|
Friday 29 August 2003 6:44:29 pm
Hi, The goal of a templating system are to remove logic from presentation and hence make things easier for a designer. Ez templates do not do either of these things. Firstly, ez makes it impossible to use a wysiwyg html editor like dreamweaver. This is because of the {section} etc tags. This means that you have to do most of your editing in plain html which takes a lot of time. In dreamweaver I can change something i need to in under a minute, by coding it will take me at least 10 to change and see if it comes out ok. Thats an efficiency slap of 1000%. That sucks. Secondly, it does not remove logic from design. Because you still have assignments and loops contained *within* your html through section, let, set etc "template" tags. What this really does is the same thing as having php inside your html (stupid) but your crippled because the template language features are so bare. In generating a database driven site, *most* things can be done with pure templates. But there will always remain a little bit of logic require (like get last 10 articles, loop through and show them) so we have to have a solution that allows for that sort of thing. But the current solution, the template language, is far too crippled. In order to accomplish the goals of content/logic seperation yet still logic use in my opinion, the best way to go about things is as follows. Request -> Generator + Template -> User view. This involves the use of four technologies - xml, xslt, html and ez. It borrows ideas from similar systems in Java. Here is what override.ini entries would look like:
#My Class in a special section
[MyClass]
Source=node/view/full.tpl
UseGenerator=/mysite/generators/special/
UseTemplate=/mysite/templates/MyClass/special/
Subdir=templates
Match[class]=12
Match[section]=10 In /mysite/templates/MyClass/special there exists a number of files, depending on how many presentations you want. IE:
special.tpl.html
special.html.xslt
special.tpl.wml
special.wml.xslt
special.tpl.xml
special.xml.xslt and so on. Use would be determined on the fly by the type of request ez gets. In /mysite/generators/special/ there also exists a number of entries to match the ones in templates.
special.html.php
special.xml.php
special.wml.php
special.php The specific ones are optional, the generic one (special.php) is not. I would not reccomend usage of specifc ones as it sort of removes the xslt advantage. On a request for that object, the generator php file is called and in there you have ready made access to the node that has been called (through php api). You probably wouldnt need, or shouldn't need, to use it much though - *but it still gives you the power of a real programming language*. The generator returns xml which is fed into the xslt file, and combined with html, xml, wml template etc, whichever was asked for by the request. Now you wouldn't have to do much to display an object, perhaps the generator here by default just returns the parameters of the object serialized as xml, ie you would only have to do the xslt and html. Simple. Now the real benefit comes in the parts that we are currently crippled by ez templates. Displaying a list of something in an html file. For example, a folder node, listing all the articles in it. The generator for the folder can then use the api to return a dom tree of all the articles in it, the xslt transforms it into html (or wml etc) output, which is shoved into your template using only a variable.
This method means:
We have a full programming language at our disposal for logic.
There is *complete* logic seperation from presentation (only variables in templates, in order to output the result from the xslt transformations of the generator xml output)
Hence we can use wysiwyg
There are great xslt editors out there too for that part. I think this is a much cleaner way to do things. Its another layer, but its *easier* and thats what counts. I reckon there would be significant reduction in the ez learning curve (no learning wierdo template language), significant ez developer productivity enhancements (no coding html by hand cause we can't use dreamweaver), and significant feature enhancement (full programming language at our disposal). Your thoughts please? Ez people?? Description is rather vague and has been typed out at thought speed. I can elaborate with hypothetical examples if requested.
Regards,
Willie
|