[Lift] Re: A round of thanks to Marius for better GC
Thank you Dave, I just noticed a little bug in case cookies are disabled. I just committed a fix for it. Br's, Marius On Feb 20, 4:29 am, David Pollak wrote: > Folks, > Marius made some patches to Lift's GC support today. He removed the lift:gc > tag so we don't trip over the Firefox namespace issue. > > I've done some initial testing (and made a few minor updates). > > Please do a mvn -U clean install and let us know how well the new code > works. > > Please also do tests like navigating to a page with form elements on it, > waiting 45 minutes and then making sure the form can be submitted. > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: A round of thanks to Marius for better GC
Well I did some testing with cookies disabled and worked just fine. Can you pleas make a minimalist example that reproduces the problem? (I suspect you case should be reproducible on desktop browser as well if you turn of cookies from container) Br's, Marius On Feb 20, 11:40 am, "Paul O'Rorke" wrote: > Has this fix been committed? > Dunno for sure if it is really GC related > But I did an mvn -U clean install and my app worked fine on my desktop > But when I accessed it from my iPhone I got logged out in 10 or 15 > seconds. > I had cookies disabled in Safari on my iPhone. Enabling cookies fixed > the problem. > ---Paul O > > On Feb 19, 10:45 pm, "marius d." wrote: > > > Thank you Dave, > > > I just noticed a little bug in case cookies are disabled. I just > > committed a fix for it. > > > Br's, > > Marius > > > On Feb 20, 4:29 am, David Pollak > > wrote: > > > > Folks, > > > Marius made some patches to Lift's GC support today. He removed the > > > lift:gc > > > tag so we don't trip over the Firefox namespace issue. > > > > I've done some initial testing (and made a few minor updates). > > > > Please do a mvn -U clean install and let us know how well the new code > > > works. > > > > Please also do tests like navigating to a page with form elements on it, > > > waiting 45 minutes and then making sure the form can be submitted. > > > > Thanks, > > > > David > > > > -- > > > Lift, the simply functional web frameworkhttp://liftweb.net > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: A round of thanks to Marius for better GC
On Feb 20, 5:30 pm, Viktor Klang wrote: > I unfortunately have been working alot lately and havent had a chance to > check the new GC code out. > > Some kind soul who can explain the new solution? Well instead of using lift:gc all around the gc polling send up only the page ID. Functions on the session are no updating with the right owner in the rendering pipelline. Hence for a GC request we are updating the last-seen timestamp only for the functions pertaining to that specific page. Of course now if youare removing DOM nodes (or use SHtml) we don't really know what functions were tight to that node so those will still be kept around. I really don't think this is a biggie though. Even with old lift:gc approach there were some corner cases like one can clone a node, remove it, and later on add it back ... but in the mean time the function may have been gc-ed (could have happened extremely rare but it was still there). Another benefit now is that gc requests are more lightweight. ... and all thanks to Dave's nifty idea ! > > On Fri, Feb 20, 2009 at 4:18 PM, Derek Chen-Becker > wrote: > > > > > Great work! I ran into the issue yesterday and today with an update it > > seems to be working fine. > > > Derek > > > On Thu, Feb 19, 2009 at 7:29 PM, David Pollak < > > feeder.of.the.be...@gmail.com> wrote: > > >> Folks, > >> Marius made some patches to Lift's GC support today. He removed the > >> lift:gc tag so we don't trip over the Firefox namespace issue. > > >> I've done some initial testing (and made a few minor updates). > > >> Please do a mvn -U clean install and let us know how well the new code > >> works. > > >> Please also do tests like navigating to a page with form elements on it, > >> waiting 45 minutes and then making sure the form can be submitted. > > >> Thanks, > > >> David > > >> -- > >> Lift, the simply functional web frameworkhttp://liftweb.net > >> Beginning Scalahttp://www.apress.com/book/view/1430219890 > >> Follow me:http://twitter.com/dpp > >> Git some:http://github.com/dpp > > -- > Viktor Klang > Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Sanity Check...
On Feb 24, 10:16 pm, Tim Perrett wrote: > Guys, > > Just looking for a sanity check. Im planning out some database > localization stuff that I need to implement to localize a system... Im > not concerned with currency or other such fun localization problems, > simply localizing text in my database. > > Right now, im thinking of just creating a custom ResourceBundle and > having it populated by / accessing content that i'll hold in an in- > memory LRU cache (something like net.liftweb.util.KeyedCache). As I > wont need to worry about other issues like currency, im guessing that > if I add this LiftRules.resourceNames then lift will look at it for > localized content? LiftRules.resourceNames is just a list of strings and if you abstract the ResourceBundle it can have a slightly different semantic then right now where we use the ResourceBundle in the "traditional" way. It the DB context those names can act as a "namespace". > > Is their any hope of such a simplistic scheme working or have I just > been awake too long today?! > > Cheers > > Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Adding bundle factory to LiftRules
How would LiftRule.resourceNames work with type ResourceBundleFactoryPF = PartialFunction[Locale,Box [ResourceBundle]] var resourceBundleFactories : RulesSeq[ResourceBundleFactory] ... from usability perspective ? On Feb 27, 7:38 pm, Tim Perrett wrote: > Ok, excellent. I know have a working implementation! Rock. > > Any objections to submitting this into master? Im guessing the code > freeze is now off. > > Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Adding bundle factory to LiftRules
Any reason why not use NamedPF.applyBox ?
On Feb 27, 7:12 pm, Derek Chen-Becker wrote:
> Take 3. Change the factory application to:
>
> LiftRules.resourceBundleFactories.toList.find(_.isDefinedAt(locale)).toList.map(_.apply(locale))
>
> Derek
>
> On Fri, Feb 27, 2009 at 11:05 AM, Derek Chen-Becker
> wrote:
>
> > Tim, I just noticed that the PF type should be:
>
> > type ResourceBundleFactoryPF =
> > PartialFunction[(String,Locale),Box[ResourceBundle]]
>
> > The reason we wanted to use PFs was to allow specialization for a specific
> > language. I'm wondering whether the string parameter is really necessary,
> > since really that's intended to look up a bundle name via
> > ResourceBundle.getBundle. That would change the proposed code to:
>
> > type ResourceBundleFactoryPF = PartialFunction[Locale,Box[ResourceBundle]]
> > var resourceBundleFactories : RulesSeq[ResourceBundleFactory]
>
> > // In S.scala
> > def resourceBundles : List[ResourceBundle] =
> > ...
> > case Nil => _resBundle.set(LiftRules.resourceNames.flatMap(name =>
> > tryo {
> > List(ResourceBundle.getBundle(name, locale))
> > } openOr {
> > // I think this is right...
> > LiftRules.resourceBundleFactories.toList.find(_.isDefinedAt(locale)).map(_.apply(locale))
> > openOr Nil
> > }))
>
> > Derek
>
> > On Fri, Feb 27, 2009 at 9:58 AM, Tim Perrett wrote:
>
> >> Guys,
>
> >> Me and Derek have just been chatting over IM debating the whole
> >> resource bundle loading mech in Lift. As you know, im working on this
> >> database localization stuff right now as I need it for work.
>
> >> Right now, were loading bundles using the normal
> >> ResourceBundle.getBundle methods from Java. Whilst this is good for
> >> most applications, when you need flexibility to do more compelx
> >> localization, it falls down a bit.
>
> >> Id like to propose adding a configurable "bundle factory" to
> >> LiftRules, so that we provide a localization hook. Something like:
>
> >> // LiftRules.scala
> >> type ResourceBundleFactoryPF = (String,Locale) => Box[ResourceBundle]
> >> var resourceBundleFactories : RulesSeq[ResourceBundleFactory]
>
> >> Then, in S.scala where we load the bundles, rather than having openOr
> >> Nil, it could fall through to the custom loaders like so:
>
> >> case Nil => _resBundle.set(LiftRules.resourceNames.flatMap(name =>
> >> tryo {
> >> List(ResourceBundle.getBundle(name, locale))
> >> } openOr {
> >> // load bundle factories, do something
> >> // here to load them (not sure what yet!)
> >> LiftRules.resourceBundleFactories
> >> }))
>
> >> Then in Boot.scala you could do:
>
> >> LiftRules.resourceBundleFactories.prepend {
> >> case (basename, locale) => DBResourceBundle(basename, locale)
> >> }
>
> >> Thoughts?
>
> >> Cheers
>
> >> Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Adding bundle factory to LiftRules
Well yeah but I only havethis code from you:
def resourceBundles : List[ResourceBundle] =
...
case Nil => _resBundle.set(LiftRules.resourceNames.flatMap(name =>
tryo {
List(ResourceBundle.getBundle(name, locale))
} openOr {
// I think this is right...
LiftRules.resourceBundleFactories.toList.find(_.isDefinedAt
(locale)).map(_.apply(locale))
openOr Nil
}))
... and you are looking intothe factories if not found in the
"traditional" bundles. WHich I guess is fine ... but I don't see the
"name" from resurceNames passed to the factory.
SO the name has a meaning in the curent approach but not anymore when
using the new factories?
On Feb 27, 8:00 pm, Timothy Perrett wrote:
> Don't they achieve different things? resourceNames just defines the base
> name for which the default java system starts looking for localizations
> right?
>
> Cheers, Tim
>
> On 27/02/2009 17:54, "marius d." wrote:
>
>
>
> > How would LiftRule.resourceNames work with
>
> > type ResourceBundleFactoryPF = PartialFunction[Locale,Box
> > [ResourceBundle]]
> > var resourceBundleFactories : RulesSeq[ResourceBundleFactory]
>
> > ... from usability perspective ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Adding bundle factory to LiftRules
I am :) ... nice work !
On Feb 27, 8:38 pm, Tim Perrett wrote:
> Marius and I have just chatted this over on IM - I've altered the code
> to use NamedPF...
>
> The code now reads:
>
> /**
> * Get the resource bundle for the current locale
> */
> def resourceBundles: List[ResourceBundle] = {
> _resBundle.value match {
> case Nil => {
> _resBundle.set(LiftRules.resourceNames.flatMap(name => tryo(
> List(ResourceBundle.getBundle(name, locale))
> ).openOr(
> //LiftRules.resourceBundleFactories.toList.find
> (_.isDefinedAt(locale)).toList.map(_.apply(locale))
> NamedPF.applyBox((name, locale),
> LiftRules.resourceBundleFactories.toList).map(List(_)) openOr Nil
> )))
> _resBundle.value
> }
> case bundles => bundles
> }
> }
>
> Everyone happy with this?
>
> Cheers, Tim
>
> On Feb 27, 6:10 pm, "marius d." wrote:
>
> > Well yeah but I only havethis code from you:
>
> > def resourceBundles : List[ResourceBundle] =
> > ...
> > case Nil => _resBundle.set(LiftRules.resourceNames.flatMap(name =>
> > tryo {
> > List(ResourceBundle.getBundle(name, locale))
>
> > } openOr {
>
> > // I think this is right...
> > LiftRules.resourceBundleFactories.toList.find(_.isDefinedAt
> > (locale)).map(_.apply(locale))
> > openOr Nil
>
> > }))
>
> > ... and you are looking intothe factories if not found in the
> > "traditional" bundles. WHich I guess is fine ... but I don't see the
> > "name" from resurceNames passed to the factory.
>
> > SO the name has a meaning in the curent approach but not anymore when
> > using the new factories?
>
> > On Feb 27, 8:00 pm, Timothy Perrett wrote:
>
> > > Don't they achieve different things? resourceNames just defines the base
> > > name for which the default java system starts looking for localizations
> > > right?
>
> > > Cheers, Tim
>
> > > On 27/02/2009 17:54, "marius d." wrote:
>
> > > > How would LiftRule.resourceNames work with
>
> > > > type ResourceBundleFactoryPF = PartialFunction[Locale,Box
> > > > [ResourceBundle]]
> > > > var resourceBundleFactories : RulesSeq[ResourceBundleFactory]
>
> > > > ... from usability perspective ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Configurable JQuery Version?
GC stuff is not dependent on the underlying JS library. On Feb 28, 7:36 pm, Tim Perrett wrote: > Ah right excellent - I was not sure if any of the new GC stuff > *needed* that version or not hence my reason for asking :-) > > Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift newbie - Horizontal scaling of Lift servers
On Mar 1, 2:21 am, David Pollak wrote: > On Sat, Feb 28, 2009 at 2:37 PM, Ikai Lan wrote: > > > Hi, > > > I'm looking to learn Lift coming from working with Ruby on Rails for a > > while and I've been voraciously consuming the documentation and > > tutorials that are available on the internet. There are a few things I > > really like about Lift so far: > > > - Out of the box Comet support > > - Rapid development (incremental compiles are awesome) > > - Being able to design without having to think of the request/response > > cycle* > > > I'm putting an asterisk on the last item because I'm a bit confused > > how this will work in a production application running two or more > > load balanced Lift instances of the same application. > > You need a load balancer that's either JSESSIONID aware or can be tuned to > work with Lift's feature that re-writes URLs in such a way that it's easy to > have a load balancer send the requests back to the specific server that > houses the Lift session. > > > The fact that > > form processing can happen without inspecting GET/POST params or > > dealing with data that needs to life longer than a standard request > > cycle is pretty neat, but it raises questions about horizontal > > scalability. Where is the session data stored? > > In the app server where the session was initialized. > > > If it is in-memory by > > default, are there any best practices for sharing session data across > > application servers, or is the recommended solution to use load > > balancer affinity? > > The latter. > > With all this being said, I have significant operational experience with the > highest volume RoR powered site. A quad-core Intel/AMD box running Lift > could have handled all of its traffic. So, unless you're expecting to have > significantly more traffic than Twitter... unless you're site is saturating > a gigabit ethernet card, you can run it on a single server with Lift. If I may I would add ... unless you want redundancy. > > Thanks, > > David > > > > > Ikai > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Record and JSON
:) .. ok ... let me noodle for while on this and I'll get back with more details ... perhaps a POC On Mar 4, 7:11 pm, David Pollak wrote: > On Wed, Mar 4, 2009 at 9:08 AM, Marius wrote: > > > Hi, > > > I was thinking that it might be useful to be able to obtain a JSON > > representation of a Record and also from a JSON construct to create a > > Record. > > > Record defines now: > > > def suplementalJs(ob: Box[KeyObfuscator]): List[(String, JsExp)] = Nil > > > but that's not very intuitive ... not to mention not implemented yet. > > > Thoughts ? > > I've been needing bi-directional JSON support to allow for the creation of > complex JSON data structures. > > So, my thought is I have a need, but not a solution. :-) > > > > > Br's, > > Marius > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: I would Love to see JSR 168/ 268 Portlet Support
Out of curiosity are you looking for both local and remote (WSRP) portlets support ? On Mar 5, 1:11 am, abut wrote: > Having evaluated by Grails and Lift, and being about ready to start a > project, the only thing that inclines me to Grails is the portlet > support. > > Is such a thing on the Lift roadmap? > > If not, how big a effort might it be to implement such support? My > project will have substantial resources and it might be a good > opportunity to give back a little. > > Regards, > > Robert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Awesome Scala, Lift, EMSE, and Buy a Feature press
Outstanding ! On Mar 4, 9:55 pm, David Pollak wrote: > http://www.adtmag.com/article.aspx?id=24080 > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Proposed localization change to S
+1 for overloading '? '
On Mar 6, 4:52 pm, Derek Chen-Becker wrote:
> I think this is a reasonable addition, but I would use
>
> def ?(key : String, defaultKey : String) = ...
>
> That way changing the default text just doesn't require changes to code.
>
> Derek
>
> On Fri, Mar 6, 2009 at 6:29 AM, Tim Perrett wrote:
>
> > Guys,
>
> > I have a situation where I want to localize a bunch of dynamic texts,
> > however the current behavior of S.? is to return the input text if its
> > found in a resource bundle. Whilst I see the rational for this, I have
> > another situation where I want to pass a key, and if it doesn't find
> > it, display something else (the english version). Id rather not use
> > the english text as the translation key, as if the english text
> > changes, my database translations will break (not good!)
>
> > I can achieve the functionality needed right by doing something like:
>
> > S.loc(item.localization_key.toString + ".name") match {
> > case Full(t) => t
> > case _ => Text(doc.name.toString)
> > }
>
> > But it would be nice if we could have a utility method in S which
> > allowed you do do:
>
> > ?("my.localization.key", defaultText.toString)
>
> > Thoughts?
>
> > Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Record and JSON
Why not use Lift's parser one for the purpose of Record integration? However the way I see it converting from a Record to JSON the result should be a JsObj structure so that it can be used in other JS expressions. Also converting from a Record to JsObj is pretty straight forward at this Record stage. Please don't get me wrong .. I really like what you did (as a generic and isolated solution) but for Records stuff ... I don't see lots of reasons to integrate it. Br's, Marius On Mar 6, 10:11 pm, Jorge Ortiz wrote: > And I forgot the link: > > http://paste.pocoo.org/show/106757/ > > --j > > On Fri, Mar 6, 2009 at 12:11 PM, Jorge Ortiz wrote: > > Hey Folks, > > > I wrote a Json AST and parser/serializer for unrelated reasons yesterday. > > This could be the basis of a Record <--> Json tool. > > > --j > > > On Wed, Mar 4, 2009 at 9:11 AM, David Pollak < > > feeder.of.the.be...@gmail.com> wrote: > > >> On Wed, Mar 4, 2009 at 9:08 AM, Marius wrote: > > >>> Hi, > > >>> I was thinking that it might be useful to be able to obtain a JSON > >>> representation of a Record and also from a JSON construct to create a > >>> Record. > > >>> Record defines now: > > >>> def suplementalJs(ob: Box[KeyObfuscator]): List[(String, JsExp)] = Nil > > >>> but that's not very intuitive ... not to mention not implemented yet. > > >>> Thoughts ? > > >> I've been needing bi-directional JSON support to allow for the creation of > >> complex JSON data structures. > > >> So, my thought is I have a need, but not a solution. :-) > > >>> Br's, > >>> Marius > > >> -- > >> Lift, the simply functional web frameworkhttp://liftweb.net > >> Beginning Scalahttp://www.apress.com/book/view/1430219890 > >> Follow me:http://twitter.com/dpp > >> Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Bug in LiftRules defaultLocaleCalculator
I'll look on it this evening ... On Mar 11, 1:12 pm, Timothy Perrett wrote: > Just realised i had not posted the stack trace: > > java.lang.NullPointerException > at net.liftweb.http.LiftRules$$anonfun$defaultLocaleCalculator > $1.apply(LiftRules.scala:316) > at net.liftweb.http.LiftRules$$anonfun$defaultLocaleCalculator > $1.apply(LiftRules.scala:316) > at net.liftweb.util.Full.flatMap(Box.scala:332) > at net.liftweb.http.LiftRules$.defaultLocaleCalculator > (LiftRules.scala:316) > at com.xmpie.bos.localization.Localizer$$anonfun > $localeCalculator$1.workOutLocale$1(Localizer.scala:95) > at com.xmpie.bos.localization.Localizer$$anonfun > $localeCalculator$1.apply(Localizer.scala:100) > at com.xmpie.bos.localization.Localizer$$anonfun > $localeCalculator$1.apply(Localizer.scala:90) > at net.liftweb.util.Full.flatMap(Box.scala:332) > at com.xmpie.bos.localization.Localizer$.localeCalculator > (Localizer.scala:90) > at com.xmpie.bos.localization.Localizer$$anonfun$boot$2.apply > (Localizer.scala:54) > at com.xmpie.bos.localization.Localizer$$anonfun$boot$2.apply > (Localizer.scala:54) > at net.liftweb.http.S$.locale(S.scala:171) > at net.liftweb.http.S$$anonfun$resourceBundles$1$$anonfun$apply > $11.apply(S.scala:242) > at net.liftweb.http.S$$anonfun$resourceBundles$1$$anonfun$apply > $11.apply(S.scala:242) > at net.liftweb.util.EmptyBox.openOr(Box.scala:372) > at net.liftweb.http.S$$anonfun$resourceBundles$1.apply(S.scala: > 241) > at net.liftweb.http.S$$anonfun$resourceBundles$1.apply(S.scala: > 239) > at scala.List.flatMap(List.scala:1125) > at net.liftweb.http.S$.resourceBundles(S.scala:239) > at net.liftweb.http.S$.$qmark(S.scala:267) > at com.xmpie.bos.comet.JobNotifier.status(JobNotifier.scala: > 33) > at com.xmpie.bos.comet.JobNotifier.render(JobNotifier.scala: > 34) > at net.liftweb.http.CometActor$class.net$liftweb$http > $CometActor$$performReRender(CometActor.scala:474) > at net.liftweb.http.CometActor$$anonfun$net$liftweb$http > $CometActor$$_mediumPriority$1.apply(CometActor.scala:374) > at net.liftweb.http.CometActor$$anonfun$net$liftweb$http > $CometActor$$_mediumPriority$1.apply(CometActor.scala:338) > at scala.PartialFunction$$anon$1.apply(PartialFunction.scala: > 38) > at scala.PartialFunction$$anon$1.apply(PartialFunction.scala: > 37) > at scala.PartialFunction$$anon$1.apply(PartialFunction.scala: > 37) > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > $anonfun$apply$11$$anonfun$apply$12.apply(CometActor.scala:303) > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > $anonfun$apply$11$$anonfun$apply$12.apply(CometActor.scala:302) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.liftweb.http.S$.functionLifespan(S.scala:520) > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > $anonfun$apply$11.apply(CometActor.scala:302) > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > $anonfun$apply$11.apply(CometActor.scala:302) > at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala: > 402) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$ > $_nest2InnerInit$1$$anonfun$apply$18.apply(S.scala:457) > at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala: > 376) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$ > $_nest2InnerInit$1.apply(S.scala:455) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit > (S.scala:454) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit > $1$$anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply > $24$$anonfun$apply$25$$anonfun$apply$26.apply(S.scala:475) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit > $1$$anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply > $24$$anonfun$apply$25.apply(S.scala:474) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit > $1$$anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply > $24.apply(S.scala:473) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit > $1$$anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23.apply(S.scala: > 472) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit > $1$$anonfun$apply$21$$anonfun$apply$22.apply(S.scala:471) > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > at net.lif
[Lift] Re: Bug in LiftRules defaultLocaleCalculator
Ohh goody goody goody ... I won't have to fix it :D ... so back on the book work ... On Mar 11, 5:15 pm, David Pollak wrote: > Fixed in the 1.1 branch. It might make sense to back-port to the 1.0 branch > > > > On Wed, Mar 11, 2009 at 1:49 PM, marius d. wrote: > > > I'll look on it this evening ... > > > On Mar 11, 1:12 pm, Timothy Perrett wrote: > > > Just realised i had not posted the stack trace: > > > > java.lang.NullPointerException > > > at net.liftweb.http.LiftRules$$anonfun$defaultLocaleCalculator > > > $1.apply(LiftRules.scala:316) > > > at net.liftweb.http.LiftRules$$anonfun$defaultLocaleCalculator > > > $1.apply(LiftRules.scala:316) > > > at net.liftweb.util.Full.flatMap(Box.scala:332) > > > at net.liftweb.http.LiftRules$.defaultLocaleCalculator > > > (LiftRules.scala:316) > > > at com.xmpie.bos.localization.Localizer$$anonfun > > > $localeCalculator$1.workOutLocale$1(Localizer.scala:95) > > > at com.xmpie.bos.localization.Localizer$$anonfun > > > $localeCalculator$1.apply(Localizer.scala:100) > > > at com.xmpie.bos.localization.Localizer$$anonfun > > > $localeCalculator$1.apply(Localizer.scala:90) > > > at net.liftweb.util.Full.flatMap(Box.scala:332) > > > at com.xmpie.bos.localization.Localizer$.localeCalculator > > > (Localizer.scala:90) > > > at com.xmpie.bos.localization.Localizer$$anonfun$boot$2.apply > > > (Localizer.scala:54) > > > at com.xmpie.bos.localization.Localizer$$anonfun$boot$2.apply > > > (Localizer.scala:54) > > > at net.liftweb.http.S$.locale(S.scala:171) > > > at net.liftweb.http.S$$anonfun$resourceBundles$1$$anonfun$apply > > > $11.apply(S.scala:242) > > > at net.liftweb.http.S$$anonfun$resourceBundles$1$$anonfun$apply > > > $11.apply(S.scala:242) > > > at net.liftweb.util.EmptyBox.openOr(Box.scala:372) > > > at net.liftweb.http.S$$anonfun$resourceBundles$1.apply(S.scala: > > > 241) > > > at net.liftweb.http.S$$anonfun$resourceBundles$1.apply(S.scala: > > > 239) > > > at scala.List.flatMap(List.scala:1125) > > > at net.liftweb.http.S$.resourceBundles(S.scala:239) > > > at net.liftweb.http.S$.$qmark(S.scala:267) > > > at com.xmpie.bos.comet.JobNotifier.status(JobNotifier.scala: > > > 33) > > > at com.xmpie.bos.comet.JobNotifier.render(JobNotifier.scala: > > > 34) > > > at net.liftweb.http.CometActor$class.net$liftweb$http > > > $CometActor$$performReRender(CometActor.scala:474) > > > at net.liftweb.http.CometActor$$anonfun$net$liftweb$http > > > $CometActor$$_mediumPriority$1.apply(CometActor.scala:374) > > > at net.liftweb.http.CometActor$$anonfun$net$liftweb$http > > > $CometActor$$_mediumPriority$1.apply(CometActor.scala:338) > > > at scala.PartialFunction$$anon$1.apply(PartialFunction.scala: > > > 38) > > > at scala.PartialFunction$$anon$1.apply(PartialFunction.scala: > > > 37) > > > at scala.PartialFunction$$anon$1.apply(PartialFunction.scala: > > > 37) > > > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > > > $anonfun$apply$11$$anonfun$apply$12.apply(CometActor.scala:303) > > > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > > > $anonfun$apply$11$$anonfun$apply$12.apply(CometActor.scala:302) > > > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > > > at net.liftweb.http.S$.functionLifespan(S.scala:520) > > > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > > > $anonfun$apply$11.apply(CometActor.scala:302) > > > at net.liftweb.http.CometActor$$anon$1$$anonfun$apply$10$ > > > $anonfun$apply$11.apply(CometActor.scala:302) > > > at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala: > > > 402) > > > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$ > > > $_nest2InnerInit$1$$anonfun$apply$18.apply(S.scala:457) > > > at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala: > > > 376) > > > at net.liftweb.http.S$$anonfun$net$liftweb$http$S$ > > > $_nest2InnerInit$1.apply(S.scala:455) > > > at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) > > > at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit &g
[Lift] Re: How can I use unit tests with S.?("key") ?
Can you try
S.initIfUninitted(liftSession) {
do your code here
}
?
... but you'd still need to create a dumb LiftSession
Br's,
Marius
On Mar 11, 8:40 pm, "Joachim A." wrote:
> Hi,
> I have a unit test which call a method which uses the locale method S.?
> (String). It throws a nullpointer, though.
>
> Did I forget to setup things somewhere? Or can't I use S.? without a running
> request?
> The call to S.? works fine in a running web application.
>
> Thanks a lot,
> Joachim
>
> The beginning of the backtrace is:
>
> java.lang.NullPointerException
> at net.liftweb.http.S$.$qmark$bang(S.scala:288)
> at net.liftweb.http.S$.$qmark(S.scala:263)
> at net.liftweb.http.S$.$qmark(S.scala:277)
> at
> com.ansorgit.frontend.SubscriptionMgr$.subscribeToNewsletter(SubscriptionMgr.scala:65)
> at
> com.ansorgit.frontend.SubscriptionMgrTest$$anonfun$testAlreadySubscribed$1.apply(SubscriptionMgrTest.scala:37)
> at
> com.ansorgit.frontend.SubscriptionMgrTest$$anonfun$testAlreadySubscribed$1.apply(SubscriptionMgrTest.scala:33)
> at
> net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith(DB.scala:117)
> at
> net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$$doWith$1.apply(DB.scala:118)
> at
> net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$$doWith$1.apply(DB.scala:118)
> at net.liftweb.mapper.DB$.use(DB.scala:305)
> at
> net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith(DB.scala:118)
> at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:124)
> at com.ansorgit.BaseDBTest.runInDb(BaseTest.scala:44)
> at
> com.ansorgit.frontend.SubscriptionMgrTest.testAlreadySubscribed(SubscriptionMgrTest.scala:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: OpenID defect and fix
Good points but OpenIdConsumer is typically not directly used. To make it work from your application you just use OpenIdVendor On Mar 15, 8:52 pm, Jan Lohre wrote: > Breaking the api IMHO needs stronger justification than naming consistency. > > But thats just my two cents. > > Kind regards, > Jan > > 2009/3/15 Marius > > > > > Folks, > > > Writing about OpenID in LIftBook inherently made me use it so I can > > use valid examples. Everything worked smoothly ... util I turned off > > cookies. This broke the OpenID flow and the Identity Provider side > > returned an error page. There were two fundamental problems: > > > 1. On redirect the Location was updated encodeURL from response > > regardless if this was an absolute URL and jsessionid part was > > becoming part of the redirect of the Identity Provider destination URL > > which was obviously wrong > > > 2. OpenID code did not call S.encodeURL for the return_url meaning > > that the Identity Provider was redirecting back to our site and since > > jsessionid part was no there it was pocessed in the context of a new > > session and not the correct one. > > > I will be committing the fix for this a a couple of minutes ... woks > > smooth now. But there is a minor thing. We have the traits: > > > OpenIdVendor and > > OpenIDConsumer > > > does anyone has any objections renaming OpenIDConsumer to > > OpenIdConsumer (for naming consistency purposes)? > > > Br's, > > Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: OpenID defect and fix
+1 Charles... (... I would rather avoid diverging into a philosophical discussion). I wonder if there is someone out there that actually used directly OpenIDConsumer ... it's likely not break anything since Lift's OpenID support is pretty undocumented ... till now. Furthermore I opted in for renaming OpenIDConsumer and not OpenIdVendor because the later is what you'd directly use to enable OpenID in your application and there are way better chances for existing apps to actually use OpenIdVendor already. Br's, Marius On Mar 15, 10:46 pm, "Charles F. Munat" wrote: > I would argue the reverse. Naming consistency is forever. Breaking the > API is once, and affects only a small number of developers. I, for one, > when I start using OpenID, will be screwing that up over and over again > as my brain refuses to remember which one is all caps and which is mixed > case. > > Chas. > > Jan Lohre wrote: > > Breaking the api IMHO needs stronger justification than naming consistency. > > > But thats just my two cents. > > > Kind regards, > > Jan > > > 2009/3/15 Marius mailto:marius.dan...@gmail.com>> > > > Folks, > > > Writing about OpenID in LIftBook inherently made me use it so I can > > use valid examples. Everything worked smoothly ... util I turned off > > cookies. This broke the OpenID flow and the Identity Provider side > > returned an error page. There were two fundamental problems: > > > 1. On redirect the Location was updated encodeURL from response > > regardless if this was an absolute URL and jsessionid part was > > becoming part of the redirect of the Identity Provider destination URL > > which was obviously wrong > > > 2. OpenID code did not call S.encodeURL for the return_url meaning > > that the Identity Provider was redirecting back to our site and since > > jsessionid part was no there it was pocessed in the context of a new > > session and not the correct one. > > > I will be committing the fix for this a a couple of minutes ... woks > > smooth now. But there is a minor thing. We have the traits: > > > OpenIdVendor and > > OpenIDConsumer > > > does anyone has any objections renaming OpenIDConsumer to > > OpenIdConsumer (for naming consistency purposes)? > > > Br's, > > Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: xml parser, utf-8, special characters... kill me now
just out of curiosity are you setting manually in the HTTP header
Content-Type: text/html; charset=UTF-8
and it's still broken?
P.S.
Sometimes HTTP equiv from HTML header just doesn't do the trick.
Br's,
Marius
On Mar 15, 11:20 pm, Derek Chen-Becker wrote:
> Crapola:
>
> http://jira.codehaus.org/browse/JETTY-958
>
> I think I've confirmed that this is not lift. I added a non-lift input text
> element to an existing lift form:
>
>
>
> Then I use the following code, which I believe should be getting direct
> access to Jetty's HttpServletRequest instance:
>
> Log.info("testthis = " + (S.request.map({r =>
> r.request.getParameter("testthis")}) openOr "not found!"))
>
> And when I put a cedilla in, I get:
>
> INFO - testthis = ç
>
> Can you confirm that you're using Jetty? I also tried the flags listed in
> the JIRA ticket:
>
> -Dorg.mortbay.util.URI.charset=utf-8 -Dfile.encoding=UTF-8
>
> But they didn't seem to do anything (it didn't crash, though). I'm not sure
> if I specified those correctly for use with the Maven jetty:run command
> line:
>
> mvn -Djetty.port=9090 -Dorg.mortbay.util.URI.charset=utf-8
> -Dfile.encoding=UTF-8 jetty:run
>
> Anyways, this doesn't look to be Lift's fault. I know that's not a great
> answer. I'm trying to think of whether there's a clean, simple way to "undo"
> the bogus transform but I don't know enough about charset handling. One more
> interesting thing is that if I change my log code to:
>
> Log.info("testthis = " + (S.request.map({r => r.request.getCharacterEncoding
> + r.request.getParameter("testthis")}) openOr "not found!"))
>
> I get:
>
> INFO - testthis = nullç
>
> Which seems to indicate that the character encoding for the POST isn't being
> set. I tried overriding it:
>
> S.request.foreach{ r => r.request.setCharacterEncoding("UTF-8")}
>
> and that seems to have absolutely no effect (in fact, I get the same "null"
> log message).
>
> Derek
>
> On Sun, Mar 15, 2009 at 3:08 PM, Charles F. Munat wrote:
>
>
>
> > Marc Boschma wrote:
> > >> When I use ç instead, the problem is that it is *not* converted
> > >> to ç as it goes into the database, and then on the way out the XML
> > >> interpreter does not recognize it as a character entity reference
> > >> and so
> > >> converts the & to &.
>
> > > I think this is due to using the standard Scala XML load functions
> > > rather than the lift XML parser. From memory I don't think the
> > > standard parser recognises that many named entities. ie. does ç
> > > work instead of ç ? If so then that is probably what is
> > > happening on this issue.
>
> > ç goes into the database unchanged, but comes back out as
> > ç. For that matter, & in the DB comes out as & on
> > the page.
>
> > This is actually fine with me. It means that my users can just type &,
> > <, > etc. and they will appear on the page that way (rather than being
> > intepreted as HTML tags). It's safer, too. There is no way for them to
> > insert HTML, especially script tags.
>
> > So really, the only problem I have is that I need to be able to type a ç
> > and have it still a ç when it gets to the database.
>
> > Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: OpenID defect and fix
It's done. On Mar 16, 3:05 am, David Pollak wrote: > Marius, > Go ahead and make the change. I think I'm the only one using the OpenID > stuff and I'm happy to fix it. > > The following maven packages are heavily used and I consider it a serious > negative to break APIs: lift-util, lift-http, and lift-mapper. The others I > consider to be a little more slushy. > > Thanks, > > David > > > > On Sun, Mar 15, 2009 at 8:44 PM, marius d. wrote: > > > Good points but OpenIdConsumer is typically not directly used. To make > > it work from your application you just use OpenIdVendor > > > On Mar 15, 8:52 pm, Jan Lohre wrote: > > > Breaking the api IMHO needs stronger justification than naming > > consistency. > > > > But thats just my two cents. > > > > Kind regards, > > > Jan > > > > 2009/3/15 Marius > > > > > Folks, > > > > > Writing about OpenID in LIftBook inherently made me use it so I can > > > > use valid examples. Everything worked smoothly ... util I turned off > > > > cookies. This broke the OpenID flow and the Identity Provider side > > > > returned an error page. There were two fundamental problems: > > > > > 1. On redirect the Location was updated encodeURL from response > > > > regardless if this was an absolute URL and jsessionid part was > > > > becoming part of the redirect of the Identity Provider destination URL > > > > which was obviously wrong > > > > > 2. OpenID code did not call S.encodeURL for the return_url meaning > > > > that the Identity Provider was redirecting back to our site and since > > > > jsessionid part was no there it was pocessed in the context of a new > > > > session and not the correct one. > > > > > I will be committing the fix for this a a couple of minutes ... woks > > > > smooth now. But there is a minor thing. We have the traits: > > > > > OpenIdVendor and > > > > OpenIDConsumer > > > > > does anyone has any objections renaming OpenIDConsumer to > > > > OpenIdConsumer (for naming consistency purposes)? > > > > > Br's, > > > > Marius > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Custom Boot Class
Thanks Jorge for pointing this out. We'll look into it. Looks like a
Lift bug so far.
Br's,
Marius
On Mar 16, 12:31 pm, Jorge Ortiz wrote:
> Folks,
>
> I'm trying to specify a custom Boot class, as per Chapter 3 of the Lift
> Book. To my web.xml I've added:
>
>
> bootloader
> bootstrap.liftweb.Brat
>
>
> and in Boot.scala I've commented out the regular Boot class and added a Brat
> class with identical implementation, except it extends Bootable.
>
> class Brat extends Bootable { ... }
>
> Unfortunately, I'm getting a:
>
> ERROR - Failed to Boot
> java.lang.ClassNotFoundException: bootstrap.liftweb.Boot
>
> Attached is the zipped project.
>
> Thanks,
>
> --j
>
> bootable.zip
> 20KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Error in Msgs
You're right. Can you fix and commit it ? On Mar 16, 8:20 pm, "Charles F. Munat" wrote: > Line 54 in net.liftweb.builtin.snippet.Msgs.scala reads: > > (styles \\ "error_msg" \\ "@class")), 1), > > It should read: > > (styles \\ "warning_msg" \\ "@class")), 1), > > Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Error in Msgs
Wow I could have swear that Charles is on bord ! LOL I'll commit it in a bit :) On Mar 16, 9:26 pm, "Charles F. Munat" wrote: > Heh, heh. You don't want me sticking my nose in there... > > Chas. > > marius d. wrote: > > You're right. Can you fix and commit it ? > > > On Mar 16, 8:20 pm, "Charles F. Munat" wrote: > >> Line 54 in net.liftweb.builtin.snippet.Msgs.scala reads: > > >> (styles \\ "error_msg" \\ "@class")), 1), > > >> It should read: > > >> (styles \\ "warning_msg" \\ "@class")), 1), > > >> Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Error in Msgs
committed in both master anf 1.0 On Mar 16, 10:00 pm, "marius d." wrote: > Wow I could have swear that Charles is on bord ! LOL > > I'll commit it in a bit :) > > On Mar 16, 9:26 pm, "Charles F. Munat" wrote: > > > Heh, heh. You don't want me sticking my nose in there... > > > Chas. > > > marius d. wrote: > > > You're right. Can you fix and commit it ? > > > > On Mar 16, 8:20 pm, "Charles F. Munat" wrote: > > >> Line 54 in net.liftweb.builtin.snippet.Msgs.scala reads: > > > >> (styles \\ "error_msg" \\ "@class")), 1), > > > >> It should read: > > > >> (styles \\ "warning_msg" \\ "@class")), 1), > > > >> Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
FWIW please also take a look on Record and form&validation support.
Br's,
Marius
On Mar 17, 11:07 pm, Clemens Oertel wrote:
> Hello everybody,
>
> Still trying to learn how to use lift efficiently and effectively, I
> got a little bit confused about the toForm function in the model/
> mappers. Admittedly, my web framework background may be limited, but
> this looked to me as if some view code snuck into the model space
> there (I must admit that I do like how RoR tries to keep the models
> fairly clean of both controller code and of view code).
>
> For my first little project, I was going to encapsulate the HTML field
> formatting into a separate class (similar to what RoR does, but making
> use of the type system).
>
> This is a very quick brain dump, not running code.
>
> // The different field types, at a higher level than HTML
> abstract class InputType
> case class TextField extends InputType
> case class DateField extends InputType
> case class DateTimeField extends InputType
>
> // Rendering hints that an form field formatter may use, could also be
> called FormGenerator ...
> abstract class RenderingHint
> case class MinLength(l: Int) extends RenderingHint
> case class MaxLength(l: Int) extends RenderingHint
>
> // Input-type aware callback'ed formatter, from the model's perspective
> trait InputTypeHandler {
> def handleTextField(fieldID: String, presetValue: String,
> renderingHints: RenderingHint*)
>
> def handleDateField(fieldID: String, presetValue: Date,
> renderingHints: RenderingHint*)
>
> }
>
> // A model class using the callback
> class ModelClass {
> object aField extends MappedString(this, 128) {
> def inputTypeCallback(InputTypeHandler handler) {
> // A reasonable default should/could be pushed upwards in the
> type hierarchy
> handler.handleTextField(fieldID, this.is, MaxLength(this.length))
> }
> }
>
> }
>
> This InputTypeHandler could be a nice spot to deal with validation
> result formatting:
>
> class AnInputFormatter(errors: List[FieldError]) extends
> InputTypeHandler {
> def handleTextField(fieldID: String, presetValue: String,
> renderingHints: RenderingHint*) {
> errors.filter(_._1 == fieldID).match {
> case Nil => /* format field normally */
> case xs => /* format as error, i.e. red background, error
> messages right of field */
> }
> }
>
> ...
>
> }
>
> // A snippet
> ...
> val inputFormatter = new AnInputFormatter(errorsFromValidation)
> bind("form", html, "aField" -> aModelClass.aField.
> inputTypeCallback(inputFormatter))
> ...
>
> Maybe a partial function, potentially on case classes, is better? Many
> options ...
>
> I'm looking forward to any feedback.
>
> Best,
> Clemens
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Welcome Lee Mighdoll to the Lift committers
Lee, you're most welcomed ! On Mar 18, 5:11 am, David Pollak wrote: > Folks, > I'm pleased to welcome Lee Mighdoll to the Lift committers. Lee wrote the > brilliant line: > > Lift is an expressive and elegant framework for writing web applications. > > Almost 18 months ago... but he's not a marketing guy, he's a code slinger > and he's going to be slinging some pretty cool code into Lift. > > Please join me in welcoming Lee on board! > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 18, 1:30 pm, Clemens Oertel wrote:
> I admit to only having worked with mapper. I will look closer into
> record, (quick glance: it comes with next-to-the-field messages, nice).
>
> Marius, are you referring to the toForm functions? I'm probably just
> not seeing how to use them in a flexible manner. With respect to
> validation, I was wondering how to apply conditional formatting based
> on failed/succeeded validation.
Yes I am referring to toForm but note that you can provide your own
template. Please see formTemplate. I think the existent scaladocs can
be quite helpful. You can also apply an extremely flexible validation
model. Each field can have multiple validators and when you are
calling S.error(MetaRecord.validate(myRecord)) Lift will automatically
place the error messages near by your fields.
Nevertheless for youimediate needs the Record is probably not very
relevant yet as DB for Recrd is not yet implemented. I was just
pointing out that forms&form validations are consistently provided by
Record. I think there is still some level of validation in mappers but
I haven't played with it yet ...
>
> Maybe a word or two to the background of my questions: I'm currently
> trying to port a web application from RoR to lift. All I know is that
> RoR does not work for me any longer, but I'm not sure where to go yet,
> so I started to look around, and lift seems to be the most promising
> candidate. The heavy exposure to RoR might have tainted my mind, true,
> and I'm open to be shown the light.
>
> Anyways, this app is of medical nature, very database heavy, lots and
> lots of fields. In order to avoid error upon data entry, the record's
> form on screen must looks as closely like the paper version as
> possible. A record's field can appear (and may be edited) in different
> contexts. Sometimes, the same text field is displayed with different
> lengths, the same text area may have different heights, all text
> fields may be limited to a max length of n in some contexts, etc.
>
> Other aspect of the story: While working on the RoR version, the
> directive was: Some boolean fields are to be displayed as drop downs
> with 3 values (empty, yes, no). This now has changed, these boolean
> fields are to be displayed as 3 radio buttons. One of course wants to
> ensure that such a change only affects one area in the code base.
>
> That's what got me wondering: Is the toForm approach the best one for
> my case?
>
> Thanks for listening,
> Clemens
>
> On 18-Mar-09, at 3:18 AM, marius d. wrote:
>
>
>
>
>
> > FWIW please also take a look on Record and form&validation support.
>
> > Br's,
> > Marius
>
> > On Mar 17, 11:07 pm, Clemens Oertel wrote:
> >> Hello everybody,
>
> >> Still trying to learn how to use lift efficiently and effectively, I
> >> got a little bit confused about the toForm function in the model/
> >> mappers. Admittedly, my web framework background may be limited, but
> >> this looked to me as if some view code snuck into the model space
> >> there (I must admit that I do like how RoR tries to keep the models
> >> fairly clean of both controller code and of view code).
>
> >> For my first little project, I was going to encapsulate the HTML
> >> field
> >> formatting into a separate class (similar to what RoR does, but
> >> making
> >> use of the type system).
>
> >> This is a very quick brain dump, not running code.
>
> >> // The different field types, at a higher level than HTML
> >> abstract class InputType
> >> case class TextField extends InputType
> >> case class DateField extends InputType
> >> case class DateTimeField extends InputType
>
> >> // Rendering hints that an form field formatter may use, could also
> >> be
> >> called FormGenerator ...
> >> abstract class RenderingHint
> >> case class MinLength(l: Int) extends RenderingHint
> >> case class MaxLength(l: Int) extends RenderingHint
>
> >> // Input-type aware callback'ed formatter, from the model's
> >> perspective
> >> trait InputTypeHandler {
> >> def handleTextField(fieldID: String, presetValue: String,
> >> renderingHints: RenderingHint*)
>
> >> def handleDateField(fieldID: String, presetValue: Date,
> >> renderingHints: RenderingHint*)
>
> >> }
>
> >> // A model class using the callback
> >> class ModelClass {
> >> object aField extends MappedString(this, 128) {
> >> def inputTypeCallback(InputTyp
[Lift] Re: Forms & validation formatter
On Mar 18, 8:54 pm, Clemens wrote: > > Yes I am referring to toForm but note that you can provide your own > > template. Please see formTemplate. > > I did, thanks for the pointer. formTemplate applies to the record as a > whole, right? If I want to render a record differently, I could set > different templates one after the other - even though this introduces > more evil state dependence. Well you can use different RecordMeta implementations if you need to different representation of a record without sequential template change. So no state dependency. > > Just trying to figure out how to how to solve my case where a field is > supposed to be rendered differently in different contexts - a single > asXHtml variable doesn't seem to allow this. > > Also, all the formatting happens in what I thought was the DB > abstraction layer, which still makes context-sensitive formatting > difficult (again, as I understand things right know) - it's just > personal style, but I like to keep control flow and view stuff outside > my data models. Well keeping close view representation and backend abstraction makes a lot of sense as it reduces lots of complexity. Having records/mappers that know how to represent themselves in different contexts (DB, xhtml) brings a lot of benefits an simplicity. I admit thought that it's quire a paradigm shift from ... say MVC mindset. But let's not get into a "patterns" debate now .. we had plenty of those :) > > But record promises to give me a lot more flexibility than mapper, > that's great. > > > I think the existent scaladocs can > > be quite helpful. > > Point taken ;-) > > > Nevertheless for youimediate needs the Record is probably not very > > relevant yet as DB for Recrd is not yet implemented. I was just > > pointing out that forms&form validations are consistently provided by > > Record. I think there is still some level of validation in mappers but > > I haven't played with it yet ... > > Oh, the validation is working just fine with mapper. It's only the > lack of flexibility with respect to automated output that's I'm > talking about. I'm sorry maybe I'm missing something but can you give a Minimalistic example that would yield the lack of flexibility of Mapper for your needs? Perhaps we can improve things or perhaps certain things are already there waiting to be discovered. > > Best, > Clemens --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: horizontal navbar drop-downs
I'm wondering if we shouldn't provide this by the means of a Lift widget. Looks like a needed feature ... WDYT ? Br's, Marius On Mar 19, 6:43 pm, David Pollak wrote: > On Thu, Mar 19, 2009 at 9:30 AM, Derek Chen-Becker > wrote: > > > This is something that has been asked before, but I don't think there was > > anything out there. I think that this would be a really nice feature, > > particularly if it could leverage the existing jQuery stuff. IIRC, the > > built-in Menu snippet doesn't render children at all unless the parent is > > the current selected page, so we would have to either modify that or we > > could code up a new MenuBar snippet that renders a "bar" instead of a UL > > like the current one. > > There's a way to ask for the entire menu rather than just the current view. > Dan O'Leary from Enthiosys did this for Innovation Games Online. I've > pinged him to see if he can share some of the code. > > > > > > > Derek > > > On Thu, Mar 19, 2009 at 10:21 AM, DavidV wrote: > > >> I'm wondering if there is a built-in way to create drop-down menus > >> from a horizontal navbar using the Menu.builder method. These are the > >> relevant sections of my current template: > > >> My Title > >> > >> > >> > >>
[Lift] Re: Forms & validation formatter
On Mar 18, 11:24 pm, Clemens wrote: > Thank you for your patience, Marius. > > > Well you can use different RecordMeta implementations if you need to > > different representation of a record without sequential template > > change. So no state dependency. > >, b I'm really not trying to be difficultut having multiple RecordMeta > instances, for which the HTML output seems to be only one of many > functionalities, seems to be shooting with canons at sparrows. Having > a toForm functions that takes some template provider as input could be > one option. Well this is kinda already in there but it's private :) ... See: private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq so to me makes sense to relax it ... to public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq ... thanks for reminding me about this :) > > Anyways, I was not even thinking at record level, but rather at field > level. See below. > > > Well keeping close view representation and backend abstraction makes a > > lot of sense as it reduces lots of complexity. Having records/mappers > > that know how to represent themselves in different contexts (DB, > > xhtml) brings a lot of benefits an simplicity. I admit thought that > > (Btw, by "context" I meant different HTML display contexts.) > > I agree that a field should be able to provide hints about how it > should be represented, such as max/min length, type, defaults, etc. > > Depending on the logical context within the app I'm working on, a > record (and thus its fields) can have multiple representations: row in > a table, complete record as a table, abbreviated record as a table, > complete form as table, form as row in a table, form with mandatory > fields only, records have to be printed out as ini-files, etc. > Unfortunately, it's not me making this stuff up, it's fixed > requirements. > > At field level, there are also different possible representations. For > example, I would like to be able to represent a record as a tabular > form, with every input field being shown with its preferred length. In > addition to this, I would like to have a different form with a fixed > with multi-column layout; for this form, no input field must be wider > than 40 characters. Somehow I have to tell the fields not to make > themselves wider than 40 characters, and not just use the maximum > length. > > Again, what it boils down to is the desire to be able to have > different representations for a single record, and to have different > possible representations for each field. This while maintaining as > much encapsulation as possible. Well for both mapper and record you have the toForm function which is per field thus allows you to represent the field in any way you like: your own Node, augment the default node with new attributes etc. And your implementation can of choose the layout based on your own context. > > Hence my original idea to have fields provide representation hints > (eg. "I'd like to be 80 characters wide"), and then have another > "something" that uses these hints for the actual output, while > potentially adding additional hints/constrains (eg. "No one get's more > than 40 characters"), css directives, a little red star in front of > mandatory fields (based on a rendering hint), Depending on how > the record is being displayed, I would use a different "something", > and neither the record nor the fields would have to know anything > about "application context". Well since you can override the toForm for each field you can add your own "something" to it. Thus you can work with necessary abstractions to make the field "unaware" of the "application context" if that's what you want but it feels to me that this is an application specific concern and not a framework one. Personally if I'd need to render a record/field in different layouts using mapper I'd probably make the fields aware of the context in which they need to render themselves. Context is good ! :) > > If I then had a default "something", which renders fields the way they > are rendered right now, and have the various record fields > (StringField, etc.) call upon this default "something" whenever their > toForm-function is called, no one would notice something has changed. > But I could also call toForm(formRenderer) for non-default rendering. > > > it's quire a paradigm shift from ... say MVC mindset. But let's not > > get into a "patterns" debate now .. we had plenty of those :) > > Agreed. > > Best, > Clemens --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 19, 7:08 pm, "marius d." wrote: > On Mar 18, 11:24 pm, Clemens wrote: > > > Thank you for your patience, Marius. > > > > Well you can use different RecordMeta implementations if you need to > > > different representation of a record without sequential template > > > change. So no state dependency. > > >, b I'm really not trying to be difficultut having multiple RecordMeta > > instances, for which the HTML output seems to be only one of many > > functionalities, seems to be shooting with canons at sparrows. Having > > a toForm functions that takes some template provider as input could be > > one option. > > Well this is kinda already in there but it's private :) ... See: > > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > so to me makes sense to relax it ... to > > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq I used here on purpose ... :) > > ... thanks for reminding me about this :) > > > > > > > Anyways, I was not even thinking at record level, but rather at field > > level. See below. > > > > Well keeping close view representation and backend abstraction makes a > > > lot of sense as it reduces lots of complexity. Having records/mappers > > > that know how to represent themselves in different contexts (DB, > > > xhtml) brings a lot of benefits an simplicity. I admit thought that > > > (Btw, by "context" I meant different HTML display contexts.) > > > I agree that a field should be able to provide hints about how it > > should be represented, such as max/min length, type, defaults, etc. > > > Depending on the logical context within the app I'm working on, a > > record (and thus its fields) can have multiple representations: row in > > a table, complete record as a table, abbreviated record as a table, > > complete form as table, form as row in a table, form with mandatory > > fields only, records have to be printed out as ini-files, etc. > > Unfortunately, it's not me making this stuff up, it's fixed > > requirements. > > > At field level, there are also different possible representations. For > > example, I would like to be able to represent a record as a tabular > > form, with every input field being shown with its preferred length. In > > addition to this, I would like to have a different form with a fixed > > with multi-column layout; for this form, no input field must be wider > > than 40 characters. Somehow I have to tell the fields not to make > > themselves wider than 40 characters, and not just use the maximum > > length. > > > Again, what it boils down to is the desire to be able to have > > different representations for a single record, and to have different > > possible representations for each field. This while maintaining as > > much encapsulation as possible. > > Well for both mapper and record you have the toForm function which is > per field thus allows you to represent the field in any way you like: > your own Node, augment the default node with new attributes etc. And > your implementation can of choose the layout based on your own > context. > > > > > Hence my original idea to have fields provide representation hints > > (eg. "I'd like to be 80 characters wide"), and then have another > > "something" that uses these hints for the actual output, while > > potentially adding additional hints/constrains (eg. "No one get's more > > than 40 characters"), css directives, a little red star in front of > > mandatory fields (based on a rendering hint), Depending on how > > the record is being displayed, I would use a different "something", > > and neither the record nor the fields would have to know anything > > about "application context". > > Well since you can override the toForm for each field you can add your > own "something" to it. Thus you can work with necessary abstractions > to make the field "unaware" of the "application context" if that's > what you want but it feels to me that this is an application specific > concern and not a framework one. Personally if I'd need to render a > record/field in different layouts using mapper I'd probably make the > fields aware of the context in which they need to render themselves. > Context is good ! :) > > > > > If I then had a default "something", which renders fields the way they > > are rendered right now, and have the various record fields > > (StringField, etc.) call upo
[Lift] Re: horizontal navbar drop-downs
Derek let me know if you want to own this ... otherwise I'll take it if no one else claims it ... after I'm added to the "magic" owner list on lighthouse :D On Mar 19, 7:04 pm, Derek Chen-Becker wrote: > Added a ticket for the enhancement: > > http://liftweb.lighthouseapp.com/projects/26102/tickets/24-create-lif... > > Derek > > On Thu, Mar 19, 2009 at 11:59 AM, Derek Chen-Becker > wrote: > > > Cool! If Dan can share some code that would help, but in any case I don't > > think this is going to be a huge chunk of code. > > > Derek > > > On Thu, Mar 19, 2009 at 11:52 AM, David Pollak < > > feeder.of.the.be...@gmail.com> wrote: > > >> On Thu, Mar 19, 2009 at 9:50 AM, marius d. wrote: > > >>> I'm wondering if we shouldn't provide this by the means of a Lift > >>> widget. Looks like a needed feature ... > > >>> WDYT ? > > >> Sounds good to me. > > >>> Br's, > >>> Marius > > >>> On Mar 19, 6:43 pm, David Pollak > >>> wrote: > >>> > On Thu, Mar 19, 2009 at 9:30 AM, Derek Chen-Becker < > >>> dchenbec...@gmail.com>wrote: > > >>> > > This is something that has been asked before, but I don't think there > >>> was > >>> > > anything out there. I think that this would be a really nice feature, > >>> > > particularly if it could leverage the existing jQuery stuff. IIRC, > >>> the > >>> > > built-in Menu snippet doesn't render children at all unless the > >>> parent is > >>> > > the current selected page, so we would have to either modify that or > >>> we > >>> > > could code up a new MenuBar snippet that renders a "bar" instead of a > >>> UL > >>> > > like the current one. > > >>> > There's a way to ask for the entire menu rather than just the current > >>> view. > >>> > Dan O'Leary from Enthiosys did this for Innovation Games Online. I've > >>> > pinged him to see if he can share some of the code. > > >>> > > Derek > > >>> > > On Thu, Mar 19, 2009 at 10:21 AM, DavidV >>> >wrote: > > >>> > >> I'm wondering if there is a built-in way to create drop-down menus > >>> > >> from a horizontal navbar using the Menu.builder method. These are > >>> the > >>> > >> relevant sections of my current template: > > >>> > >> My Title > >>> > >> > >>> > >> > >>> > >> > >>> > >>
[Lift] Re: horizontal navbar drop-downs
Yeah I did ... thanks. On Mar 19, 9:34 pm, Timothy Perrett wrote: > @marius: > > You might want to ping Debby, as I belive she setup the lighthouse account > for Lift... Perhaps she is the gate keeper? > > Cheers, Tim > > On 19/03/2009 19:30, "Derek Chen-Becker" wrote: > > > > > Feel free to take it when we let you ;). > > > On Thu, Mar 19, 2009 at 1:16 PM, marius d. wrote: > > >> Derek let me know if you want to own this ... otherwise I'll take it > >> if no one else claims it ... after I'm added to the "magic" owner list > >> on lighthouse :D > > >> On Mar 19, 7:04 pm, Derek Chen-Becker wrote: > >>> > Added a ticket for the enhancement: > > >>> >http://liftweb.lighthouseapp.com/projects/26102/tickets/24-create-lif... > > >>> > Derek > > >>> > On Thu, Mar 19, 2009 at 11:59 AM, Derek Chen-Becker > >>> > wrote: > > >>>> > > Cool! If Dan can share some code that would help, but in any case I > >>>> don't > >>>> > > think this is going to be a huge chunk of code. > > >>>> > > Derek > > >>>> > > On Thu, Mar 19, 2009 at 11:52 AM, David Pollak < > >>>> > > feeder.of.the.be...@gmail.com> wrote: > > >>>>> > >> On Thu, Mar 19, 2009 at 9:50 AM, marius d. > >>>>> wrote: > > >>>>>> > >>> I'm wondering if we shouldn't provide this by the means of a Lift > >>>>>> > >>> widget. Looks like a needed feature ... > > >>>>>> > >>> WDYT ? > > >>>>> > >> Sounds good to me. > > >>>>>> > >>> Br's, > >>>>>> > >>> Marius > > >>>>>> > >>> On Mar 19, 6:43 pm, David Pollak > >>>>>> > >>> wrote: > >>>>>>> > >>> > On Thu, Mar 19, 2009 at 9:30 AM, Derek Chen-Becker < > >>>>>> > >>> dchenbec...@gmail.com>wrote: > > >>>>>>>> > >>> > > This is something that has been asked before, but I don't > >>>>>>>> think there > >>>>>> > >>> was > >>>>>>>> > >>> > > anything out there. I think that this would be a really > >>>>>>>> > >>> > > nice > feature, > >>>>>>>> > >>> > > particularly if it could leverage the existing jQuery > >>>>>>>> > >>> > > stuff. > IIRC, > >>>>>> > >>> the > >>>>>>>> > >>> > > built-in Menu snippet doesn't render children at all unless > the > >>>>>> > >>> parent is > >>>>>>>> > >>> > > the current selected page, so we would have to either > >>>>>>>> > >>> > > modify > that or > >>>>>> > >>> we > >>>>>>>> > >>> > > could code up a new MenuBar snippet that renders a "bar" > >>>>>>>> instead of a > >>>>>> > >>> UL > >>>>>>>> > >>> > > like the current one. > > >>>>>>> > >>> > There's a way to ask for the entire menu rather than just the > current > >>>>>> > >>> view. > >>>>>>> > >>> > Dan O'Leary from Enthiosys did this for Innovation Games > >>>>>>> Online. I've > >>>>>>> > >>> > pinged him to see if he can share some of the code. > > >>>>>>>> > >>> > > Derek > > >>>>>>>> > >>> > > On Thu, Mar 19, 2009 at 10:21 AM, DavidV > >>>>>>>> >>>>>>> > >>> >wrote: > > >>>>>>>>> > >>> > >> I'm wondering if there is a built-in way to create > >>>>>>>>> drop-down menus > >>>>>>>>> > >>> > >> from a horizontal navbar using the Menu.builder method. > These are > >>>>>> > >>> the > >>>>>>>>> > >>> > >> relevant sections of my current template: > > >>>>>>>>> > >>> > >> My Title > >>>>>>>>> > >>> > >> > >>>>>>>>> > >>> > >> > >>>>>>>>> > >>> > >>
[Lift] Re: Lift as a UI in server side OSGi
Hi Chad, On Mar 19, 9:45 pm, chad skinner wrote: > I am trying to redesign our web applications into a more services / > component based system that would allow us to add features without > having to worry about breaking other components. I have been > investigating OSGi as a framework utilizing EJB3 and JPA. So far I > have (at least I believe) all of my EJBs and Entities deploying in the > OSGi container. The primary issue I have to address now is how to > handle authentication and the User Interface (we are currently using > JSF, but it has not been a good fit for our applications) and during > some reading I ran across the Lift Framework and am impressed so far, > but was wondering if anyone has any ideas on how it could be > integrated into OSGi applications? Personally I'm not experienced with OSGi but Lift is exposed to the JEE web container using a Servlet filter, not a servlet per se and AFAIK to the OSGi HttpService one can only register a servlet.LiftServlet class is A HttpServlet but I don;t think that this would help you much as critical operations are done in the LiftFilter class. > > Would it be possible to create a servlet that would register itself > with OSGi as handling all http requests. Then have a bundle that > implements a service interface containing methods that determine if > the bundle can handle a requested URI, and a method that the > controller can call to delegate the request. This delegation process I > believe to be entirely possible however I am not certain how this > would play well with the Lift Framework. Well Lit's controllers are essentially functions and partial functions.I think that in order to have a Lift Servlet usable in this context would require a bit of changes in Lift. In fact OSGi integration has been discussed before if I remember correctly but never materialized mostly due to other priorities. >For this to work, I would > need to have an OSGi activator that could initialize and destroy the > Lift configuration when the bundle is activated or deactivated (I > believe this would be similar to the initialization and destruction > processes in the Lift Filter. > > One issue is whether or not it is possible to have multiple lift > instances running as you will have multiple bundles each with its own > snippets and templates and these may need to be able to access the > templates from other services. If and only if each registered servlet is loaded by a separate class- loader (unrelated in the delegation chain) that should be possible otherwise because Lift is using Scala objects such as LiftRules there are no boundaries so there can not be separate LiftRules etc.AFAIK each OSGi bundle is loaded by its own classloader. Am I wrong ? > > Our system uses a series of nested services and I am trying to figure > out how I can register the servlets in a hierarchal fashion without > knowing what context the parent bundle’s servlets are registered. For > example, The profile may register is servlets under /profile, but the > blog that adds functionality to the profile would register itself with > the profile under /blog. The issue is that profile injects a couple of > elements into the path so that /profile/private/blog shows the owner/ > administrator view of the blog, but /profile//blog shows the > public representation of the blog. The only way I can figure out how > to make this work is to use delegation. > > Does anyone know if it is possible to setup lift in an OSGi bundle > activator and then have another servlet delegate the calls to the Lift > framework? Also, does anyone have any thoughts on how security could > be implemented in a dynamic situation like this? Lastly, if this is > possible, is this a good approach or if there are better solutions? IMHO Lift's integration in OSGi needs some work that is definitely worthwhile. > > I have been trying to get my thoughts down in words for a few days and > am not certain that I have done a good job of explaining what I am > thinking, but any thoughts or questions would be appreciated. All these are very interested things but to make it happen I think: 1. Make proper isolation for Lift to be properly initialized without a Lift Filter (not sure if OSGi will support registering filters any time soon). Thus one can have different context paths ... essentially different Lift apps registered 2. Test, test, test ... One thought though .. you mentioned that you'd want to use different context /profile, /blog etc. For that you don't actually need different LiftServlet .. just a single Lift servlet registered to the ROOT "/" context and let Lift manage the other paths /profile, / blog, ... etc. > > Thanks, > Chad --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more optio
[Lift] Re: Lift Web, why no download of a zipped archive on the website?
I guess it would be beneficial for the zip to contain the built artifacts such as http://scala-tools.org/hudson/job/lift/643/ ... and a little script that would push them into the local maven repository ? Br's, Marius On Mar 19, 10:34 pm, BerlinBrown wrote: > http://liftweb.net/download.html > > Call me old fashion, but why can't there simply be a download on the > download page? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Charles Munat to the Lift committers
Welcome Charles ... I know I'm on the list of people that always thought you're already a committer ... so now my confusion is gone ! Glad to have you on board and not "over" it :) On Mar 20, 9:49 pm, David Pollak wrote: > Folks, > I am pleased to welcome Charles Munat to the list of Lift committers. Now, > many of you, including some other Lift committers, look at Charles' > contribution to Lift and the community and say, "yeah, he's a committer." > Well, now he is. > > Welcome Charles! > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: horizontal navbar drop-downs
Derek if you want to build menu the widget by all means go ahead. I just don't want to duplicate the effort by having us work on the same thing. (If you do please update the ticket owner) Br's, Marius On Mar 20, 5:48 pm, Derek Chen-Becker wrote: > Sure, I'll bundle it as part of the widgets module along with some code do > handle the nitty-gritty of emitting the full menu and enabling superfish. > > Derek > > On Fri, Mar 20, 2009 at 9:30 AM, David Pollak > > wrote: > > > On Fri, Mar 20, 2009 at 12:45 AM, Charles F. Munat wrote: > > >> It doesn't say anything about licensing on the site, but it's a jQuery > >> plugin. I presume that if we can bundle jQuery, we can bundle Superfish. > > > Sounds reasonable. However, I'd prefer not to bundle it with Lift webkit, > > but make it like the other widgets. > > >> Chas. > > >> Derek Chen-Becker wrote: > >> > That's awesome. Are there restrictions that would prevent us from just > >> > including the superfish script file (and CSS) as part of a widget? It > >> > looks like it wants ULs anyways, which is what Lift already outputs. > >> > From what DPP said, it should be easy to dump the entire menu as a full > >> > UL (with nesting), in which case it really is just adding the > >> > appropriate
[Lift] Re: Menu widget
Similar approach yes, duplicate not quite. It just utilizes that the API provided by SiteMap, MenuItem etc. and walks through a tree structure and build / constructs. We could make the SiteMap to be self aware of rendering itself to / constructs but personally I don't really see this as being necessary. Nonetheless if there are compelling reasons to do so I'd like to know them. ... I like things do be decoupled and SIteMap is expressive enough to represent it in so many ways, Br's, Marius On Mar 21, 3:51 pm, Derek Chen-Becker wrote: > Awesome! It looks like you did end up having to essentially duplicate the > code in the builtin Menu.builder snippet method to get this working. When I > was looking at it I thought that it might be nice to have a general way of > making the builtin Menu snippet just render the whole tree in case anyone > else wants to use it (for a site navigation page, etc). I was thinking that > we could add an optional parameter that would essentially do that, then you > could just have the snippet look like: > > > > Or something. I suppose it's a pretty small chunk of code, but if someone > else wants to do something similar it means they have to copy it all over. > > Thoughts? > > Derek > > On Sat, Mar 21, 2009 at 3:44 AM, Marius wrote: > > > Folks, > > > I just committed the menu widget. Now the Widgets test site uses this > > widget instead of the traditional builtin menu. You can also specify > > the style of the menu using MenuStyle.HORIZONTAL, MenuStyle.VERTICAL > > and MenuStyle.NAVBAR. > > > All these thanks to superfish jquery plugin > >http://users.tpg.com.au/j_birch/plugins/superfish/ > > > Oh you can also customize the superfish plugin by specifying the JsObj > > to set the properties. > > > Thoughts/suggestions ? > > > Br's, > > Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Menu widget
I think I am aware what you meant ... If you want to make SiteMap to
know how to render itself as / hence "centralize" this fine by
me. I have nothing against it, I just don't see the need ... the good
news is that it may be just me ;)
The analogy with chooseTemplate is not very relevant IMHO because
choseeTemplate is a construct that one can use in many application
context whereas SiteMap is typically only one. But by all means don't
let me stay in your way:)
If you are implementing this in SIteMap then perhaps you should make
both Menu built in snippet and MenuWidget to use it?
Br's,
Marius
On Mar 21, 5:41 pm, Derek Chen-Becker wrote:
> Sorry, what I mean is that the builtin Menu snippet code is duplicated, not
> SiteMap. For instance, here's how the builtin snippet generates the ULs:
>
> S.request.map(_.buildMenu.lines.toList match {
> case Nil => List(Text("No Navigation Defined."))
> case xs =>
> val liMap = S.prefixedAttrsToMap("li")
> val li = S.mapToAttrs(liMap)
>
> def buildANavItem(i: MenuItem) = {
> i match {
> case MenuItem(text, uri, kids, true, _, _) =>
> ({text}{buildUlLine(kids)}) %
> S.prefixedAttrsToMetaData("li_item", liMap)
> case MenuItem(text, uri, kids, _, true, _) =>
> ({text}{buildUlLine(kids)}) %
> S.prefixedAttrsToMetaData("li_path", liMap)
> case MenuItem(text, uri, kids, _, _, _) =>
> ({text}{buildUlLine(kids)} % li)
> }
> }
>
> def buildUlLine(in: Seq[MenuItem]): Node = if (in.isEmpty)
> Text("")
> else {in.flatMap(buildANavItem)} %
> S.prefixedAttrsToMetaData("ul")
>
> buildUlLine(xs)
>
> })
>
> And here's the new code you put together:
>
> private def buildMenu(kids: Seq[MenuItem]): Elem = {
> {
> for (m <- kids) yield {
> {
> {m.text} ++ (m.kids.isEmpty match {
> case true => NodeSeq.Empty
> case _ => buildMenu(m.kids)
> })
> }
> }
> }
> }
>
> What you've written is very similar, albeit without some of the attribute
> handling, etc. I was just saying that if someone else comes along and finds
> a need for fully expanding SiteMap into nested ULs, then they have to write
> similar code again. It's a fairly small snippet of code, but I don't know
> that that's really an argument against providing it as a general mechanism.
> I mean, chooseTemplate is just a few lines, but we include it because it's
> useful. I would be happy to make changes to the builtin Menu snippet on a
> new branch to show what I mean if you'd like.
>
> Derek
>
> On Sat, Mar 21, 2009 at 8:22 AM, marius d. wrote:
>
> > Similar approach yes, duplicate not quite. It just utilizes that the
> > API provided by SiteMap, MenuItem etc. and walks through a tree
> > structure and build / constructs.
>
> > We could make the SiteMap to be self aware of rendering itself to /
> > constructs but personally I don't really see this as being
> > necessary. Nonetheless if there are compelling reasons to do so I'd
> > like to know them. ... I like things do be decoupled and SIteMap is
> > expressive enough to represent it in so many ways,
>
> > Br's,
> > Marius
>
> > On Mar 21, 3:51 pm, Derek Chen-Becker wrote:
> > > Awesome! It looks like you did end up having to essentially duplicate the
> > > code in the builtin Menu.builder snippet method to get this working. When
> > I
> > > was looking at it I thought that it might be nice to have a general way
> > of
> > > making the builtin Menu snippet just render the whole tree in case anyone
> > > else wants to use it (for a site navigation page, etc). I was thinking
> > that
> > > we could add an optional parameter that would essentially do that, then
> > you
> > > could just have the snippet look like:
>
> > >
>
> > > Or something. I suppose it's a pretty small chunk of code, but if someone
> > > else wants to do something similar it means they have to copy it all
> > over.
>
> > > Thoughts?
>
> > > Derek
>
> > > On Sat, Mar 21, 2009 at 3:44 AM, Marius wrote:
>
> > > > Folks,
>
> > > > I just committed the menu widget. Now the Widgets test site uses this
> > > > widget instead of the traditional builtin menu. You can also specify
> > > > th
[Lift] Re: Menu widget
Not sure what to say about having the MenuWidget depending on the
builtin Menu snippet. But go ahead ...
On Mar 21, 6:22 pm, Derek Chen-Becker wrote:
> I think I'm not being very clear. I'm going to modify the builtin Menu
> snippet, not SiteMap. In my view, SiteMap should not be concerned with how
> it's rendered, but the builtin snippet surely should be able to handle this.
> Once I have the Menu snippet modified, the MenuWidget class would just embed
> a tag where it wants the menu. I'll
> work on it this weekend and let you know when I have something usable.
>
> Derek
>
> On Sat, Mar 21, 2009 at 10:01 AM, marius d. wrote:
>
> > I think I am aware what you meant ... If you want to make SiteMap to
> > know how to render itself as / hence "centralize" this fine by
> > me. I have nothing against it, I just don't see the need ... the good
> > news is that it may be just me ;)
>
> > The analogy with chooseTemplate is not very relevant IMHO because
> > choseeTemplate is a construct that one can use in many application
> > context whereas SiteMap is typically only one. But by all means don't
> > let me stay in your way:)
>
> > If you are implementing this in SIteMap then perhaps you should make
> > both Menu built in snippet and MenuWidget to use it?
>
> > Br's,
> > Marius
>
> > On Mar 21, 5:41 pm, Derek Chen-Becker wrote:
> > > Sorry, what I mean is that the builtin Menu snippet code is duplicated,
> > not
> > > SiteMap. For instance, here's how the builtin snippet generates the ULs:
>
> > > S.request.map(_.buildMenu.lines.toList match {
> > > case Nil => List(Text("No Navigation Defined."))
> > > case xs =>
> > > val liMap = S.prefixedAttrsToMap("li")
> > > val li = S.mapToAttrs(liMap)
>
> > > def buildANavItem(i: MenuItem) = {
> > > i match {
> > > case MenuItem(text, uri, kids, true, _, _) =>
> > > ({text}{buildUlLine(kids)}) %
> > > S.prefixedAttrsToMetaData("li_item", liMap)
> > > case MenuItem(text, uri, kids, _, true, _) =>
> > > ({text}{buildUlLine(kids)}) %
> > > S.prefixedAttrsToMetaData("li_path", liMap)
> > > case MenuItem(text, uri, kids, _, _, _) =>
> > > ({text}{buildUlLine(kids)} %
> > li)
> > > }
> > > }
>
> > > def buildUlLine(in: Seq[MenuItem]): Node = if (in.isEmpty)
> > > Text("")
> > > else {in.flatMap(buildANavItem)} %
> > > S.prefixedAttrsToMetaData("ul")
>
> > > buildUlLine(xs)
>
> > > })
>
> > > And here's the new code you put together:
>
> > > private def buildMenu(kids: Seq[MenuItem]): Elem = {
> > > {
> > > for (m <- kids) yield {
> > > {
> > > {m.text} ++ (m.kids.isEmpty match {
> > > case true => NodeSeq.Empty
> > > case _ => buildMenu(m.kids)
> > > })
> > > }
> > > }
> > > }
> > > }
>
> > > What you've written is very similar, albeit without some of the attribute
> > > handling, etc. I was just saying that if someone else comes along and
> > finds
> > > a need for fully expanding SiteMap into nested ULs, then they have to
> > write
> > > similar code again. It's a fairly small snippet of code, but I don't know
> > > that that's really an argument against providing it as a general
> > mechanism.
> > > I mean, chooseTemplate is just a few lines, but we include it because
> > it's
> > > useful. I would be happy to make changes to the builtin Menu snippet on a
> > > new branch to show what I mean if you'd like.
>
> > > Derek
>
> > > On Sat, Mar 21, 2009 at 8:22 AM, marius d.
> > wrote:
>
> > > > Similar approach yes, duplicate not quite. It just utilizes that the
> > > > API provided by SiteMap, MenuItem etc. and walks through a tree
> > > > structure and build / constructs.
>
> > > > We could make the SiteMap to be self aware of rendering itself to /
> > > > constructs but personally I don't really see this as being
> > > > necessary. Nonetheless if there are compelling reasons to do so I'd
> >
[Lift] Re: Menu widget
Good point ... perhaps put it on the Lift online demo application? Br's, Marius On Mar 21, 6:29 pm, James Matlik wrote: > Is there a running version of the widgets site online, or is this only > available in source format? It would be nice to have something like this > linked to the liftweb home page or wiki for people to test drive these > features at zero cost. I did a quick look there and didn't find anything of > the kind. > > On Sat, Mar 21, 2009 at 5:44 AM, Marius wrote: > > > Folks, > > > I just committed the menu widget. Now the Widgets test site uses this > > widget instead of the traditional builtin menu. You can also specify > > the style of the menu using MenuStyle.HORIZONTAL, MenuStyle.VERTICAL > > and MenuStyle.NAVBAR. > > > All these thanks to superfish jquery plugin > >http://users.tpg.com.au/j_birch/plugins/superfish/ > > > Oh you can also customize the superfish plugin by specifying the JsObj > > to set the properties. > > > Thoughts/suggestions ? > > > Br's, > > Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Menu widget
Cool ... if you tested it and the MenuWidget, from my perspective it
is good to go into master. And it's really great that you added the
ScalaDocs !!!
Br's,
Marius
On Mar 23, 6:07 pm, Derek Chen-Becker wrote:
> OK, I've pushed the new code on the wip-dcb-dropdown branch. I made some
> minor mods to the builtin Menu snippet (and changes to the Menu widget to
> match):
>
> 1. Added an "expandAll" attribute that renders the entire SiteMap.
> 2. Added a new "top" prefix to the builder snippet to allow for
> attributes on the top-level menu UL element.
> 3. Added API documentation to the Menu class.
>
> For some reason, the branch isn't showing up on github. I did a
>
> git push origin wip-dcb-dropdown
>
> And it says it's up-to-date, but I'm not seeing it on github.
>
> Derek
>
> On Sat, Mar 21, 2009 at 3:04 PM, Charles F. Munat wrote:
>
>
>
> > +1
>
> > I am understanding exactly what you have in mind and think it's a great
> > idea. I wrote some kludgy code months ago (I knew zero about Scala back
> > then -- now I know *infinity* times more! :-) to do pretty much the same
> > thing, and I ended up completely rewriting the Menu snippet to my own
> > needs. More flexibility == good, I think.
>
> > Chas.
>
> > (For anyone a little slow on the uptake this fine Saturday, please note
> > that anything times zero is still zero.)
>
> > Derek Chen-Becker wrote:
> > > I think I'm not being very clear. I'm going to modify the builtin Menu
> > > snippet, not SiteMap. In my view, SiteMap should not be concerned with
> > > how it's rendered, but the builtin snippet surely should be able to
> > > handle this. Once I have the Menu snippet modified, the MenuWidget class
> > > would just embed a tag where it
> > > wants the menu. I'll work on it this weekend and let you know when I
> > > have something usable.
>
> > > Derek
>
> > > On Sat, Mar 21, 2009 at 10:01 AM, marius d. > > <mailto:marius.dan...@gmail.com>> wrote:
>
> > > I think I am aware what you meant ... If you want to make SiteMap to
> > > know how to render itself as / hence "centralize" this fine
> > by
> > > me. I have nothing against it, I just don't see the need ... the good
> > > news is that it may be just me ;)
>
> > > The analogy with chooseTemplate is not very relevant IMHO because
> > > choseeTemplate is a construct that one can use in many application
> > > context whereas SiteMap is typically only one. But by all means don't
> > > let me stay in your way:)
>
> > > If you are implementing this in SIteMap then perhaps you should make
> > > both Menu built in snippet and MenuWidget to use it?
>
> > > Br's,
> > > Marius
>
> > > On Mar 21, 5:41 pm, Derek Chen-Becker > > <mailto:dchenbec...@gmail.com>> wrote:
> > > > Sorry, what I mean is that the builtin Menu snippet code is
> > > duplicated, not
> > > > SiteMap. For instance, here's how the builtin snippet generates
> > > the ULs:
>
> > > > S.request.map(_.buildMenu.lines.toList match {
> > > > case Nil => List(Text("No Navigation Defined."))
> > > > case xs =>
> > > > val liMap = S.prefixedAttrsToMap("li")
> > > > val li = S.mapToAttrs(liMap)
>
> > > > def buildANavItem(i: MenuItem) = {
> > > > i match {
> > > > case MenuItem(text, uri, kids, true, _, _) =>
> > > > ({text}{buildUlLine(kids)})
> > %
> > > > S.prefixedAttrsToMetaData("li_item", liMap)
> > > > case MenuItem(text, uri, kids, _, true, _) =>
> > > > ( > > href={uri}>{text}{buildUlLine(kids)}) %
> > > > S.prefixedAttrsToMetaData("li_path", liMap)
> > > > case MenuItem(text, uri, kids, _, _, _) =>
> > > > ( > > href={uri}>{text}{buildUlLine(kids)} % li)
> > > > }
> > > > }
>
> > > > def buildUlLine(in: Seq[MenuItem]): Node = if
> > (in.isEmpty)
> > > > Text("")
> > > > else {in.flat
[Lift] Re: [ANN] Exploring Lift: a Book for the Scala-based Web Framework
LOL ... but damn right. At this point I can only wholeheartedly thanks David and each and every committer for Lift's existence. Br's, Marius On Mar 23, 11:22 pm, Viktor Klang wrote: > On Mon, Mar 23, 2009 at 10:16 PM, David Pollak < > > feeder.of.the.be...@gmail.com> wrote: > > > On Mon, Mar 23, 2009 at 2:14 PM, Viktor Klang wrote: > > >> Guys, > > >> I'm expecting a signed copy... ;) > > > Who's the father? :-) > > You are the daddy. ;) > > > > > > >> On Mon, Mar 23, 2009 at 7:24 PM, TylerWeir wrote: > > >>> Dave Griffith wrote: > > >>> > Garrett Rowe-2 wrote: > > >>> >> I'll be buying the e-version of the book today. > > >>> > Me too, or, more precisely, I'll be buying it whenever APress actually > >>> > lets people purchase the e-book. The publication date says April, but > >>> > until then will the book be available as beta? > > >>> I'll post again when I know dates. Thanks for the patience. > >>> -- > >>> View this message in context: > >>>http://www.nabble.com/-ANN---Exploring-Lift%3A-a-Book-for-the-Scala-b... > >>> Sent from the Scala - User mailing list archive at Nabble.com. > > >> -- > >> Viktor Klang > >> Senior Systems Analyst > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > -- > Viktor Klang > Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: State and binding
The foo reference is captured in checkAndSave which is saved on
LiftSession in function mapping.
Br's,
Marius
On Mar 24, 10:23 am, Alex wrote:
> If I have this in a (not Stateful) Snippet, is the checkAndSave
> closure saving state on the server? Where is the reference to foo
> saved?
>
> def add(form: NodeSeq) : NodeSeq = {
> val foo = Foo.create
> def checkAndSave(): Unit = foo.validate match {
> case Nil => foo.save ; S.notice("Started foo: " + foo.body)
> case xs => S.error(xs) ; S.mapSnippet("Foo.add", doBind)
> }
> def doBind(form: NodeSeq) =
> bind("foo", form,
> "body" -> foo.body.toForm,
> "submit" -> submit("Submit", checkAndSave))
>
> doBind(form)
> }
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Build Comet applications using Scala, Lift, and jQuery
Outstanding and congrats ! On Mar 24, 4:42 pm, Michael wrote: > http://www.ibm.com/developerworks/ajax/tutorials/wa-aj-comet/ > > Thanks to Jorge and David for helping me out with the CometActors. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: State and binding
On Mar 24, 6:53 pm, Alex wrote:
> Perhaps this debate has been had before but I didn't see it. I have a
> feeling this might be contentious.
>
> Doesn't this violate the basic tenet that you should not use server
> side state when you don't have to?
No. As long as you are binding a function we are talking about state.
> There is no reason for instance
> when someone is submitting a news group posting to bind an empty
> posting in a closure and store it on the server, thereby breaking the
> application in any number of cases:
>
> 1) The session times out because the user got distracted or lost their
> connection temporarily
> 2) The user abuses the back button
> 3) The server fails over (assuming there is no memory replication)
> 4) There is a temporary connection failure and the user reloads
> 5) The server is restarted
I don't see how that would break the application. The function mapping
is cleared is the session times out or it is terminated. Furthermore
Lift has a garbage collection mechanism that removes the functions
that are not utilized.
None of the above cases breaks a Lift application ... if the
application itself is correctly designed and implemented. If we are
talking about clustered applications Lift currently uses sticky
sessions mechanism meaning that all requests pertaining to a given
session are processed by the same node. This can be easily ensured by
load balancing rules. If a node breaks part of the conversation state
can be ensured by application design when processed by a different
node ...of course in the context of a different HttpSession.
>
> All of the above cases are recoverable with what, IMO, are properly
> designed frameworks that minimize server-side state. Those are the
> things that taught us state should be stored in the client whenever
> possible.
Yes and no. I agree with state minimization but adding burden to
client side doesn't solve much in many cases. With Lift and Scala we
are leveraging functions and partial functions to process requests. If
you want that bad purely stateless handling you can also do that with
Lift. Please see LiftRules.statelessDispatchTable.
>
> I saw a bit of a discussion distinguishing REST from human
> interaction, saying human interactions are not stateless, but that
> does not excuse the application being so vulnerable to breakage.
I still don't get where your vulnerability comes from.
>
> This reminds me of why I dislike many ASP applications I've used -
> they always break when users don't behave well or when some kicks a
> server - and users, myself included, always misbehave. I use the back
> button when I shouldn't, I leave forms half filled out when I answer
> the phone, and as a frequent traveler I tend to use web applications
> from places with shoddy internet. I also don't like to lose my work
> when a server fails over or is restarted.
With a bit of care for design this can be taken care. For instance if
you have an Ajax form and the request fails, Lift will try to resend
that ... if the retry request qoes to a new node then we are talking
about the application design if the application has enough contextual
information to handle that or not. Such as in forms that do not
require logged in users (i.e. posting a comment on a blog or forum as
anonymous) the application can safely process the form request in the
context of a new HttpSession/LiftSession.
>
> There may be a few gains from designing things the lift way -
> simplicity, security, etc - but they seem to come at too great a cost.
What is this "great cost" ... one can write poor designed applications
in any language or framework on this Earth (dunno about other
planets). A framework can only do so much but it does not guarantee
flawless applications.
>
> There maybe some solutions to this, such as serialization of this data
> to the client, but I'm not sure I like any of them.
That would be a performance killer.
>
> -Alex
>
> On Mar 24, 2:46 am, "marius d." wrote:
>
> > The foo reference is captured in checkAndSave which is saved on
> > LiftSession in function mapping.
>
> > Br's,
> > Marius
>
> > On Mar 24, 10:23 am, Alex wrote:
>
> > > If I have this in a (not Stateful) Snippet, is the checkAndSave
> > > closure saving state on the server? Where is the reference to foo
> > > saved?
>
> > > def add(form: NodeSeq) : NodeSeq = {
> > > val foo = Foo.create
> > > def checkAndSave(): Unit = foo.validate match {
> > > case Nil => foo.save ; S.notice("Started foo: " + foo.body)
> > > case xs => S.error(xs) ; S.mapSnippet("Foo.add", doBind)
> > > }
> > > def doBin
[Lift] Re: Adding / Updating a JsObj
Please see def props: List[(String,JsExp)] and def +*(other: JsObj) would this suffice ? +* looks like an awkward name to me ... ++ expresses concatenation better IMHO. Br's, Marius On Mar 24, 8:36 pm, Tim Perrett wrote: > Hey guys, > > So, I have a JsObj with a bunch of key-value pairs - how can I both > add new key pairs or update existing values? > > I originally had my data being held as Map[String,String], and > attempted to convert it to JsObj however this was for some reason > causing a massive memory leak which nearly crashed my entire mac. lol. > > Thoughts? > > Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Adding / Updating a JsObj
oops typo Perreyt = Perrett :D
On Mar 24, 10:15 pm, "marius d." wrote:
> On Mar 24, 9:46 pm, Timothy Perrett wrote:
>
> > Hmm, it seems like this is not enough as lists do not care for keys.
>
> A valid JSON structure allows multiple properties with the same name
> such as:
>
> var x = {
> name: "Perreyt",
> name: "Tim"
>
> }
>
> ... guess what alert(x.name) displays :) ?
>
> The props function returns a List[(String, JxExp)] which you can
> iterate over
>
> The +* function allows you to concatenate the props of two JsObj.
>
> > In my use case, im actually building a library for something that
> > provide default options that are inserted into a flash object. So,
> > given:
>
> > { key: 'value', something: 'else' }
>
> > I *need* to only have one of the "something" key, as it has a bearing
> > on the application. If someone wants to change / override the default
> > value in there client application, this is extremely difficult - seems
> > like it would need a lot of boilerplate code to convert to list, hack
> > about in the list, then manually convert it back to JsObj.
>
> Not difficult but not convenient either such as:
>
> def update(name: String, newVal: JsExp, obj: JsObj) = (for (found <-
> obj.props if found._1 != name) yield found) ::: List(name, newVal)
>
> which return the new List ... which is suboptimal comparing with a
> Map.
>
> >Can we not
> > add some support for Map[String, JsExp] and going to to/from JsObj?
> > IMO, it seems like its a natural fit given the key-pair nature of
> > JsObj.
>
> Personally I'm fine with a Map[String, JxExp] instead of List because
> if we have the same property multiple times in a JSON construct the
> last occurrence "wins".
>
>
>
> > Thoughts?
>
> > Cheers, Tim
>
> > On Mar 24, 7:10 pm, Timothy Perrett wrote:
>
> > > Hmm, I saw those methods but they are not documented so didnt know
> > > what they did!
>
> > > Will +* replace an object thats the same?
>
> > > On Mar 24, 6:45 pm, "marius d." wrote:
>
> > > > Please see
>
> > > > def props: List[(String,JsExp)]
>
> > > > and
>
> > > > def +*(other: JsObj)
>
> > > > would this suffice ?
>
> > > > +* looks like an awkward name to me ... ++ expresses concatenation
> > > > better IMHO.
>
> > > > Br's,
> > > > Marius
>
> > > > On Mar 24, 8:36 pm, Tim Perrett wrote:
>
> > > > > Hey guys,
>
> > > > > So, I have a JsObj with a bunch of key-value pairs - how can I both
> > > > > add new key pairs or update existing values?
>
> > > > > I originally had my data being held as Map[String,String], and
> > > > > attempted to convert it to JsObj however this was for some reason
> > > > > causing a massive memory leak which nearly crashed my entire mac. lol.
>
> > > > > Thoughts?
>
> > > > > Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Adding / Updating a JsObj
On Mar 24, 9:46 pm, Timothy Perrett wrote:
> Hmm, it seems like this is not enough as lists do not care for keys.
A valid JSON structure allows multiple properties with the same name
such as:
var x = {
name: "Perreyt",
name: "Tim"
}
... guess what alert(x.name) displays :) ?
The props function returns a List[(String, JxExp)] which you can
iterate over
The +* function allows you to concatenate the props of two JsObj.
> In my use case, im actually building a library for something that
> provide default options that are inserted into a flash object. So,
> given:
>
> { key: 'value', something: 'else' }
>
> I *need* to only have one of the "something" key, as it has a bearing
> on the application. If someone wants to change / override the default
> value in there client application, this is extremely difficult - seems
> like it would need a lot of boilerplate code to convert to list, hack
> about in the list, then manually convert it back to JsObj.
Not difficult but not convenient either such as:
def update(name: String, newVal: JsExp, obj: JsObj) = (for (found <-
obj.props if found._1 != name) yield found) ::: List(name, newVal)
which return the new List ... which is suboptimal comparing with a
Map.
>Can we not
> add some support for Map[String, JsExp] and going to to/from JsObj?
> IMO, it seems like its a natural fit given the key-pair nature of
> JsObj.
Personally I'm fine with a Map[String, JxExp] instead of List because
if we have the same property multiple times in a JSON construct the
last occurrence "wins".
>
> Thoughts?
>
> Cheers, Tim
>
> On Mar 24, 7:10 pm, Timothy Perrett wrote:
>
> > Hmm, I saw those methods but they are not documented so didnt know
> > what they did!
>
> > Will +* replace an object thats the same?
>
> > On Mar 24, 6:45 pm, "marius d." wrote:
>
> > > Please see
>
> > > def props: List[(String,JsExp)]
>
> > > and
>
> > > def +*(other: JsObj)
>
> > > would this suffice ?
>
> > > +* looks like an awkward name to me ... ++ expresses concatenation
> > > better IMHO.
>
> > > Br's,
> > > Marius
>
> > > On Mar 24, 8:36 pm, Tim Perrett wrote:
>
> > > > Hey guys,
>
> > > > So, I have a JsObj with a bunch of key-value pairs - how can I both
> > > > add new key pairs or update existing values?
>
> > > > I originally had my data being held as Map[String,String], and
> > > > attempted to convert it to JsObj however this was for some reason
> > > > causing a massive memory leak which nearly crashed my entire mac. lol.
>
> > > > Thoughts?
>
> > > > Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Adding / Updating a JsObj
On Mar 24, 10:27 pm, Timothy Perrett wrote: > Hey Marius, > > > Not difficult but not convenient either such as: > > > def update(name: String, newVal: JsExp, obj: JsObj) = (for (found <- > > obj.props if found._1 != name) yield found) ::: List(name, newVal) > > I think your exactly right - its doable, but it just feels dirty. > lol. > > > Personally I'm fine with a Map[String, JxExp] instead of List because > > if we have the same property multiple times in a JSON construct the > > last occurrence "wins". > > Do you think we could add this to JsObj? There appears to be a good > rational for it. What do you think? I think you should change the List to mutable Map > > Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift Authentication
On Mar 25, 6:00 pm, David Pollak
wrote:
> On Wed, Mar 25, 2009 at 8:56 AM, Chad Skinner wrote:
>
> > All of our applications are currently using form based authentication in
> > the EJB container .. am I correct that this (Form based authentication) is
> > not supported in Lift?
>
> You are incorrect. Form-based authentication works just fine in Lift.
>
>
>
> > As I see it, After checking the users cookie against the Authentication
> > server I would want to cache the returned User object for a period to
> > prevent hitting the server for each request. The only downfall is that if
> > the user logs out of the authentication server and the cache is not cleared
> > then the user would still be authenticated until the cache expires.
>
> > I may be living in the dark ages, but I did not think you could log a user
> > out using HttpAuthentication short of closing the browser ... is this true?
>
> No. You can stop honoring the authentication provided by HttpAuth. This
> requires server logic rather than a hard-coded auth file.
Actually there might be a way ... no bullet proof though. You can
register a JavaScript listener when the browser is closed :
onbeforeunload. Here you can probably send an Ajax logout call.
>
>
>
>
>
> > On Wed, Mar 25, 2009 at 10:20 AM, Timothy Perrett > > wrote:
>
> >> Further to that example, no doubt someone will laugh at me for using
> >> database access on each request... However this is just an example! In
> >> reality I actually read from an LRU cache to save the database access.
>
> >> Cheers, Tim
>
> >> On 25/03/2009 15:08, "Timothy Perrett" wrote:
>
> >> > Chad,
>
> >> > We have HTTP Basic Auth and HTTP Digest Auth support in Lift. The
> >> > authentication is implemented as a partial function that you implement
> >> > like so:
>
> >> > LiftRules.httpAuthProtectedResource.prepend {
> >> > case (ParsePath("api" :: _, _, _, _)) => Full(AuthRole("admin"))
> >> > }
>
> >> > LiftRules.authentication = HttpBasicAuthentication("lift") {
> >> > case (username, password, req) => {
> >> > User.find(By(User.username, username)) match {
> >> > case Full(user) if user.password.match_?(password) => {
> >> > userRoles(AuthRole("admin"))
> >> > true
> >> > }
> >> > case _ => false
> >> > }
> >> > }
> >> > }
>
> >> > Does that make things clearer for you? Essentially what happens is
> >> > this:
>
> >> > user request (no auth) ==> challenge
> >> > user request (with auth) ==> sucsess (or challenge if incorrect)
>
> >> > HTTP Digest is a lot more complex, if you need info on that, let me
> >> > know.
>
> >> > Thanks
>
> >> > Tim
>
> >> > On Mar 25, 2:42 pm, Chad Skinner wrote:
> >> >> Humm, I am learning something about HttpBasicAuthentication and need to
> >> look
> >> >> into this more. Is this method called for every request ... even before
> >> the
> >> >> user fills out the login form?
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: State and binding
On Mar 25, 3:46 pm, Chad Skinner wrote: > >> Not know much about lift yet and wanting to learn more, what is stored in > >> the server session for a simple application? I am assuming it is used by > >> the > >> binder to store the generated form field names so the submitted fields can > >> be rebound ... what other state does the framework store in it? > > > Any SessionVars are held in Session state. Bindings from HTML elements to > > functions are held in Session state. Bindings between Comet Actors and the > > HTML the represents them in held in Session state. > > Thanks for the information, I believe that the documentation states that > lift has its own session system and that it does not use the servers session > ... if this is true and you are running two redundant servers, will the > servers session replication / clustering copy the Lift session? LiftSession is bound to HTTP session via a Session bridge which essentially is a HttpSessionBindingListener and HttpSessionActivationListener. But besides that LiftSession is managed by a SessionMaster actor.LiftSessions are not replicated among cluster nodes. > > State/session replication in a large cluster can cause problems, but for our > situation I don't see server state as being a problem as long as it is > minimal and replicates in clusters. > > I went to the Colorado Software Summit last year and went to a couple of > presentations by Yan Pujante and was very impressed by what they are doing > at linked-in. He presented a couple of sessions one on OSGi and the issues > they are solving or hoping to solve with it as well as the obstacles they > have encountered. Also, he did a presentation on their new security / > authentication system which was very interesting. One thing he mentioned was > that they were moving to a stateless environment, where the only state that > is maintained is that of the authenticated user object. > > Working for a school district I can say that Linked-in's world is ... well > different ... they have over 400 developers we have 2 ... they have I > believe he said 600 web servers ... we have two. Server state for us ... not > really a problem and I'd be happy if my development is easier, quicker and I > can better meet the needs of our users in a timely fashion. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift Authentication
Hi, Everything said here pretty much covers it. I just want to say the HTTP authentication has pretty much nothing to do with form based authentication. Lift HTTP authentication is based on RFC 2617. Form based authentication is something invented by J(2)EE JSR specs and J(2) EE containers use JAAS to support both. As Derek said using form based auth in Lift is also trivial. Br's, Marius --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Form action URI's
You could use some hidden form fields and have another rewriter in front of you existent one. This will read the hidden params and reconstruct the query string. But it looks to me that changing the action via JS would be easier. Br's, Marius On Mar 26, 9:51 pm, Timothy Perrett wrote: > Sorry, let me be more accurate. Lets say your viewing the following: > > /catalogue?filter=marin&limit=10&page=1 > > I then want a dropdown menu to change ³10² in limit to, say, 20. So I setup > a form, but when it does the POST of course those paramaters are gone and > the URL goes to: > > /catalogue > > Which because my function that calculates the URL is looking for those > filter parameters it bombs out as they are missing when its trying to > evaluate. > > My current thinking is to perhaps use some hidden field which holds the > value of S.uri or something... Im not sure. > > Does that help? > > Cheers, Tim > > On 26/03/2009 19:42, "Derek Chen-Becker" wrote: > > > Are you saying that when you access a page using some GET params, the page > > renders with those params missing in any embedded links? Some more concrete > > code/HTML could help clear this up, since I think I'm missing something. > > There > > is Helpers.appendParams, but I'm not sure if that's what you're talking > > about. > > > Derek > > > On Thu, Mar 26, 2009 at 1:06 PM, Tim Perrett > > wrote: > > >> Guys, > > >> I have a catalogue of products that essentially have a bunch of meta- > >> data attached to them and the user can dynamically drill down into to > >> get a relevant list of products. Because of this query type operation, > >> im using the query string like so: > > >> /catalogue?filter=marin > > >> I know some people don't agree with this, but IMO, its the most REST > >> approach with the rest of the ROA I have in this application (i.e. > >> there is no meaningful relationship between the filter options so it > >> makes no sense to use resource paths) - anyway... to the problem at > >> hand. > > >> I have a function def that calculates links etc taking into account > >> all the various filters and things, and i want a simple "results on a > >> page" type drop-down select. Now, this is fairly simple as i already > >> have the function defined to calculate the url and yes, i know i could > >> calculate the new URL in javascript, but i dont really want to do that > >> as its two lot of code to maintain. When I write a form with lift and > >> bind(...) the action="catalogue" with a post so my server side > >> function bones because the S.params call cant find anything (there are > >> no longer any params). > > >> Any ideas on how one could work around this? > > >> Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: mixinAttributes help
If I may you can also use something like:
bind("f", xhtml,
"query" -> {n: NodeSeq => (for (node <- BindHelpers.currentNode)
yield BindHelpers.mixinAttributes(SHtml.text(query, query = _))(node))
open_! },
"submit" -> SHtml.submit("Submit", processSearch)
)
Query:
the difference is that we passed the id directly to f:query without
duplicating the input tag.
Br's,
Marius
On Mar 27, 3:12 pm, bradford wrote:
> Hi Timothy,
>
> Thanks for your response. After I posted this message I realized that
> JavaRebel failed to reload a class. I restarted the application and
> the code works now. This thread did not appear in the list at that
> time (due to moderation perhaps) so I could not reply to it in time.
>
> Yes, I'm aware that you can set the attributes that way, but I prefer
> to set it in the HTML. I just find it easier to work with CSS that
> way. I guess it's a personal preference. Anyway, mixinAttributes is
> very cool.
>
> Thanks for your help,
> Bradford
>
> On Mar 27, 6:10 am, Timothy Perrett wrote:
>
> > Hi Bradford,
>
> > Can you just elaborate on what your trying to achieve? My assumption
> > is that you want to set the ID of the input field?
> > When your working with lift you dont need to define the input fields
> > in the HTML, only on the serverside.
>
> > Try this:
>
> > bind("f", xhtml,
> > "query" -> SHtml.text(query, query = _) % "id" -> "hello"
> > "submit" -> SHtml.submit("Submit", processSearch)
> > )
> >
> > Query:
> >
> >
>
> > On Mar 27, 2:28 am, bradford wrote:
>
> > > I'm trying to use mixinAttributes, but get a scala.MatchError:
> > > (full error below). I'm using the 1.1 snapshot.
>
> > > bind("f", xhtml,
> > > "query" -> mixinAttributes(SHtml.text(query, query = _)) _,
> > > "submit" -> SHtml.submit("Submit", processSearch)
> > > )
>
> > >
> > > Query:
> > >
> > >
>
> > > Can someone please let me know if I'm doing something wrong.
>
> > > Message: scala.MatchError:
> > > scala.runtime.ScalaRunTime$.boxArray(ScalaRunTime.scala:135)
> > >
> > > net.liftweb.util.BindHelpers$FuncBindParam.value(BindHelpers.scala:
> > > 217)
> > > net.liftweb.util.BindHelpers$FuncBindParam.calcValue
> > > (BindHelpers.scala:218)
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind$1$1$
> > > $anonfun$apply$8.apply(BindHelpers.scala:419)
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind$1$1$
> > > $anonfun$apply$8.apply(BindHelpers.scala:414)
> > > net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind
> > > $1$1.apply(BindHelpers.scala:413)
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind
> > > $1$1.apply(BindHelpers.scala:412)
> > > scala.Seq$class.flatMap(Seq.scala:294)
> > > scala.xml.NodeSeq.flatMap(NodeSeq.scala:34)
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2.in_bind$1
> > > (BindHelpers.scala:412)
> > >
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2.apply(BindHelpers.scala:
> > > 429)
> > >
> > > net.liftweb.util.BindHelpers$$anonfun$bind$2.apply(BindHelpers.scala:
> > > 397)
> > > net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
> > > net.liftweb.util.BindHelpers$class.bind(BindHelpers.scala:397)
> > > net.liftweb.util.BindHelpers$.bind(BindHelpers.scala:72)
> > > net.liftweb.util.BindHelpers$class.bind(BindHelpers.scala:368)
> > > net.liftweb.util.BindHelpers$.bind(BindHelpers.scala:72)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: mixinAttributes help
Of course if you want it simpler just use:
bind("f", xhtml,
"query" -> SHtml.text(query, query = _),
"submit" -> SHtml.submit("Submit", processSearch)
)
Query:
and Lift will automatically merge the attributes for you ;)
Br's,
Marius
On Mar 27, 9:40 pm, "marius d." wrote:
> If I may you can also use something like:
>
> bind("f", xhtml,
> "query" -> {n: NodeSeq => (for (node <- BindHelpers.currentNode)
> yield BindHelpers.mixinAttributes(SHtml.text(query, query = _))(node))
> open_! },
> "submit" -> SHtml.submit("Submit", processSearch)
> )
>
>
> Query:
>
>
>
> the difference is that we passed the id directly to f:query without
> duplicating the input tag.
>
> Br's,
> Marius
>
> On Mar 27, 3:12 pm, bradford wrote:
>
> > Hi Timothy,
>
> > Thanks for your response. After I posted this message I realized that
> > JavaRebel failed to reload a class. I restarted the application and
> > the code works now. This thread did not appear in the list at that
> > time (due to moderation perhaps) so I could not reply to it in time.
>
> > Yes, I'm aware that you can set the attributes that way, but I prefer
> > to set it in the HTML. I just find it easier to work with CSS that
> > way. I guess it's a personal preference. Anyway, mixinAttributes is
> > very cool.
>
> > Thanks for your help,
> > Bradford
>
> > On Mar 27, 6:10 am, Timothy Perrett wrote:
>
> > > Hi Bradford,
>
> > > Can you just elaborate on what your trying to achieve? My assumption
> > > is that you want to set the ID of the input field?
> > > When your working with lift you dont need to define the input fields
> > > in the HTML, only on the serverside.
>
> > > Try this:
>
> > > bind("f", xhtml,
> > > "query" -> SHtml.text(query, query = _) % "id" -> "hello"
> > > "submit" -> SHtml.submit("Submit", processSearch)
> > > )
> > >
> > > Query:
> > >
> > >
>
> > > On Mar 27, 2:28 am, bradford wrote:
>
> > > > I'm trying to use mixinAttributes, but get a scala.MatchError:
> > > > (full error below). I'm using the 1.1 snapshot.
>
> > > > bind("f", xhtml,
> > > > "query" -> mixinAttributes(SHtml.text(query, query = _)) _,
> > > > "submit" -> SHtml.submit("Submit", processSearch)
> > > > )
>
> > > >
> > > > Query:
> > > >
> > > >
>
> > > > Can someone please let me know if I'm doing something wrong.
>
> > > > Message: scala.MatchError:
> > > > scala.runtime.ScalaRunTime$.boxArray(ScalaRunTime.scala:135)
> > > >
> > > > net.liftweb.util.BindHelpers$FuncBindParam.value(BindHelpers.scala:
> > > > 217)
> > > > net.liftweb.util.BindHelpers$FuncBindParam.calcValue
> > > > (BindHelpers.scala:218)
> > > >
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind$1$1$
> > > > $anonfun$apply$8.apply(BindHelpers.scala:419)
> > > >
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind$1$1$
> > > > $anonfun$apply$8.apply(BindHelpers.scala:414)
> > > > net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind
> > > > $1$1.apply(BindHelpers.scala:413)
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2$$anonfun$in_bind
> > > > $1$1.apply(BindHelpers.scala:412)
> > > > scala.Seq$class.flatMap(Seq.scala:294)
> > > > scala.xml.NodeSeq.flatMap(NodeSeq.scala:34)
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2.in_bind$1
> > > > (BindHelpers.scala:412)
> > > >
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2.apply(BindHelpers.scala:
> > > > 429)
> > > >
> > > > net.liftweb.util.BindHelpers$$anonfun$bind$2.apply(BindHelpers.scala:
> > > > 397)
> > > > net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
> > > > net.liftweb.util.BindHelpers$class.bind(BindHelpers.scala:397)
> > > > net.liftweb.util.BindHelpers$.bind(BindHelpers.scala:72)
> > > > net.liftweb.util.BindHelpers$class.bind(BindHelpers.scala:368)
> > > > net.liftweb.util.BindHelpers$.bind(BindHelpers.scala:72)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Bidirectional Record - JSON conversion
Apologies ... fixing it now.
On Mar 29, 11:34 pm, Timothy Perrett wrote:
> FYI - the job is also failing on Hudson
>
> http://scala-tools.org/hudson/job/lift/926/
>
> On Mar 29, 9:29 pm, Timothy Perrett wrote:
>
> > @marius, this is slick.
>
> > However, its causing my build to error now... I get the following
> > stack trace when building the entire lift project:
>
> > [INFO] Compiling 22 source files to /Users/timperrett/repositories/
> > lift/lift-framework/lift-record/target/classes
> > [WARNING] /Users/timperrett/repositories/lift/lift-framework/lift-
> > record/src/main/scala/net/liftweb/record/MetaRecord.scala:238: error:
> > type mismatch;
> > [WARNING] found : net.liftweb.util.Box[net.liftweb.util.Box
> > [net.liftweb.record.OwnedField[BaseRecord]#MyType]]
> > [WARNING] required: Iterable[?]
> > [WARNING] Note that implicit conversions are not applicable because
> > they are ambiguous:
> > [WARNING] both method box2Iterable in object Box of type [T]
> > (net.liftweb.util.Box[T])Iterable[T]
> > [WARNING] and method box2Iterable in object Box of type [T]
> > (net.liftweb.util.Box[T])Iterable[T]
> > [WARNING] are possible conversion functions from net.liftweb.util.Box
> > [net.liftweb.util.Box[net.liftweb.record.OwnedField[BaseRecord]
> > #MyType]] to Iterable[?]
> > [WARNING] field <- inst.fieldByName(k.toString)) yield
> > field.setFromAny(v)
> > [WARNING] ^
> > [WARNING] one error found
>
> > On Mar 29, 1:59 pm, Derek Chen-Becker wrote:
>
> > > Very nice :)
>
> > > On Sun, Mar 29, 2009 at 6:07 AM, Marius wrote:
>
> > > > Folks,
>
> > > > I just committed the Record/JSON conversion support.
>
> > > > Here is a simple example:
>
> > > > import net.liftweb.record.field._
> > > > import java.util._
>
> > > > object Main {
> > > > def main(args : Array[String]) : Unit = {
>
> > > > val rec = MyRecordMeta.createRecord.firstName("McLoud")
>
> > > > // Change an existing record with the values from a given json
> > > > val json = "{'firstName': 'Johnson', 'birthDay': 'Sun, 29 Mar 2009
> > > > 11:41:53 UTC', 'cars': 3, 'lastName': 'Doe'}"
> > > > rec.fromJSON(json)
> > > > println(rec.birthDay.value.getTime)
> > > > println(rec.firstName)
> > > > println(rec.cars)
>
> > > > // Construct a record out of the json(opne_! is used only for
> > > > exemplification :)...)
> > > > val rec2 = MyRecordMeta.createRecord(json).open_!
> > > > println(rec2.firstName)
> > > > println(rec2.birthDay.value.getTime)
> > > > }
> > > > }
>
> > > > class MyRecord extends Record[MyRecord] {
> > > > def meta = MyRecordMeta
>
> > > > object firstName extends StringField(this, "Smith")
> > > > object lastName extends StringField(this, "John")
> > > > object birthDay extends DateTimeField(this,
> > > > Calendar.getInstance);
> > > > object cars extends IntField(this, 1);
> > > > }
>
> > > > object MyRecordMeta extends MyRecord with MetaRecord[MyRecord] {
> > > > override def mutable_? = false
> > > > }
>
> > > > Br's,
> > > > Marius
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Bidirectional Record - JSON conversion
Done ...
The Box's implicits were not visible. Funny it was working on my
Eclipse plugin 2.8.0 ...
Sorry again and thanks for pointing it out !
Br's,
Marius
On Mar 29, 11:45 pm, "marius d." wrote:
> Apologies ... fixing it now.
>
> On Mar 29, 11:34 pm, Timothy Perrett wrote:
>
> > FYI - the job is also failing on Hudson
>
> >http://scala-tools.org/hudson/job/lift/926/
>
> > On Mar 29, 9:29 pm, Timothy Perrett wrote:
>
> > > @marius, this is slick.
>
> > > However, its causing my build to error now... I get the following
> > > stack trace when building the entire lift project:
>
> > > [INFO] Compiling 22 source files to /Users/timperrett/repositories/
> > > lift/lift-framework/lift-record/target/classes
> > > [WARNING] /Users/timperrett/repositories/lift/lift-framework/lift-
> > > record/src/main/scala/net/liftweb/record/MetaRecord.scala:238: error:
> > > type mismatch;
> > > [WARNING] found : net.liftweb.util.Box[net.liftweb.util.Box
> > > [net.liftweb.record.OwnedField[BaseRecord]#MyType]]
> > > [WARNING] required: Iterable[?]
> > > [WARNING] Note that implicit conversions are not applicable because
> > > they are ambiguous:
> > > [WARNING] both method box2Iterable in object Box of type [T]
> > > (net.liftweb.util.Box[T])Iterable[T]
> > > [WARNING] and method box2Iterable in object Box of type [T]
> > > (net.liftweb.util.Box[T])Iterable[T]
> > > [WARNING] are possible conversion functions from net.liftweb.util.Box
> > > [net.liftweb.util.Box[net.liftweb.record.OwnedField[BaseRecord]
> > > #MyType]] to Iterable[?]
> > > [WARNING] field <- inst.fieldByName(k.toString)) yield
> > > field.setFromAny(v)
> > > [WARNING] ^
> > > [WARNING] one error found
>
> > > On Mar 29, 1:59 pm, Derek Chen-Becker wrote:
>
> > > > Very nice :)
>
> > > > On Sun, Mar 29, 2009 at 6:07 AM, Marius wrote:
>
> > > > > Folks,
>
> > > > > I just committed the Record/JSON conversion support.
>
> > > > > Here is a simple example:
>
> > > > > import net.liftweb.record.field._
> > > > > import java.util._
>
> > > > > object Main {
> > > > > def main(args : Array[String]) : Unit = {
>
> > > > > val rec = MyRecordMeta.createRecord.firstName("McLoud")
>
> > > > > // Change an existing record with the values from a given json
> > > > > val json = "{'firstName': 'Johnson', 'birthDay': 'Sun, 29 Mar 2009
> > > > > 11:41:53 UTC', 'cars': 3, 'lastName': 'Doe'}"
> > > > > rec.fromJSON(json)
> > > > > println(rec.birthDay.value.getTime)
> > > > > println(rec.firstName)
> > > > > println(rec.cars)
>
> > > > > // Construct a record out of the json(opne_! is used only for
> > > > > exemplification :)...)
> > > > > val rec2 = MyRecordMeta.createRecord(json).open_!
> > > > > println(rec2.firstName)
> > > > > println(rec2.birthDay.value.getTime)
> > > > > }
> > > > > }
>
> > > > > class MyRecord extends Record[MyRecord] {
> > > > > def meta = MyRecordMeta
>
> > > > > object firstName extends StringField(this, "Smith")
> > > > > object lastName extends StringField(this, "John")
> > > > > object birthDay extends DateTimeField(this,
> > > > > Calendar.getInstance);
> > > > > object cars extends IntField(this, 1);
> > > > > }
>
> > > > > object MyRecordMeta extends MyRecord with MetaRecord[MyRecord] {
> > > > > override def mutable_? = false
> > > > > }
>
> > > > > Br's,
> > > > > Marius
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: lift on vista
Does it work if you put http://127.0.0.1:8080 ? if it does you need to add 127.0.0.01localhost in your c:/windows/sys32/drivers/etc/hosts Br's, Marius On Mar 29, 6:29 pm, vpalle wrote: > Hi there > > I've followed the getting started guide and managed to create the > helloworld app, but when I try and openhttp://localhost:8080, the > page is empty.. or rather, theres no connection. I can see that the > jetty server is running though.. Any known problems with vista > regarding lift or jetty? Or any suggestions otherwise? I've tried > shutting down the firewall.. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Derek's #1
Keep on Rockin' Derek ! On Mar 30, 7:15 pm, David Pollak wrote: > Folks, > > It's almost the end of the most active month ever on the Lift list. I'm > happy to report that Derek is the #1 poster this month. He's been helping > lots of folks and improving Lift. > > So, welcome to all the new folks who have joined the list and starting > asking questions. A big round of thanks to Derek and others for helping out > and making the Lift community an excellent place to be. > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Jonas Bonér to the Lift committer s
Welcome Jonas ! On Mar 30, 7:52 pm, David Pollak wrote: > Folks, > > Please join me in welcoming Jonas as a Lift committer. I had the pleasure > of meeting Jonas as QCon in London this month. Jonas, Tim, and I went out a > grabbed a few pints and chatted. I think Jonas has a lot to contribute to > Lift. > > So, please join me in welcoming him! > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Welcome Jonas Bonér to the Lift committer s
On Mar 30, 9:53 pm, David Pollak wrote: > On Mon, Mar 30, 2009 at 11:26 AM, Lee Mighdoll wrote: > > > Welcome Jonas! > > > I'd been thinking that some judicious use of aspectJ might be a nice fit > > for lift. Rumor has it you know something about aspects... > > AspectJ over my dead body. :-) > > I think AOP is a dangerous and generally very bad thing to do (sorry Jonas). > I have not found an application for it in Scala and would need a lot of > convincing to include it with anything Lift-related. > > Sorry for the wicked negative vibe against AOP... but it's one of my > hard-core things. I tend to agree. A while back was really interested in AspectJ played with it but in practice I never ever needed it. Especially with Scala where we have higher order functions and closures. I am still wondering how AspectJ survives :) ..jus' kiddin' I'm sure there is a market for it somewhere. > > > > > > > Lee > > > On Mon, Mar 30, 2009 at 11:15 AM, marius d. wrote: > > >> Welcome Jonas ! > > >> On Mar 30, 7:52 pm, David Pollak > >> wrote: > >> > Folks, > > >> > Please join me in welcoming Jonas as a Lift committer. I had the > >> pleasure > >> > of meeting Jonas as QCon in London this month. Jonas, Tim, and I went > >> out a > >> > grabbed a few pints and chatted. I think Jonas has a lot to contribute > >> to > >> > Lift. > > >> > So, please join me in welcoming him! > > >> > Thanks, > > >> > David > > >> > -- > >> > Lift, the simply functional web frameworkhttp://liftweb.net > >> > Beginning Scalahttp://www.apress.com/book/view/1430219890 > >> > Follow me:http://twitter.com/dpp > >> > Git some:http://github.com/dpp > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: HTML 5 Web Sockets ?
Hi, Well as long as we have XML well formed templates it should work. So far Lift does not use new tags from HTML 5 but you can use them if you want and you have a browser supporting HTML 5. Br's, Marius On Mar 31, 12:35 pm, Matthias Wessendorf wrote: > Hi, > > I wonder if Lift does support HTML 5's Web Sockets. I think that I > read it somewhere ... > > Thanks! > Matthias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Forms & validation formatter
On Mar 31, 5:06 pm, Clemens Oertel wrote: > Hello, > > Sorry for the delay in my response, but I only get to play with lift > on the weekends, and I wanted to look into your suggestions in more > detail. > > I ported the toForm code from Record to Mapper (and by port, I mean > mostly cut'n'paste). While doing so, I noticed 2 things: > > - Why not provide the same template mechanism used for forms for HTML > output? This way I can reuse the same template for both - given that > my records have at least dozens, if not even hundreds, of fields, > that'd be a great help. Well you can load templates from an html file. Please see LiftSession.findAnyTemplate function. > - The templates require the use of and similar tags. I > thought I'd be really smart, and created a HTML file A with lift-tags > (...) to run my snippet, and > used the tags as children to . This > way, I can create my templates externally, and use the normal lift > dispatch-from-view mechanism. And, to save me some more work, the > actual form template is in a separate, reusable, HTML file B, to be > embedded into A. Embedding, of course, requires eager evaluation. > Fine. No. With eager evaluation, lift of course complains that there > is no class "field", as referenced by . Now me's wondering > whether a separate namespace would be more appropriate? (I did switch > to a different namespace, liftf, out of necessity, but I figure that > other people might have similar issues) Well I can understand the urge but we do NOT recommend processing templates outside of rendering pipeline. You can call LiftSession.processSurroundAndInclude so that lift tags to be processed etc. but again it is not recommended. The main reason is that your functions that you assume to be bounded during this off- cycle template processing, will not actually be bounded cause it i happening in the wrong place. The Record's form template is to allow you to shape the form in any way you like (from markup perspective). But this template is supposed to be very very lightweight in terms of lift's tags. It is just an xhtml fragment and not a full blow page/(lift template). > > As to the original discussion: I still strongly believe that toForm > and to/as(X)Html should not be in Mapper/Record. Different story for > JSON/XML/SQL - those seem to me to be rather functionality complete, > no problem. > But form and html creation seem to be something that most users will > want to adapt to their application's needs eventually - state > dependent css classes, javascript validation, AJAX form updates... In > the examples that I've seen so far, this functionality was dealt with > in the snippet. So, either mapper/record eventually become this super- > omnipotent-mega-classes that can deal with this functionality to > (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or > form/html generation happens in multiple locations, or the user has to > override some functions from mapper/record/fields. My beef with this > is A) that the respective function calls, given their current > signature, require the respective mapper/record-objects to be fully > aware of application state for more complex applications; and B) that > it is my understanding that overriding internal classes of a framework > is a bad thing - I'd rather see a proper application of the Hollywood > principle. > > Just wanted to provide an outsider's feedback. Overall, I think lift's > just fantastic. I'm really glad you like Lift ! > > Thank you for listening/reading, > Clemens > > On 19-Mar-09, at 1:08 PM, marius d. wrote: > > > > > > > On Mar 18, 11:24 pm, Clemens wrote: > >> Thank you for your patience, Marius. > > >>> Well you can use different RecordMeta implementations if you need to > >>> different representation of a record without sequential template > >>> change. So no state dependency. > > >> , b I'm really not trying to be difficultut having multiple > >> RecordMeta > >> instances, for which the HTML output seems to be only one of many > >> functionalities, seems to be shooting with canons at sparrows. Having > >> a toForm functions that takes some template provider as input could > >> be > >> one option. > > > Well this is kinda already in there but it's private :) ... See: > > > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > > so to me makes sense to relax it ... to > > > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq > > > ... thanks for reminding me a
[Lift] Re: Forms & validation formatter
On Mar 31, 9:09 pm, Clemens Oertel wrote:
> Marius:
>
> On 31-Mar-09, at 12:31 PM, marius d. wrote:
>
>
>
> > On Mar 31, 5:06 pm, Clemens Oertel wrote:
> >> - Why not provide the same template mechanism used for forms for HTML
> >> output? This way I can reuse the same template for both - given that
> >> my records have at least dozens, if not even hundreds, of fields,
> >> that'd be a great help.
>
> > Well you can load templates from an html file. Please see
> > LiftSession.findAnyTemplate function.
>
> just thought that, since MetaRecord has
>
> def toForm(inst: BaseRecord): NodeSeq
> and
> def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
>
> it would only be consistent to provide similar means for HTML output.
>
> > Well I can understand the urge but we do NOT recommend processing
> > templates outside of rendering pipeline. You can call
> > LiftSession.processSurroundAndInclude so that lift tags to be
> > processed etc. but again it is not recommended. The main reason is
> > that your functions that you assume to be bounded during this off-
> > cycle template processing, will not actually be bounded cause it i
> > happening in the wrong place.
>
> > The Record's form template is to allow you to shape the form in any
> > way you like (from markup perspective). But this template is supposed
> > to be very very lightweight in terms of lift's tags. It is just an
> > xhtml fragment and not a full blow page/(lift template).
>
> Mmh, maybe there's a misunderstanding. I was only using the template
> as indicated in the source code, or so I thought.
>
> May I just provide an abbreviated version of the code that I come up
> with?
>
> Outer Template
>
> Create a New Site
>
>
>
>
>
> Submit
>
>
>
>
>
>
> End Outer Template
>
> Embedded Template
>
>
> Name:
> A Hospital Site
>
>
>
> End Embedded Template
>
> SiteOps
> def add(form: NodeSeq): NodeSeq = {
> val invokedAs = S.invokedAs
> val site = Site.create
>
> def newSite(form: NodeSeq): NodeSeq = {
> def saveMe(): Unit = {
> site.validate match {
> case Nil => site.save ; S.notice("Added " + site.name);
> S.redirectTo("/sites/")
> case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
> }
> }
>
> bind("site", Site.toForm(site, form), "submit" ->
> submit("Save", saveMe))
> }
>
> newSite(form)
> }
> End SiteOps
>
> The Site.toForm function is pretty much the same as found in
> MetaRecord. It will eventually call each fields' toForm function
> (which are the original Lift 1.0 mapper versions, no changes there).
>
> Am I really doing things outside the rendering pipeline (this is not a
> rhetorical question)?
Nope sorry ... I misunderstood your case. By bad entirely.
It all seems to work, incl. validation.
> Also, the eagerly evaluated template, which will be passed to toForm,
> contains only field tags, no other lift tags.
>
> Again, imagine a few dozen different entities, each with a ton of
> fields. I'm sure you'll understand that I'm hesitant to bind each
> field manually (once for the list page, once for the display page,
> once for the add page, and again once for the edit page, even though
> the last 2 can surely be combined into one bind call in the code).
> I obviously have to declare each field in the model, and refer to it
> in the view. I really wouldn't mind not having to mention it anywhere
> inbetween.
This is actually a nice thing to do. Sorry that I misunderstood your
intentions :)
>
> Thank you for all your help,
> Clemens
>
> Clemens Oertel
> clem...@oertel.ca
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Menu widget
-------
> [INFO] Total time: 5 seconds
> [INFO] Finished at: Tue Mar 31 17:38:35 EDT 2009
> [INFO] Final Memory: 17M/30M
> [INFO]
>
>
> Any ideas on how to prevent/fix this? Do I need to modify my .pom?
>
> Thanks,
> David
>
> On Mar 23, 12:18 pm, "marius d." wrote:
>
> > Cool ... if you tested it and theMenuWidget, from my perspective it
> > is good to go into master. And it's really great that you added the
> > ScalaDocs !!!
>
> > Br's,
> > Marius
>
> > On Mar 23, 6:07 pm, Derek Chen-Becker wrote:
>
> > > OK, I've pushed the new code on the wip-dcb-dropdown branch. I made some
> > > minor mods to the builtin Menu snippet (and changes to the Menu widget to
> > > match):
>
> > > 1. Added an "expandAll" attribute that renders the entire SiteMap.
> > > 2. Added a new "top" prefix to the builder snippet to allow for
> > > attributes on the top-level menu UL element.
> > > 3. Added API documentation to the Menu class.
>
> > > For some reason, the branch isn't showing up on github. I did a
>
> > > git push origin wip-dcb-dropdown
>
> > > And it says it's up-to-date, but I'm not seeing it on github.
>
> > > Derek
>
> > > On Sat, Mar 21, 2009 at 3:04 PM, Charles F. Munat wrote:
>
> > > > +1
>
> > > > I am understanding exactly what you have in mind and think it's a great
> > > > idea. I wrote some kludgy code months ago (I knew zero about Scala back
> > > > then -- now I know *infinity* times more! :-) to do pretty much the same
> > > > thing, and I ended up completely rewriting the Menu snippet to my own
> > > > needs. More flexibility == good, I think.
>
> > > > Chas.
>
> > > > (For anyone a little slow on the uptake this fine Saturday, please note
> > > > that anything times zero is still zero.)
>
> > > > Derek Chen-Becker wrote:
> > > > > I think I'm not being very clear. I'm going to modify the builtin Menu
> > > > > snippet, not SiteMap. In my view, SiteMap should not be concerned with
> > > > > how it's rendered, but the builtin snippet surely should be able to
> > > > > handle this. Once I have the Menu snippet modified, theMenuWidgetclass
> > > > > would just embed a tag where it
> > > > > wants the menu. I'll work on it this weekend and let you know when I
> > > > > have something usable.
>
> > > > > Derek
>
> > > > > On Sat, Mar 21, 2009 at 10:01 AM, marius d. > > > > <mailto:marius.dan...@gmail.com>> wrote:
>
> > > > > I think I am aware what you meant ... If you want to make SiteMap
> > > > > to
> > > > > know how to render itself as / hence "centralize" this
> > > > > fine
> > > > by
> > > > > me. I have nothing against it, I just don't see the need ... the
> > > > > good
> > > > > news is that it may be just me ;)
>
> > > > > The analogy with chooseTemplate is not very relevant IMHO because
> > > > > choseeTemplate is a construct that one can use in many application
> > > > > context whereas SiteMap is typically only one. But by all means
> > > > > don't
> > > > > let me stay in your way:)
>
> > > > > If you are implementing this in SIteMap then perhaps you should
> > > > > make
> > > > > both Menu built in snippet andMenuWidgetto use it?
>
> > > > > Br's,
> > > > > Marius
>
> > > > > On Mar 21, 5:41 pm, Derek Chen-Becker > > > > <mailto:dchenbec...@gmail.com>> wrote:
> > > > > > Sorry, what I mean is that the builtin Menu snippet code is
> > > > > duplicated, not
> > > > > > SiteMap. For instance, here's how the builtin snippet generates
> > > > > the ULs:
>
> > > > > > S.request.map(_.buildMenu.lines.toList match {
> > > > > > case Nil => List(Text("No Navigation Defined."))
> > > > > > case xs =>
> > > > > > val liMap = S.prefixedAttrsToMap("li")
> > >
[Lift] Re: A gap in my knowledge, JsCommands
On Apr 1, 5:59 pm, TylerWeir wrote:
> Rewriting ajaxCall_* to incorporate Vik's idea fixes this:
>
> private def ajaxCall_*(jsCalcValue: JsExp, func: AFuncHolder):
> (String, JsExp) = {
> val (n, r) = fmapFunc(func)(name =>
> (name, makeAjaxCall(JsRaw("'"+name+"=' +
> "+jsCalcValue.toJsCmd
> ("'" + n + "'", r)
Tyler instead of "'" + n + "'" we usually use encJs so the return
tuple would become (n.encJs, r). If you are ok with this can you
please update it in github ?
> }
>
> Thanks.
>
> On Apr 1, 9:37 am, TylerWeir wrote:
>
> > Excellent, thanks Derek, Vik, I'm back on this today.
>
> > On Apr 1, 9:03 am, Viktor Klang wrote:
>
> > > On Wed, Apr 1, 2009 at 2:55 PM, Derek Chen-Becker
> > > wrote:
>
> > > > It looks like it's missing a function call. Compare
>
> > > > onclick="lift_ajaxHandler(...
>
> > > > to
>
> > > > onclick="(F687305521435R3K,lift_ajaxHandler
>
> > > > I'm no JS guru, so that second one might be perfectly valid JS, but it
> > > > looks weird to me.
>
> > > I'd recommend to stay away from referring to objects by reference instead
> > > of
> > > by id..
> > > (all kinds of weird stuff can happen when you start to remove objects/have
> > > partial rendering)
>
> > > I.e. somefun('F687305521435R3K',lift_ajaxHandler) instead of
> > > somefun(F687305521435R3K,lift_ajaxHandler)
> > > (Note the single-quotes.)
>
> > > > Derek
>
> > > > On Tue, Mar 31, 2009 at 9:57 AM, TylerWeir wrote:
>
> > > >> I'm wading into an area that I'm a bit unfamiliar with and not sure if
> > > >> I'm running in a bug.
>
> > > >> Snippet code:
> > > >> class HelloWorld {
> > > >> def ajaxFunc1() : JsCmd = JsRaw("alert('Button1 clicked')")
>
> > > >> def ajaxFunc2(str: String) : JsCmd = {
> > > >> Log.info("Received" + str)
> > > >> JsRaw("alert('Button2 clicked')")
> > > >> }
>
> > > >> def renderAjaxButtons(xhtml: NodeSeq): NodeSeq = {
> > > >> bind("ex", xhtml,
> > > >> "button1" -> SHtml.ajaxButton("Press Me", ajaxFunc1 _),
> > > >> "button2" -> Press Me 2 % ("onclick" ->
> > > >> SHtml.ajaxCall(Str("Button-2"), ajaxFunc2 _)))
> > > >> }
> > > >> }
>
> > > >> Which is in this template:
> > > >>
> > > >>
> > > >>
> > > >>
>
> > > >> And is rendered thusly:
> > > >> Press Me
>
> > > >> Press Me 2 > > >> button>
>
> > > >> Button 1 is find, but Button 2 causes FireBug to whine:
> > > >> F687305521435R3K is not defined
> > > >> onclick(click clientX=500, clientY=239)2 (line 2)
> > > >> [Break on this error] F687305521435R3K,
> > > >> lift_ajaxHandl...F687305521435R3K=Button-2", null, null);
>
> > > >> Does the second onclick look incorrect to you?
>
> > > --
> > > Viktor Klang
> > > Senior Systems Analyst
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Widget CSS
Can you "scope" your stylesheet props? ... such as adding prefixes to classes etc. ... or use styles per ID-s. Looks to me that even if we change the order the application specific styles could potentially conflict with TableSorter's. The TableSorter's CSS are coming from JQuery plugin and not really proprietary so we probably should not change that. Do you have an example of the conflict? Br's, Marius On Apr 2, 7:47 am, "Charles F. Munat" wrote: > I've been playing with the very cool TableSorter widget. Nice work. > > One hassle though -- it inserts its stylesheet *after* my stylesheet, so > it overrides my styles. I could change things locally, but that's a > hassle. Might be able to add "important" qualifiers or some trick like > that, but it would be easiest if I could just turn that stylesheet off > and use my own. > > Any luck on that, or do I have to reinvent the TableSorter? > > Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: [Bug] liftAjax.js generation bug in case of LiftRules.enableLiftGC = false
well I just assigned it to myself ... Dave if youreally want it just
let me know to stay away ... I should be commititng the fix either
today or tomorrow.
Br's,
Marius
On Apr 3, 7:12 pm, David Pollak wrote:
> Please add this to
> Lighthousehttp://liftweb.lighthouseapp.com/projects/26102-lift/overview Feel
> free to
> assign it to me.
>
>
>
> On Thu, Apr 2, 2009 at 3:32 PM, nau wrote:
>
> > Hi there,
>
> > There is a bug in ScriptRenderer.scala I've described here:
>
> >http://liftweb.lighthouseapp.com/projects/26102/tickets/31-bug-liftaj...
> > .
>
> > I've got a quick fix for it but I don't think it's the best one
> > (sorry, can't provide normal patch now, I'm on windows):
>
> > ScriptRenderer.scala
>
> > function addPageName(url) {
> > return url.replace('""" + LiftRules.ajaxPath + """', '""" +
> > LiftRules.ajaxPath + liftPage + """);
> > }
>
> > function lift_actualAjaxCall(data, onSuccess, onFailure) {
> > """ +
> > LiftRules.jsArtifacts.ajax(AjaxInfo(JE.JsRaw
> > ("data"),
> > "POST",
>
> > LiftRules.ajaxPostTimeout,
> > false,
> > "script",
> > Full
> > ("onSuccess"), Full("onFailure")))+
> > """
> > }
>
> > """ +
> > LiftRules.jsArtifacts.onLoad(new JsCmd() {def
> > toJsCmd = "lift_doAjaxCycle()"}).toJsCmd)
>
> > val liftPage = if (LiftRules.enableLiftGC) "/'+lift_page" else
> > ""
>
> > --
>
> > One more. I've found inconsistent statements in Liftweb book (pdf
> > compilation master-20090309 from github). I'm not sure wheather it
> > still exists but anyway:
> > paragraph 3.4 states:
> > "3. Check to see if the request should be handled by a View. This is
> > covered in section
> > 3.6
> > 4. If the request is not handled by a View, find a template that
> > matches and use it. We’ll
> > cover templates in section 3.5"
>
> > but paragraph 3.6 states:
>
> > "In either case, View lookup and dispatch is done after template
> > resolution, so templates take priority."
>
> > Cheers,
> > Alex Nemish
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: liftAjax.js generation bug in case of LiftRules.enableLiftGC = false
committed.
On Apr 3, 8:10 pm, "marius d." wrote:
> well I just assigned it to myself ... Dave if youreally want it just
> let me know to stay away ... I should be commititng the fix either
> today or tomorrow.
>
> Br's,
> Marius
>
> On Apr 3, 7:12 pm, David Pollak wrote:
>
> > Please add this to
> > Lighthousehttp://liftweb.lighthouseapp.com/projects/26102-lift/overview Feel
> > free to
> > assign it to me.
>
> > On Thu, Apr 2, 2009 at 3:32 PM, nau wrote:
>
> > > Hi there,
>
> > > There is a bug in ScriptRenderer.scala I've described here:
>
> > >http://liftweb.lighthouseapp.com/projects/26102/tickets/31-bug-liftaj...
> > > .
>
> > > I've got a quick fix for it but I don't think it's the best one
> > > (sorry, can't provide normal patch now, I'm on windows):
>
> > > ScriptRenderer.scala
>
> > > function addPageName(url) {
> > > return url.replace('""" + LiftRules.ajaxPath + """', '""" +
> > > LiftRules.ajaxPath + liftPage + """);
> > > }
>
> > > function lift_actualAjaxCall(data, onSuccess, onFailure) {
> > > """ +
> > > LiftRules.jsArtifacts.ajax(AjaxInfo(JE.JsRaw
> > > ("data"),
> > > "POST",
>
> > > LiftRules.ajaxPostTimeout,
> > > false,
> > > "script",
> > > Full
> > > ("onSuccess"), Full("onFailure")))+
> > > """
> > > }
>
> > > """ +
> > > LiftRules.jsArtifacts.onLoad(new JsCmd() {def
> > > toJsCmd = "lift_doAjaxCycle()"}).toJsCmd)
>
> > > val liftPage = if (LiftRules.enableLiftGC) "/'+lift_page" else
> > > ""
>
> > > --
>
> > > One more. I've found inconsistent statements in Liftweb book (pdf
> > > compilation master-20090309 from github). I'm not sure wheather it
> > > still exists but anyway:
> > > paragraph 3.4 states:
> > > "3. Check to see if the request should be handled by a View. This is
> > > covered in section
> > > 3.6
> > > 4. If the request is not handled by a View, find a template that
> > > matches and use it. We’ll
> > > cover templates in section 3.5"
>
> > > but paragraph 3.6 states:
>
> > > "In either case, View lookup and dispatch is done after template
> > > resolution, so templates take priority."
>
> > > Cheers,
> > > Alex Nemish
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift using JQuery and JCarousel
Hmm ... I'd be very surprised if the the presence of the multiple ready function calls would cause this. Virtually you can have as many as you want. But what is the exact problem ? I could probably take a look tomorrow and maybe make a lift widget out of it. Br's, Marius P.S. You can render stuff in any place you want using various ways. For instance: 1. Use a snippet 2. Use lift:embed 3.You can post process resulting xml before it is sent to client (a pretty uncommon need) I I'd really doubt that this would represent the solution. >On Apr 3, 11:32 am, wapgui wrote: > Hi, > > had anybody success including the JCarousel plugin into Lift. > Here is my default.html > > http://www.w3.org/1999/xhtml"; > xmlns:lif="http://liftweb.net/";> > > > jCarousel Examples > > > > > src="classpath/json.js"> script> >