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.
