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
>
>
>>
>>
>> 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
-~----------~----~----~----~------~----~------~--~---
