On Tue, Dec 29, 2009 at 1:58 AM, Adam Warski <a...@warski.org> 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<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.
