|Re: Where are the templates?|
April 2, 2004, 8:26:45 pm
This has been a pretty interesting comment through about the way Avi suggests people make web applications. To put it simply, he suggests they should be coded, not drawn. I have to say there is a certain domain to where you can do this and then it stops.
To clarify. Programming a page that is all dynamic information, eg: a document interface - not a business object interface, is not a good way to make a UI in code. You are wasting your time doing a translation.
But! Any where you have patterns, ie: most ui's: label: value, label: value, label: value, then you should shoot yourself in the foot if you don't patternise this process in some form or manner. Avi's suggested using Smalltalk to do it. Why? Because Smalltalk is such a descriptive language and adaptive language.
I've had plenty of experience writing both Smalltalk and XSLT these days for producing browser-based UI's and neither really suits my needs entirely. I need a blend, which is what I do these days. When it comes to creating lots of elements quickly, I write them in their natural form - XML. When it comes to lots of data that I need to patternisedly display, I use Smalltalk (sometimes).
I do agree with the design issue of developers being about to use their favourite tools to 'template' their pages. But in the end, the more powerful your browser app becomes the less you can use that, because most of the page information comes from your app. What do you have in your template? styling mostly.. which is not the place to put it - that should be in the CSS.
Avi rightly points out that Seaside has browser assumptions. Everything comes over in a big bang and everything goes back in a bigbang. In WithStyle, we intend to change that. We're going to add something along the lines of a 'dynamic include' for any node in an XML document. Eg:
<ul magic:href="http://www.myserver.com/listitems"/> in this piece of XML, we haven't stated what's inside the UL, we've told WithStyle where it can go and find those items. Now, if we abuse HTTP/1.1 a little, we can keep the connection open and receive updates from the server for that set of LI's at any time we want.
Not all the information on a web page is linked back to real data. To work this, HTML Forms were invented.. but those are a little limited - bulky bits of form on the screen - yuck. What we want to be able to do is link any node back to the server and let the server know if it changes.
<span magic:href="http://www.myserver.com/submit" style="user-modify: read-write"/> in this piece of XML, we're getting the data for the span from the server, but we're also saying its read-write via a CSS setting. Now if the user changes that information, WithStyle should send the information back to the server, which may or may not then give us other information on other parts of the page.
This is the direction we'll be heading in a few months time.