Thanks,
I missed the power of the passing the binding back and forth for the
snippet. This gives me something to chew on.
I understand the bit about 'html not being presentation', that is
becoming more prevalent these days.
So the convention about not putting logic in the template is more
important then templates in the controller, and that does make a lot
of sence.
thanks!
-Aaron
On May 6, 12:51 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> Aaron,
>
> Short answer: Lift's templating makes it nearly impossible to put business
> logic into the view, but it is possible to put view logic into your Scala
> code. Using Lift's bind'ing mechanism, it's possible to completely separate
> the view logic from the business logic.
>
> Longer answer:
> Lift's templating mechanism is a non-type-safe interface between XHTML
> template files and Scala code. Lift finds tags of the format <lift:xxx> and
> uses xxx to look up a snippet which generates dynamic content. Lift looks
> up the snippets in a number of ways including "by convention" (using
> reflection to look for classes and methods that match the snippet name) and
> by registering PartialFunctions as a lookup mechanism for snippets.
> Snippets may also be registered on a page-by-page basis using SiteMap.
>
> "by-convention" snippets may be of two forms: methods that take no
> parameters (e.g., HelloWorld.howdy) and methods that take the snippet
> invocation body as a parameter. All other snippets must take the snippet
> invocation body as a parameter.
>
> If we have a case where the snippet takes the invocation body is a
> parameter, we can bind dynamically generated content to view information.
> For example:
>
> <lift:HelloWorld.howdy>
> <span>Welcome to helloworld at <b:time/></span>
> </lift:HelloWorld>
>
> The snippet would look like:
>
> class HelloWorld {
> def howdy(xhtml: NodeSeq): NodeSeq = Helpers.bind("b", xhtml, "time" ->
> (new java.util.Date).toString)
>
> }
>
> In this case, we have complete view/logic separation. The body of the
> snippet tag (in this case <span>Welcome to helloworld at <b:time/></span>)
> is passed to the snippet and the snippet merely binds the dynamic content to
> the view template. In this way, you are guaranteed that there's no logic in
> the view and if you follow good practices in terms of binding, there will be
> no view code in your business logic.
>
> So, when does it *not* make sense to put all your view code in the view
> templates?
>
> - When I do quick prototyping, I put view code in my business logic.
> There is an extra step to do best practices binding and when I'm knocking
> something together, I find that it's quicker to use XML literals in my
> Scala
> code.
> - Some of Lift's "scafolding" code (e.g., ProtoUser, CRUDify) has
> embedded view code. This is so that all the code is self-contained. I
> view
> ProtoUser and CRUDify as tools for prototyping, not for long term
> production
> code. I expect that as projects expand from 1 to 3 people putting together
> a proof of concept to a team with clear deliniation of tasks that these
> traits will be extracted from the code and that the view code will be
> extracted to templates.
> - Sometimes HTML is not view code. In Buy A Feature's game play grid,
> there are a lot of HTML literals in the comet code. These literals are
> things like <span id={....}>{content}</span>. The id of the span is
> important because it relates to the place on the game grid where the cell
> goes. The fact that it's an HTML tag is overshadowed by the fact that it's
> a small nugget of something that needs to be put in a particular place on
> the browser page. The actually layout of the browser page is controlled by
> the CSS. One might argue that all the data should go from the server app
> to
> the browser via JSON and then the update should take place in JavaScript.
> We did this for Prune the Product Tree (another Innovation Game.) Turns
> out
> that JavaScript is not type-safe which led to a bunch of errors. Further,
> generating view code in JavaScript is error-prone (what do with HTML
> encode?) and it's logic anyway. So, having the logic stick in on the
> server
> in a higher performance, strongly typed language is a better choice.
>
> I've revised the archetypes to use better practices. Also, please look at
> the Getting Started guide. The ToDo example uses all binding.
> Additionally, the sites/example code is almost all view/logic separated
> (except in cases demonstrating that view code can appear in the Scala).
>
> Thanks,
>
> David
>
>
>
> On Wed, May 6, 2009 at 8:11 AM, Aaron <aarondh...@gmail.com> wrote:
>
> > So far I'm impressed with Lift and have gone through the toy-app stage
> > of experimenting. I have my own framework in production powering large
> > scale sites likehttp://www.comcast.netand real experience with
> > Django.
>
> > I'm a little sketchy on the thinking behind this type of display logic
> > deep in the code. For example
>
> > Snippet:
> > class HelloWorld {
> > def howdy: NodeSeq = <span>Welcome to helloworld at {new
> > java.util.Date}</span>
> > }
>
> > In Model:
> > override def loginXhtml =
> > <lift:surround with="default" at="content">
> > { super.loginXhtml }
> > </lift:surround>
>
> > In real applications are people delegating this type of rendering to
> > template files? In a freemarker world I have template macros
> > (snippets) that would look like
> > <#macro helloWord>
> > <span>Welcome to helloworld at ${exec.RunCustomDateFunction}
> > </#macro>
>
> > or server code that would look like
> > (In horrible python/java psudocode)
> > function(){
> > render_and_return(template('helloWorld', {date: new
> > java.util.Date} )
> > }
>
> > I have strict rules about who gets to edit templates and who gets to
> > edit server code. Template code should NEVER affect server profiles
> > (of course it can with bad javascript/ajax) and server code should
> > never have display data.
>
> > (In my world...) Display / presentation changes should NOT require
> > a .war deployment
>
> > I'm basically asking for other people's thoughts in this direction. I
> > have multiple HTML/CSS/JS experts and multiple Server devs. Is this
> > something that will 'people scale' in the way I need it to?
>
> > We currently have Groovy embedded in places and were looking at
> > Grails. The problem is that it is groovy is not as fast to code in as
> > Ruby and Grails is not much easier to deploy then a .war (because we
> > have automation). Lift solves some real problems for us and Scala
> > seems like a language with real benefits.
>
> > Besides SpringSource is offering Grails support so we don't want to be
> > too mainstream ;)
>
> > Thanks,
> > -Aaron
> >http://www.aaronheld.com
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@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
-~----------~----~----~----~------~----~------~--~---
