Re: [Lift] Snippet lifetime

2009-12-29 Thread Adam Warski
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've updated the wiki page a bit: 
http://wiki.github.com/dpp/liftweb/about-snippets, if some lift gurus would 
want to review.
So far it lists the following snippet kinds:
* reflection
* dispatch
* singleton dispatch
* stateful

I'm not sure if there are any other, but if there are, maybe somebody could 
mention them there, so that people would be at least aware of their existence 
and look up in the source code later.

-- 
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] Snippet lifetime

2009-12-29 Thread Timothy Perrett
Nope, that looks cool - thanks for updating that.

Cheers, Tim

On 29 Dec 2009, at 10:26, 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've updated the wiki page a bit: 
 http://wiki.github.com/dpp/liftweb/about-snippets, if some lift gurus would 
 want to review.
 So far it lists the following snippet kinds:
 * reflection
 * dispatch
 * singleton dispatch
 * stateful
 
 I'm not sure if there are any other, but if there are, maybe somebody could 
 mention them there, so that people would be at least aware of their existence 
 and look up in the source code later.
 
 -- 
 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] Snippet lifetime

2009-12-29 Thread David Pollak
On Mon, Dec 28, 2009 at 8:04 AM, 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?


Yes.  While they require a tad more code, they are type safe.  My take on
by convention is it's great when you and one or two other people are
whipping stuff together in a hurry.  As the project moves from rapid
prototyping to sustainable coding, being explicit with the dispatch makes it
easier for others to follow the code flow.



  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.


There was a particular use case for the TransientRequestVar, so I added it
and made it available only to the http package.

If you can describe a place where the current RequestVars do not work for
you, we can talk some more.



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




Re: [Lift] Snippet lifetime

2009-12-29 Thread David Pollak
On Tue, Dec 29, 2009 at 3:36 PM, Ross Mellgren dri...@gmail.com wrote:

 On Dec 29, 2009, at 6:28 PM, David Pollak wrote:

 On Mon, Dec 28, 2009 at 8:04 AM, 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?


 Yes.  While they require a tad more code, they are type safe.  My take on
 by convention is it's great when you and one or two other people are
 whipping stuff together in a hurry.  As the project moves from rapid
 prototyping to sustainable coding, being explicit with the dispatch makes it
 easier for others to follow the code flow.



  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.


 There was a particular use case for the TransientRequestVar, so I added it
 and made it available only to the http package.

 If you can describe a place where the current RequestVars do not work for
 you, we can talk some more.


 I've wanted them to cache information that isn't trivial to compute, but
 that I wanted to be regenerated on each AJAX call, for an app with a page
 that could be on-screen and doing AJAX calls for perhaps half an hour or
 more.


object Foo extends RequestVar[Box[BigHairyComputation]](Empty)

def myAjaxCallback(): JsCmd = Foo.doWith(computeValueForThisRequest) {
  // do stuff related to doing the Ajax call
}

In the above code, the lifetime of the value calculated by
computeValueForThisRequest is the call to doWith.


 In the end I whipped up controlled cache invalidation and stashed the
 cached information on a StatefulSnippet.

 I think they would be a good generally useful thing to have, personally.

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




Re: [Lift] Snippet lifetime

2009-12-28 Thread Timothy Perrett
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.

Reflection snippets do not have the same scope as request vars... rather, the 
snippet is held in a request var.

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 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] Snippet lifetime

2009-12-28 Thread Adam Warski
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 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.




Re: [Lift] Snippet lifetime

2009-12-28 Thread Alex Boisvert
On Mon, Dec 28, 2009 at 8:04 AM, 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?


DispatchSnippets support dynamic dispatch:  you can change how tags are
dispatched based on some state.

With (reflection-based) snippets, there's a direct binding between the tag
and the class name + method.  Well, unless you override
LiftRules.snippetDispatch.

alex

--

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] Snippet lifetime

2009-12-28 Thread Adam Warski
 
  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?
 
 DispatchSnippets support dynamic dispatch:  you can change how tags are 
 dispatched based on some state.
 
 With (reflection-based) snippets, there's a direct binding between the tag 
 and the class name + method.  Well, unless you override 
 LiftRules.snippetDispatch.
Ah right. Thanks. I'll modify the wiki once I gather all the answers :)

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.