Gotta go to a meeting, but I'll post more later. (I was planning to anyway.) And I've been working on something along these lines in Lift, but the need to make a living keeps interfering, dammit.
Chas. Meredith Gregory wrote: > 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 > <mailto: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> > > <mailto: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> > > <mailto: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> > > <mailto: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> > > <http://liftweb.net> > > >> Beginning Scalahttp://www.apress.com/book/view/1430219890 > <http://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 -~----------~----~----~----~------~----~------~--~---
