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