On Dec 28, 9:11 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote: > That's true in practice. The implementation of those methods however are > equivalent to the S and SHtml versions except for the call to > registerThisSnippet. But if Lift will sometimes remember even ordinary class > instances as reusable snippets then why should the API for managing reused > snippets be exclusive to StatefulSnippets? > Why was this changed made, first of all? Why take away the flexibility to > choose to use multiple instances of a class on the same page? And was a > "Breaking Change" email sent out? > If all snippets get placed in a RequestVar is there still a purpose in using > RequestVars within a snippet?
SInce snippets are kept in the snippetMap ... I asked myself the same question and the answer that I got so far is only if you need to refer that state from some other layers. But if you strictly needed those request vars for snippet state, then the answer is No. > Another question I never got around to asking: Why does StatefulSnippet > extend DispatchSnippet? IMO because the DIspatchSnippet is the recommended way of doing snippets especially in production as it doesn't use reflection. So this is a very good thing to me. > In any case if it was decided that Lift does not need to allow you to have > multiple instances on the same page then why should StatefulSnippet have > special API? This is a very confusing dichotomy. I think Dave did this change, and he will soon clarify his intent. I wonder now if regular snippets are to become stateful snippets and have a special StatelessSnippet trait instead ? ... I would be OK with this since Lift is stateful framework and stateless things should be explicit rather then implicit. > Thanks. > > ------------------------------------- > > Alex Boisvert<alex.boisv...@gmail.com> wrote: > > StatefulSnippets lifetime is manually managed and may be "chained" to other > pages by using link() or redirectTo() such that the same instance is reused > for those targets. > > (And StatefulSnippet extends DispatchSnippet) > > alex > > On Mon, Dec 28, 2009 at 10:08 AM, Naftoli Gugenheim > <naftoli...@gmail.com>wrote: > > > > > And what's the difference to a StatefulSnippet? > > > ------------------------------------- > > Adam Warski<a...@warski.org> wrote: > > > Hello, > > > > RequestVar-s lifetime is expanded beyond the actual request, which is > > > not applicable for TransientRequestVar. For instance say you have a > > > page and you set some state on a RequestVar ... then you render an > > > Ajax link. After the page is rendered, when your ajax function is > > > invoked, you RequestVar state set when rendering the page is still > > > visible. > > > > But is there is problem you're chasing or is it just terminology? > > I understand the difference; and I think the terminology is a bit > > misleading. But right now I have two questions: > > > 1) Can I have in lift a "true" request variable/snippet, that is such which > > has a lifetime of one request (without any ajax callbacks)? I can't use > > TransientRequestVar because it's private. It would be useful to complete my > > ajax-form example (after an item is saved, a new one should be used; I guess > > I could just store the model instance in a RequestVar and set it to a new > > object after saving, but maybe there's a nicer way). > > > 2) Why would one want to use DispatchSnippets? The wiki says they are > > better because they are not instantiated whenever a tag is occurred. But > > right now, reflection snippets also aren't - they are instantiated at most > > once per request. > > > > Br's, > > > Marius > > > > On Dec 28, 6:04 pm, Adam Warski <a...@warski.org> wrote: > > >> Hello, > > > >>> Yes, the article is out of date now... Lift now makes sure that > > multiple references to a single snippet in the same request context use the > > same instance of that snippet. > > > >> I see, so the rationale behind using dispatch snippets is out of date > > also. Except that you save one reflection call per page/request. So are > > there any reasons to use DispatchSnippets now? > > > >>> Reflection snippets do not have the same scope as request vars... > > rather, the snippet is held in a request var. > > > >> Which essentialy makes them have the same scope as request vars :) > > > >> By the way, is there a "true" request-scope variable? I saw that there's > > TransientRequestVar, but it's private in the liftweb package. > > > >> Adam > > > >>> Cheers, Tim > > > >>> On 28 Dec 2009, at 14:33, Adam Warski wrote: > > > >>>> Hello, > > > >>>> on the wiki page about reflection snippets ( > >http://wiki.github.com/dpp/liftweb/about-snippets), it is written: > > > >>>> "Every time you call the reflection snippet in your markup code, a new > > instance is instantiated and the appropriate method invoked" > > > >>>> However this doesn't seem to be true (I'm using 1.1-M8). I have > > modified the example in the tutorial to use ajax to submit the form (as > > Marius and others advised me in another thread), and I discovered that after > > I add an item, then try to add another one, the first one is modified, which > > would mean that the same snippet instance is used (the snippet - TD - is a > > reflection snippet, as far as I understand the terminology). > > > >>>> That would mean that reflection snippets have the same scope as > > RequestVars, that is that there's at most one instance per rendered page. > > Marius wrote that this changes recently, so maybe it's a side-effect? > > > >>>> Also, do you think that "RequestVar" is a good name? For me it > > suggests a variable which has a lifecycle only for one http request. In the > > Seam framework, for example, there are two scopes: request and page (and > > many others), the first one being a "true" request scope, the second having > > essentially the same scope as RequestVar. So maybe it should be called > > PageVar? > > > >>>> -- > > >>>> Adam > > > >>>> -- > > > >>>> You received this message because you are subscribed to the Google > > Groups "Lift" group. > > >>>> To post to this group, send email to lift...@googlegroups.com. > > >>>> To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > >>>> For more options, visit this group athttp:// > > groups.google.com/group/liftweb?hl=en. > > > >>> -- > > > >>> You received this message because you are subscribed to the Google > > Groups "Lift" group. > > >>> To post to this group, send email to lift...@googlegroups.com. > > >>> To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > >>> For more options, visit this group athttp:// > > groups.google.com/group/liftweb?hl=en. > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > > To post to this group, send email to lift...@googlegroups.com. > > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > > For more options, visit this group at > >http://groups.google.com/group/liftweb?hl=en. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/liftweb?hl=en. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/liftweb?hl=en. > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
