On Mon, Dec 28, 2009 at 11:11 AM, 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? > Lift does not keep references to snippets across full page loads, except for StatefulSnippets. > Why was this changed made, first of all? There were two different feature/clarification requests relating to keeping the same snippet instance around during a single page render and having the same snippet around during the Ajax callback. > Why take away the flexibility to choose to use multiple instances of a > class on the same page? Actually, it doesn't. If you want to have separate instantiations of an instance that handles a given snippet, you can do it manually in the snippet. It's marginally more work, but it's also not the common case. > And was a "Breaking Change" email sent out? > Naftoli, this comment is beyond the bounds of good behavior on this list. You have no place demanding this. The two changes (which in my mind were clarifications of unspecified behaviors in Lift) were made many months ago. If these changes had caused you a problem when they were made, there might be an argument for you to be unhappy about the behavior change. But many months after the change took place, you have no place making this kind of statement. > If all snippets get placed in a RequestVar is there still a purpose in > using RequestVars within a snippet? > That's one of the reasons we made the change... because its more natural to use instance variables in a Snippet rather than RequestVars. > Another question I never got around to asking: Why does StatefulSnippet > extend DispatchSnippet? > Because I believe that doing the explicit dispatch is a better practices. Once you're into making StatefulSnippets, you can write the 1 extra line per snippet for the dispatch. > 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. > 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> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- 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.
