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

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

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