On Mon, Apr 13, 2009 at 4:35 AM, David Pollak <[email protected] > wrote:
> > > On Sun, Apr 12, 2009 at 7:30 AM, Oliver Lambert <[email protected]>wrote: > >> >> >> On Sun, Apr 12, 2009 at 11:04 PM, David Pollak < >> [email protected]> wrote: >> >>> >>> >>> On Sun, Apr 12, 2009 at 5:29 AM, Oliver Lambert <[email protected]>wrote: >>> >>>> >>>> >>>> On Sun, Apr 12, 2009 at 3:49 PM, marius d. <[email protected]>wrote: >>>> >>>>> >>>>> As I said you CAN use it to "span" the same snippet instance for >>>>> multiple pages. Please see the two fundamental functions offered by >>>>> StatefulSnippet: link and redirect. Lift book provided correct >>>>> information. >>>>> >>>> >>>> It can be used, but doesn't always give the same instance when the back >>>> button is used? >>>> Therefore, all my fields are reset to null. Is this the expected >>>> functionality, or a bug (my code or Lift's)? >>>> I am using Stateful link and redirect and the application works fine, >>>> apart from the back button. >>>> >>> >>> If you're using the back button and you're presenting forms to the user, >>> what you're seeing is the expected (perhaps not desired) behavior. >>> >>> In order to figure out which stateful snippet is being used, Lift either >>> inserts a hidden field on the form or adds a parameter to the link URL. In >>> both cases, these hidden items refer to a function that binds the instance >>> of the stateful snippet to the name of the snippet so that the same instance >>> will be used. If you press the back button and a URL does not have the >>> query parameter, there's no way for Lift to know which instance of the >>> stateful snippet to attach to the particular snippet name and Lift creates a >>> new one. >>> >>> More broadly, I opted to not have ugly URLs in Lift. Seaside and other >>> frameworks that are more stateful than Lift have to put a token in the URL >>> indicating the state of the application for that particular URL. This >>> allows you to have multiple instances of a given multi-page form going at >>> the same time, all with back-button support. The cost is ugly URLs and the >>> inability to send a given URL to a friend (because the state information is >>> part of the URL.) In Seaside, you have to specify that a particular URL is >>> durable and it's not uglified. In Lift, by default, the URLs are pretty and >>> stateless. >>> >>> So, you've found a corner case of the downside of this choice. I'm >>> hoping to add wizard functionality to Lift for 1.1 (although it's not on the >>> official schedule) and that would give you better statefulness, ugly URLs, >>> and better back-button support. >>> >>> Thanks, >>> >>> David >>> >>> >> Thanks, for explaining the functionality. I was just asked by my boss to >> ask a question, I'm not criticizing Lift for having the occasional corner >> case I don't expect. The fix for the application I'm currently working on is >> to use sessionVars, the occasional requestVar and to remove statefulSnippets >> - probably several hours work. >> > > Cool. > > >> >> In fact, I think I appreciate the design of lift for its flexibility. >> While I use the function binding of Lift, I've abstracted part of it away, >> so much of my code is automatically dealing with immutable objects. Maybe my >> one criticism of Lift is - it almost offers too much choice. >> > > Yeah. Rails and Mac are both great and having one true way. Windows gives > you the "choose what you like." In general, Mac apps feel more uniform and > better than Windows apps. > Mac apps often look more professional too - which is kind of funny considering their market. > > More broadly, I'd like to see how you do more immutable stuff within the > context of Lift. I'm still uncomfortable about the the amount of mutability > floating around in Lift. > Great, I'll create an example project using the methodology I'm using this week. > Thanks, > > David > > >> >> cheers >> Oliver >> >>> >>>> >>>>> >>>>> >>>>> On Apr 12, 5:44 am, Oliver Lambert <[email protected]> wrote: >>>>> > On Sun, Apr 12, 2009 at 7:14 AM, marius d. <[email protected]> >>>>> wrote: >>>>> > >>>>> > > The StatefulSnippet is not a snippet instance that is always used >>>>> in >>>>> > > the context of your session. >>>>> > >>>>> > Yikes! in that case, I wrote a whole application based on false >>>>> assumption. >>>>> > It says in the lift book >>>>> > a StatefulSnippet is "ideal for small, conversational state, such as >>>>> a form >>>>> > that spans multiple pages" >>>>> > If it spans multiple pages, doesn't this kind of imply the same >>>>> instance in >>>>> > the session? >>>>> > >>>>> > Anyway thanks for this info. Any reason why a StatefulSnippet always >>>>> has a >>>>> > dispatch function and >>>>> > a Stateless one, by default, has not? >>>>> >>>>> The reason that I see ... >>>>> Stateless snippets are the most used artifacts to "attach" business >>>>> logic to your view. Because it is so common besides DispatchSnippet >>>>> trait, Lift loads and invoke Snippets functions using reflection. >>>>> Since discriminating at runtime between a stateless and a stateful >>>>> requires a trait (forget about annotations for now) well that trait is >>>>> StatefulSnippet. >>>>> >>>>> >>>>> > >>>>> > to avoid RequestVar-s but keep state for current rendering pipeline >>>>> in >>>>> > >>>>> > > the snippet. >>>>> > > 2. You can indicate that you want to reuse the same instance across >>>>> > > multiple pages using link or redirectTo functions from the >>>>> > > StatefulSnippet >>>>> > >>>>> > > So depending what you want to doyou can use the statefull or >>>>> stateless >>>>> > > nature of snippets. For stateless snippets you can just declare the >>>>> > > class and the method and just use it. Such as: >>>>> > >>>>> > > class Foo { >>>>> > >>>>> > > def bar(xml: NodeSeq) :NodeSeq = ... >>>>> > > } >>>>> > >>>>> > > .. and in your markup >>>>> > >>>>> > > <lift:Foo.bar/> >>>>> > >>>>> > > you can also say >>>>> > >>>>> > > class Foo extends DispatchSniuppet { >>>>> > >>>>> > > def dispatch = ... >>>>> > > } >>>>> > >>>>> > > which is also a stateless snippet. >>>>> > >>>>> > > Br's, >>>>> > > Marius >>>>> > >>>>> > > On Apr 11, 7:21 am, Oliver Lambert <[email protected]> wrote: >>>>> > > > I have a stateful snippet that doesn't always appear to work with >>>>> the >>>>> > > back >>>>> > > > button. >>>>> > > > Sometimes, when the back button is used, a new stateful snippet >>>>> instance >>>>> > > > appears to be created. Has this happened to anyone else? >>>>> > >>>>> > > > Anyway, I've converted what I had to use a SessionVar to store >>>>> the state. >>>>> > > > Should I replace the stateful snippet with a stateless one - does >>>>> a >>>>> > > stateful >>>>> > > > snippet that isn't storing any state have any extra overhead over >>>>> a >>>>> > > > stateless one? >>>>> > >>>>> > > > If I do use a stateless snipet can I still have a dispatch >>>>> method? >>>>> > >>>>> > > > cheers >>>>> > > > Oliver >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Lift, the simply functional web framework http://liftweb.net >>> Beginning Scala http://www.apress.com/book/view/1430219890 >>> Follow me: http://twitter.com/dpp >>> Git some: http://github.com/dpp >>> >>> >>> >>> >> >> >> > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
