[Lift] Re: Snippet lifetime
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? Br's, Marius On Dec 28, 6:04 pm, Adam Warski 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.
[Lift] Re: Snippet lifetime
On Dec 28, 7:19 pm, Adam Warski 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). TransientRequestVar could technically be made public but I don't see compelling reasons to do that (yet). Do you need to do some logic right before sending down the response? What is your use-case? > > 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. Because DispatchSnippets don't use reflection and as Alex said they are more dynamic. > > > Br's, > > Marius > > > On Dec 28, 6:04 pm, Adam Warski 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. > >
[Lift] Re: Snippet lifetime
On Dec 28, 7:46 pm, Adam Warski wrote: > Hello, > > >> 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). > > > TransientRequestVar could technically be made public but I don't see > > compelling reasons to do that (yet). Do you need to do some logic > > right before sending down the response? What is your use-case? > > Well for changing the tutorial form into an ajax form I guess the best > solution is to store the model instance in a RequestVar and simply set it to > a new instance after saving. So I don't have any immediate use-cases. > > But in other (Seam) projects I remember that I used the event scope > (corresponding to TransientRequestVar) quite often, for example to have a > single-request cache (things which may be invalidated even on the next ajax > request). > > Also, I suppose that you need to hold a reference to all RequestVars as long > as the user doesn't request another page, or as long as his session doesn't > time out. You don't know if the page will make ajax callbacks or not, right? Sure we know since Lift's ajax functions that have bound Scala functions are inherently kept on the LiftSession. RequestVar's are preserved (and not only them) by a mechanism that we call snaphot- restorer which simply based on Scala's reference capturing. > And even if you knew, you wouldn't know if the callbacks are going to use the > vars. So potentially there may be a memory problem. I would expect request > vars to be a bit "lighter" (a TransientRequestVar can be discarded right > after >the request processing finished). I really doubt the memory is an issue here. The amount of RequestVars used is typically quite low. Keep in mind that bound functions are subject to a garbage collection mechanism built in Lift. You may have noticed periodical __lift_GC__ Ajax request being sent from browser. This is a lease mechanism. So if bound functions are not "revitalized" they will expire and will be removed. > > -- > 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 at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Snippet lifetime
On Dec 28, 9:11 pm, Naftoli Gugenheim 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 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 > wrote: > > > > > And what's the difference to a StatefulSnippet? > > > - > > Adam Warski 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 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 >
Re: [Lift] Re: Snippet lifetime
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 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.
Re: [Lift] Re: Snippet lifetime
Hello, >> 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). > > TransientRequestVar could technically be made public but I don't see > compelling reasons to do that (yet). Do you need to do some logic > right before sending down the response? What is your use-case? Well for changing the tutorial form into an ajax form I guess the best solution is to store the model instance in a RequestVar and simply set it to a new instance after saving. So I don't have any immediate use-cases. But in other (Seam) projects I remember that I used the event scope (corresponding to TransientRequestVar) quite often, for example to have a single-request cache (things which may be invalidated even on the next ajax request). Also, I suppose that you need to hold a reference to all RequestVars as long as the user doesn't request another page, or as long as his session doesn't time out. You don't know if the page will make ajax callbacks or not, right? And even if you knew, you wouldn't know if the callbacks are going to use the vars. So potentially there may be a memory problem. I would expect request vars to be a bit "lighter" (a TransientRequestVar can be discarded right after the request processing finished). -- 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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Snippet lifetime
And what's the difference to a StatefulSnippet? - Adam Warski 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 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 th
Re: [Lift] Re: Snippet lifetime
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 wrote: > And what's the difference to a StatefulSnippet? > > - > Adam Warski 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 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, visi
Re: [Lift] Re: Snippet lifetime
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? Another question I never got around to asking: Why does StatefulSnippet extend DispatchSnippet? 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 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 wrote: > And what's the difference to a StatefulSnippet? > > - > Adam Warski 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 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 messag
Re: [Lift] Re: Snippet lifetime
On Dec 28, 2009, at 12:46 PM, Adam Warski wrote: > Hello, > >>> 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). >> >> TransientRequestVar could technically be made public but I don't see >> compelling reasons to do that (yet). Do you need to do some logic >> right before sending down the response? What is your use-case? > Well for changing the tutorial form into an ajax form I guess the > best solution is to store the model instance in a RequestVar and > simply set it to a new instance after saving. So I don't have any > immediate use-cases. > > But in other (Seam) projects I remember that I used the event scope > (corresponding to TransientRequestVar) quite often, for example to > have a single-request cache (things which may be invalidated even on > the next ajax request). I've had this desire, though I ended up working around it. I think that RequestVar should really be PageVar, but unfortunately I think RequestVar is fairly set in stone at this point. -Ross -- 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.
Re: [Lift] Re: Snippet lifetime
It could be changed, if it's thought worth it, once we are on 2.8. You need a package level type alias (and def pointing to the factory). Change the name to PageVar and add some deprecated aliases. But it would be silly. Someone needed a feature--accessing a RequestVar from ajax. So now its semantics were changed to be a page var, while adding an actual request var under the name TransientRequestVar, as internal API. Now we'll rename RequestVar to PageVar? Musical chairs anyone? What should really happen, or at least have happened, is that when someone wanted the semantics of a page var in a RequestVar, instead of changing RequestVar, a new class called PageVar should have been created. As they say, hindsight is 20/20... - Ross Mellgren wrote: On Dec 28, 2009, at 12:46 PM, Adam Warski wrote: > Hello, > >>> 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). >> >> TransientRequestVar could technically be made public but I don't see >> compelling reasons to do that (yet). Do you need to do some logic >> right before sending down the response? What is your use-case? > Well for changing the tutorial form into an ajax form I guess the > best solution is to store the model instance in a RequestVar and > simply set it to a new instance after saving. So I don't have any > immediate use-cases. > > But in other (Seam) projects I remember that I used the event scope > (corresponding to TransientRequestVar) quite often, for example to > have a single-request cache (things which may be invalidated even on > the next ajax request). I've had this desire, though I ended up working around it. I think that RequestVar should really be PageVar, but unfortunately I think RequestVar is fairly set in stone at this point. -Ross -- 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.
Re: [Lift] Re: Snippet lifetime
Hello, >> Well for changing the tutorial form into an ajax form I guess the best >> solution is to store the model instance in a RequestVar and simply set it to >> a new instance after saving. So I don't have any immediate use-cases. >> >> But in other (Seam) projects I remember that I used the event scope >> (corresponding to TransientRequestVar) quite often, for example to have a >> single-request cache (things which may be invalidated even on the next ajax >> request). >> >> Also, I suppose that you need to hold a reference to all RequestVars as long >> as the user doesn't request another page, or as long as his session doesn't >> time out. You don't know if the page will make ajax callbacks or not, right? > > Sure we know since Lift's ajax functions that have bound Scala > functions are inherently kept on the LiftSession. RequestVar's are > preserved (and not only them) by a mechanism that we call snaphot- > restorer which simply based on Scala's reference capturing. Right, but still, you don't know which variables are going to be used, so you need to keep them all. So if a page doesn't use ajax RequestVars are dereferenced right after the http request finishes? >> And even if you knew, you wouldn't know if the callbacks are going to use >> the vars. So potentially there may be a memory problem. I would expect >> request vars to be a bit "lighter" (a TransientRequestVar can be discarded >> right after >the request processing finished). > > I really doubt the memory is an issue here. The amount of RequestVars > used is typically quite low. Typically - yes, but I can bet there will be usages which will require a lot of them. I would not close the possibility for developers to decide if they want to store a variable in the real/transient request scope or in the page/request scope just because typically users want page/request scope variables. Maybe this should be the "default", but certainly not the only option. > Keep in mind that bound functions are subject to a garbage collection > mechanism built in Lift. You may have noticed periodical __lift_GC__ > Ajax request being sent from browser. This is a lease mechanism. So if > bound functions are not "revitalized" they will expire and will be > removed. I'll have to read up on how Lift handles this, I guess there was a chapter in the book :) -- 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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Snippet lifetime
Hello, > 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? > Another question I never got around to asking: Why does StatefulSnippet > extend DispatchSnippet? I can only agree here. I'm quite new to Lift, but properties like if a snippet uses dispatch instead of reflection (= provides a dispatch methods) or if its instances can survive longer than a single http request (like StatefulSnippets or reflection snipptes right now) look like perfect candidates for traits. The developer would just then decide which traits to mix into his snippet, and then he would have exact control on how the snippets behave and what is their lifecycle. By the way, I find the names RequestVar and TransientRequestVar confusing also, but maybe that's because I come from a JEE/Seam background, where normally the Page/Request terminology is used. I don't know what names are used e.g. in RoR? -- 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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Snippet lifetime
These are the names we use in Lift - appreciate what your saying, but its not confusing IMHO, just different to other things you are used to. Lift is Lift, not RoR, or Seam, or any other framework ;-) Cheers, Tim On 29 Dec 2009, at 10:04, Adam Warski wrote: > By the way, I find the names RequestVar and TransientRequestVar confusing > also, but maybe that's because I come from a JEE/Seam background, where > normally the Page/Request terminology is used. I don't know what names are > used e.g. in RoR? -- 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.
Re: [Lift] Re: Snippet lifetime
Hello, > These are the names we use in Lift - appreciate what your saying, but its not > confusing IMHO, just different to other things you are used to. Lift is Lift, > not RoR, or Seam, or any other framework ;-) Sure, it's just a simple terminology switch, I don't really mind if they are named one way or the other. The only objection I would have is that I would make TransientRequestVar public, and, as Naftoli wrote, statefullness/dispatching a trait. -- 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 at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Snippet lifetime
I found RequestVar surprising/confusing at first, too, because I assumed its scope would be a single request -- but clearly isn't. My suggestion here would be to rename RequestVar to PageVar since that's closer to its lifecycle and rename TransientRequestVar to RequestVar based on my initial expectation. I think this would make it more intuitive for newbies learning lift. alex On Tue, Dec 29, 2009 at 2:49 AM, Adam Warski wrote: > Hello, > > > These are the names we use in Lift - appreciate what your saying, but its > not confusing IMHO, just different to other things you are used to. Lift is > Lift, not RoR, or Seam, or any other framework ;-) > > Sure, it's just a simple terminology switch, I don't really mind if they > are named one way or the other. The only objection I would have is that I > would make TransientRequestVar public, and, as Naftoli wrote, > statefullness/dispatching a trait. > > -- > 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 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.
Re: [Lift] Re: Snippet lifetime
On Tue, Dec 29, 2009 at 10:22 AM, Alex Boisvert wrote: > I found RequestVar surprising/confusing at first, too, because I assumed > its scope would be a single request -- but clearly isn't. > > My suggestion here would be to rename RequestVar to PageVar since that's > closer to its lifecycle and rename TransientRequestVar to RequestVar based > on my initial expectation. > TransientRequestVar is not visible for the very reason that it's not supported. It's a bad use of time talking about it because it's not going to be made public without a compelling use case and there is none I've seen on this thread or in other Lift code I've written or used. > > I think this would make it more intuitive for newbies learning lift. > > alex > > > > On Tue, Dec 29, 2009 at 2:49 AM, Adam Warski wrote: > >> Hello, >> >> > These are the names we use in Lift - appreciate what your saying, but >> its not confusing IMHO, just different to other things you are used to. Lift >> is Lift, not RoR, or Seam, or any other framework ;-) >> >> Sure, it's just a simple terminology switch, I don't really mind if they >> are named one way or the other. The only objection I would have is that I >> would make TransientRequestVar public, and, as Naftoli wrote, >> statefullness/dispatching a trait. >> >> -- >> 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 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. > -- 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.
Re: [Lift] Re: Snippet lifetime
On Tue, Dec 29, 2009 at 1:58 AM, Adam Warski wrote: > Hello, > > >> Well for changing the tutorial form into an ajax form I guess the best > solution is to store the model instance in a RequestVar and simply set it to > a new instance after saving. So I don't have any immediate use-cases. > >> > >> But in other (Seam) projects I remember that I used the event scope > (corresponding to TransientRequestVar) quite often, for example to have a > single-request cache (things which may be invalidated even on the next ajax > request). > >> > >> Also, I suppose that you need to hold a reference to all RequestVars as > long as the user doesn't request another page, or as long as his session > doesn't time out. You don't know if the page will make ajax callbacks or > not, right? > > > > Sure we know since Lift's ajax functions that have bound Scala > > functions are inherently kept on the LiftSession. RequestVar's are > > preserved (and not only them) by a mechanism that we call snaphot- > > restorer which simply based on Scala's reference capturing. > > Right, but still, you don't know which variables are going to be used, so > you need to keep them all. So if a page doesn't use ajax RequestVars are > dereferenced right after the http request finishes? > Yes. > > >> And even if you knew, you wouldn't know if the callbacks are going to > use the vars. So potentially there may be a memory problem. I would expect > request vars to be a bit "lighter" (a TransientRequestVar can be discarded > right after >the request processing finished). > > > > I really doubt the memory is an issue here. The amount of RequestVars > > used is typically quite low. > > Typically - yes, but I can bet there will be usages which will require a > lot of them. I would not close the possibility for developers to decide if > they want to store a variable in the real/transient request scope or in the > page/request scope just because typically users want page/request scope > variables. Maybe this should be the "default", but certainly not the only > option. > If it actually become a real issue, we'll address it. Otherwise, it's premature optimization. > > > Keep in mind that bound functions are subject to a garbage collection > > mechanism built in Lift. You may have noticed periodical __lift_GC__ > > Ajax request being sent from browser. This is a lease mechanism. So if > > bound functions are not "revitalized" they will expire and will be > > removed. > > I'll have to read up on how Lift handles this, I guess there was a chapter > in the book :) > > -- > 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 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.
Re: [Lift] Re: Snippet lifetime
On Mon, Dec 28, 2009 at 11:26 AM, Naftoli Gugenheim wrote: > It could be changed, if it's thought worth it, once we are on 2.8. You need > a package level type alias (and def pointing to the factory). Change the > name to PageVar and add some deprecated aliases. > It's not a PageVar. The name will not change to PageVar. > But it would be silly. Someone needed a feature--accessing a RequestVar > from ajax. So now its semantics were changed to be a page var, while adding > an actual request var under the name TransientRequestVar, as internal API. > Now we'll rename RequestVar to PageVar? Musical chairs anyone? > What should really happen, or at least have happened, is that when someone > wanted the semantics of a page var in a RequestVar, instead of changing > RequestVar, a new class called PageVar should have been created. As they > say, hindsight is 20/20... > > > - > Ross Mellgren wrote: > > > On Dec 28, 2009, at 12:46 PM, Adam Warski wrote: > > > Hello, > > > >>> 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). > >> > >> TransientRequestVar could technically be made public but I don't see > >> compelling reasons to do that (yet). Do you need to do some logic > >> right before sending down the response? What is your use-case? > > Well for changing the tutorial form into an ajax form I guess the > > best solution is to store the model instance in a RequestVar and > > simply set it to a new instance after saving. So I don't have any > > immediate use-cases. > > > > But in other (Seam) projects I remember that I used the event scope > > (corresponding to TransientRequestVar) quite often, for example to > > have a single-request cache (things which may be invalidated even on > > the next ajax request). > > I've had this desire, though I ended up working around it. > > I think that RequestVar should really be PageVar, but unfortunately I > think RequestVar is fairly set in stone at this point. > > -Ross > > -- > > 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. > > > -- 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.
Re: [Lift] Re: Snippet lifetime
On Mon, Dec 28, 2009 at 11:11 AM, Naftoli Gugenheim 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 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 >wrote: > > > And what's the difference to a StatefulSnippet? > > > > - > > Adam Warski 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 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 pack
