Chas, Oooh! i love miracles, as in how we get from 'here' to 'there' is 'and then a miracle occurs'.
On the other hand, another way to accomplish a miracle of this type is by fiat. There's nothing to prevent lift from providing a code path that works like this, along side a code path that includes the current HTML nightmare. If there is genuine value in the vision, eventually people will start to gravitate to the other way of doing things -- especially, if there are some compelling examples that match what they are trying to do in their immediate concerns. Can you lay out the necessary pieces in more detail (for an idiot, like myself)? Can we make one sample site that works like this? Best wishes, --greg On Thu, May 7, 2009 at 10:46 AM, Charles F. Munat <c...@munat.com> wrote: > > Oh, it's a pretty vision. The part that's missing, though, is the part > where we get there from here. Still working on that part... > > Chas. > > David Pollak wrote: > > > > > > On Wed, May 6, 2009 at 7:13 PM, Charles F. Munat <c...@munat.com > > <mailto:c...@munat.com>> wrote: > > > > > > Yeah, the whole thing is kind of a joke. > > > > Long ago we should have abandoned HTML for XML. The server should > send > > the content (data) in one file with full semantic markup. Another > file > > should contain a stylesheet that controls full page layout, plus > vector > > graphics and raster images with on-the-fly resizing. > > > > Page layout should be rule-based and dynamic. The graphic designer > > creates a set of rules, sectioning the content and selecting colors, > > proportioning, alignment, etc. Then the browser reflows and updates > the > > view as the user resizes the window or changes type size. > > > > As a user, I should be able to grab sections of a page and drag them > out > > to become new pages, or pull them back in again. I should be able to > > hide or show any part of a page, or rearrange the parts. I should be > > able to resize type and images so they're clear to me. And the site > > navigation should show up as a "site" toolbar on the browser, not in > the > > pages themselves. Chrome missed the boat on this because they're too > > busy thinking of the page as the atomic unit. > > > > Now the database developer worries only about the data model. The > > application programmer worries only about business logic and sending > > semantically-marked-up data to the browser. The information architect > > worries only about which pages will need what information and how the > > navigation system will work (with navigation delivered as a separate > XML > > file), and the graphic designer worries only about the layout of > > individual pages, making sure that they look great at any resolution, > > window size/shape, or type size. > > > > > > I love this vision! > > > > > > > > HTML is a mess, combining semantic information with structural > > information, metadata, and even some presentation. > > > > But I guess we're stuck with it. Under the current circumstances, my > > opinion is that we should do the best we can to separate concerns, > but > > not be too totalitarian about it. > > > > Chas. > > > > > > Aaron wrote: > > > 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 > > <mailto: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 > > <mailto: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 > > <http://liftweb.net> > > >> Beginning Scalahttp://www.apress.com/book/view/1430219890 > > <http://www.apress.com/book/view/1430219890> > > >> Follow me:http://twitter.com/dpp > > >> Git some:http://github.com/dpp > > > > > > > > > > > > > > > > > > > -- > > Lift, the simply functional web framework http://liftweb.net > > Beginning Scala http://www.apress.com/book/view/1430219890 > > Follow me: http://twitter.com/dpp > > Git some: http://github.com/dpp > > > > > > > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
