On Sun, Apr 12, 2009 at 11:04 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:
>
>
> On Sun, Apr 12, 2009 at 5:29 AM, Oliver Lambert <olambo...@gmail.com>wrote:
>
>>
>>
>> On Sun, Apr 12, 2009 at 3:49 PM, marius d. <marius.dan...@gmail.com>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.
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.
cheers
Oliver
>
>>
>>>
>>>
>>> On Apr 12, 5:44 am, Oliver Lambert <olambo...@gmail.com> wrote:
>>> > On Sun, Apr 12, 2009 at 7:14 AM, marius d. <marius.dan...@gmail.com>
>>> 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 <olambo...@gmail.com> 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
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
