Scrap Templates move to XSLT + PHP

Author Message

Willie Seabrook

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

Jan Borsodi

Monday 08 September 2003 2:38:40 am

Actually the goal of template systems is to separate content from presentation. This is exactly what the eZ template system does.
There is also some separation of logic from presentation, most of the logic is done in PHP code but controlled by the template.

When we started working on the new template system our primary goal was to have a system that would give lots of control to the designers/implementers while still retaining control of what is allowed to be done, for instance a designer can fetch the data he wants dynamically but cannot write PHP code directly that accesses files or other parts.

Most template systems are either to free allowing you to do too much and others are too restrictive since the underlying code controls the data that are present for the template.

By using something like XSLT you will end up with the latter, XSLT was primarily meant to transform the data that is already present not fetch data dynamically and the transform it.

As for dreamweaver issue I believe it's a dreamweaver problem and not an eZ template problem. Dreamweaver (as far as I know) were meant to work on static pages while eZ template is meant to allow dynamic pages.
So until dreamweaver gets support for custom template languages and allows you to give it example data (or fetch from eZ publish) you can't use it directly for template work. However you can use dreamweaver to set up to basics of the site and then add in template code to handle the dynamics.

I also don't think XSLT is that easy to work with, it's a really complicated system.

Short said: We will not change the template system.

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq

Alan Sparkes

Monday 13 October 2003 12:10:25 pm

I am new to EZ and certaily no real developer/programmer. However, i have spent the last few years hacking and designing PostNuke themes. THey are currently working on a template engine whioch uses smarty [?] which is simpler than ez templates but still requires a little programming frame of mind. On the other hand systems lke Mamboserver have a complete wysiwyg template system but it is a bit limiting.

My experience over the last few years has now put me in a position to really appreceiate the information architecture available in ezpublish. However, the template system is complex and, although, i have learnt alot today, I can't see where the 'ez' is in publishing. It seems that you cant get a whole site off the ground without knowing a language which actually looks more complex than php! I'd rather learn more php and embed it in my html than learn another template language. That said I can see that it is not possible to provide this level of flexibility and power with a single wysiwyg editable template - be nice but i can't see it happening.

ez is really designed by programmers - it shows in the object everything. Cool i love it but it aint gonna win alot of html/css image designers over any time soon. But I guess you make an investment and benefit...eventually!

If ezsystems can give it away I can spend a few hrs learning it

alans

Paul Borgermans

Monday 13 October 2003 12:29:38 pm

Alan,

Thanks for your input

If template language complexity is an issue (and it may well be for quite a few ez users), the good news is that for part of the audience, customisation will be largely point and click in ezp 3.3 and beyond.

I appreciate the template system since it reflects also the architecture / functions of ez publish (and should not go beyond that), in spite of some shortcomings.

For pure content (which in our and others situation will be more and more xml variants), the xslt add-on is a must for rendering. For the rest (page-layout and other functionality), the ez template system is fine and pretty powerful.

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Björn [email protected]

Monday 13 October 2003 1:17:52 pm

From my understanding of XSLT

it would mean that we could have one template that could e.g generate PDF or HTML output.

This also would mean we no longer use the html inside the templates.

we can still use the current eZ template logic

we have better validation

This shoulds all reasonable and good to me.

Whatever... most of the time eZ does it right.

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Paul Borgermans

Monday 13 October 2003 1:25:17 pm

XSLT:

there is one exception: the possibility to embed other objects in your ezxml text fields and choose a view type. This would require some more processing (xml doc has to be "massaged" to get meaningful input for a xslt spec).

For other future xml field variants, this may well be the solution (re-use existing xslt sheets).

-p

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.