[Lift] Re: stateful vs stateless snippet
On Mon, Apr 13, 2009 at 4:35 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Sun, Apr 12, 2009 at 7:30 AM, Oliver Lambert olambo...@gmail.comwrote: 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.comwrote: On Sun, Apr 12, 2009 at 3:49 PM, marius d. marius.dan...@gmail.comwrote: 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 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
[Lift] Re: stateful vs stateless snippet
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.
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
--~--~-~--~~~---~--~~
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: stateful vs stateless snippet
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.comwrote:
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
[Lift] Re: stateful vs stateless snippet
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?
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
--~--~-~--~~~---~--~~
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: stateful vs stateless snippet
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.
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
--~--~-~--~~~---~--~~
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: stateful vs stateless snippet
Oh and if that helps from the Scaladoc:
* If the StatefulSnippet is used to render a form, a hidden field is
added to
* the form that causes the same instance to be used on the page that
is the
* target of the form submission.
On Apr 12, 8:49 am, 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.
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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
