Forums / Suggestions / Suggestion for template syntax: XML markup?

Suggestion for template syntax: XML markup?

Author Message

Harry Fuecks

Tuesday 24 June 2003 3:30:44 pm

Going to say something scandalous (please forgive in advance) but I don't like the template syntax. Basically it means learning another language and I get the feeling it may put (some) people off eZP3.

Wondering if you'd be willing to switch to (or additionally support) a pure XML markup at some point in the future? Think, looking at what you've got already, it wouldn't be too hard; the template classes already define a set of "compile time" components and can probably be (relatively) easily adapted to an XML markup.

The advantage as I see it is two fold. First think XML will be alot easier for people to work with, the basic "syntax" being well known. Second it would make it alot easier to design / generate eZ publish templates from some tool or other.

As an approximate guess example of how it could work, taking part of the basket.tpl template from the /design/standard/shop/ directory, specifically the main table, in XML is *might* look something like this;

<ez:section name="ProductItem">
<loop id="basket" dataSource="Basket" iterateOver="items">

<sequence id="basketRowColor">
<element>bglight</element>
<element>bgdark</element>
</sequence>

<tr>

<td classDecorator="basketRowColor">
<input type="hidden" name="ProductItemIDList[]" dataSource="Basket" dataKey="id" />
<a baseUrl="/content/view/full/" dataSource="Basket" dataKey="node_id">
<textItem dataSource="ProductItem" dataSource="ProductItem" dataKey="object_name" />
</a>
</td>
<td classDecorate="basketRowColor">
<input type="text" name="ProductItemCountList[]" dataSource="Basket" dataKey="item_count" size="5" />
</td>

<td classDecorator="basketRowColor">
<textItem dataSource="ProductItem" dataSource="ProductItem" dataKey="vat_value" />
</td>
<td classDecorator="basketRowColor">
<textItem dataSource="ProductItem" dataKey="price_ex_vat" unit="currency" intl="true"/>
</td>
<td classDecorator="basketRowColor">
<textItem dataSource="ProductItem" dataKey="price_inc_vat" unit="currency" intl="true" />
</td>
<td classDecorator="basketRowColor">
<textItem dataSource="ProductItem" dataKey="discount_percent" unit="%" />
</td>
<td classDecorator="basketRowColor">
<textItem dataSource="ProductItem" dataKey="total_price_ex_vat" unit="currency" intl="true"/>
</td>
<td classDecorator="basketRowColor">
<textItem dataSource="ProductItem" dataKey="total_price_inc_vat" unit="currency" intl="true"/>
</td>
<td classDecorator="basketRowColor">
<input type="checkbox" name="RemoveProductItemDeleteList[]" dataSource="ProductItem" dataKey="id"/>
</td>
</tr>
</loop>
</ez:section>

Also I think it's probably alot easier to document XML as well as being able to define XML schemas to help with validation.

Just a thought.

Gabriel Ambuehl

Wednesday 25 June 2003 1:19:14 am

How about XSLT?

Visit http://triligon.org

Bård Farstad

Wednesday 25 June 2003 1:27:50 am

Harry, I see your point. We're should consider this, however changing the template syntax at this point is a rather big thing.

--bård

Documentation: http://ez.no/doc

Ekkehard Dörre

Wednesday 25 June 2003 2:41:45 am

It is a big think, but a good one. There are a lot of Template Systems out there, all with different Syntax. It makes me crazy.
I only saw one with xslt as Template Language:

http://bitflux.ch/developer/cms/
"
Bitflux CMS is an XML and PHP based Content Management System. It allows you to reuse your content in different ways."

That is one interesting point:
Use EzP for everything is more easy: Html, PDF, PDF for high-resolution Printing (pre-press) Wap, etc.

"Bitflux CMS uses as "template" engine XSLT and almost everything is configurable with XML."
XSLT is a Standard, ezTemplate Syntax not.


There are very good Ideas inside, rendering of the xslt files via Popoon http://bitflux.ch/developer/cms/popoon.html it is GPL and an PHP adaptation of cocoon http://cocoon.apache.org/2.0/index.html

But it is not comparable with ez.

But the Template Syntax is the only conceptual bad think in EzP I saw.

I think I saw in the Roadmap for EzP 4 with the more OO PHP5, it becomes completely new, perhaps then?

Greetings ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing

Gabriel Ambuehl

Wednesday 25 June 2003 4:28:24 am

While I like XSLT for what it is (an easy way to convert XML.x to XML.y) it can't do all of the functionality that eztemplate currently handles, mostly because it isn't a procedural language and there are no ways to reassign variables or create custom function calls that would allow it to retrieve other page elements.

XSLT is very good at taking a finished XML piece and turning it into XHTML but is less good at assembling XML documents from pieces, out of the box anyway.

That having said, PHP with libxslt enabled a is a dream to work with performance wise, something I unfortunately can't say about ezpublish (heck it takes 0.5s to render my project site on a 2Ghz machine with caching and compiling all on!).

As to bitflux, I don't know how it is these days but some 3 months ago it felt even less complete than the earliest ezp3 betas...

Visit http://triligon.org

Harry Fuecks

Wednesday 25 June 2003 9:24:45 am

It think XSLT is one alternative although it has to be used in a certain way (IMO) to translate eZP templates into a PHP script as a "compile time" process, the PHP script being "runtime" (i.e. what gets executed when a user requests a page).

I have to confess that where I'm coming from here is ASP.NET, which I've been studying recently to get ideas from that could be applied to PHP ("ASP.NET in a Nutshell" is a pretty good resource).

Overall I have to give MS their credit - they've done something very clever with ASP.NET which is invent a template syntax which relates directly to an underlying class library. Even Sun think it's smart an are following suit with Java Server Faces.

In terms of a concept, ASP.NET is a template language which is very similar to Mozilla's XUL - it relates to a library of "widgets" which are used to create objects at runtime and render the page although where XUL is for building rich clients, ASP.NET is for web pages. The big thing ASP.NET does is abstract any control structures (loops, if/else etc) out of the template (which makes it possible it possible to use an IDE to "drop and drop" a web page when designing it), as well as providing a bunch of widgets, like a calendar, which make life easy for users. Anyway - more than enough about ASP.NET.

Been having some fascinating discussion recently with PHP coders considering how to bring the same thing to PHP. The general conclusion seems to be the way to do this is to have two sets of "components", compile time components and runtime components, then parse the template, with help from the compile time components, into a native PHP script which loads / executes runtime components. The objects that the runtime script instantiates are made available for further "manipulation" by the "controller" code (the specific application code) to do things like allow the runtime components to display different HTML/content if a particular HTTP request is received. Making sense?

I've been playing working on a couple of PEAR projects recently that could be the foundations for a parser, PEAR::XML_HTMLSax (a parser for badly formed XML) and one I've recently submitted, XML_SaxFilters, which is yet to be accepted. Reason I'm mentioning these here is I made a crude attempt doing this for an example which may help explain better;

The original template begins looking like this;

http://code.phppatterns.com/XML_SaxFilters/docs/examples/page_template.tpl.phps

Once parsed the output looks like this;

http://code.phppatterns.com/XML_SaxFilters/docs/examples/compiled_template.phps

The "runtime components" are imaginary and the compiled template is very crude but hopefully it demonstrates the point.

The script that parsed this looks like;

http://code.phppatterns.com/XML_SaxFilters/docs/examples/template.phps

The filters in that script are (poorly abstracted) "compile time" components.

This is using SaxFilters, which is only one approach. A badly formed DOM parser might be alot better. For more information on SaxFilters the docs I've written are;

http://code.phppatterns.com/XML_SaxFilters/docs/Readme.phps
http://code.phppatterns.com/XML_SaxFilters/docs/SaxFiltersGuide.phps

The complete code is up at;

http://www.phppatterns.com/index.php/filemanager/fileview/29/

Apologies if that sounds like self promotion - not intended but simply to share ideas.

Paul Borgermans

Wednesday 25 June 2003 2:06:09 pm

Harry,

I see your point, and I agree the current template system is not ideal. However, I see the use of xml and xslt more to support content that gets delivered inside or outside ezpublish in some xml standard (lets throw the word -docbook- again). Not to support the creation of complete pages where most people will want to assemble components from different sources.

But when it comes to having re-usable components, I too find the current template system too limited. Your suggestions are a good base for discussions in this respect. Are you joining us at the summer camp?

--paul

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

Harry Fuecks

Wednesday 25 June 2003 4:10:59 pm

<blockquote>
However, I see the use of xml and xslt more to support content that gets delivered inside or outside ezpublish in some xml standard (lets throw the word -docbook- again).
</blockquote>

Ah I see - so something to help with importing / exporting content objects? And docbook... so people could edit content offline I guess. Sounds really good. In absence of an XSLT extension that might be something that could be done with SaxFilters as well and / or something like what Sebastian Bergmann has done with PEAR::XML_Transformations - he's already got something for docbook which uses the element names to call PHP functions.

<blockquote>
But when it comes to having re-usable components, I too find the current template system too limited. Your suggestions are a good base for discussions in this respect. Are you joining us at the summer camp?
</blockquote>

I'd really love to. But... Sadly not going to be able to convince either employer or family (who want sun and beaches) this time. The program looks really good. Hopefully you'll be running some more.

Bård Farstad

Thursday 26 June 2003 12:46:38 am

Harry and Paul, I think that xslt processing should be added as an export feature. This could be the basis, or at least one possibility, of the export system.

I don't see the possibility for xslt to take over for the current template engine. It's just not the same thing.

Harry, the .NET template engine you're describing: it sounds like it's on a higher level which limits the control. Could this kind of functionality be done by adding related objects?

E.g. you would like to have a frontpage which has a list of news, a list of events and a small calendar. This could be three embeded related objects which would be rendered according to a template. If this is the functionality then you can already do this with eZ publish using related objects embeded in xml text.

--bård

Documentation: http://ez.no/doc

Paul Borgermans

Thursday 26 June 2003 10:26:59 am

>Harry and Paul, I think that xslt processing should be added as
>an export feature. This could be the basis, or at least one
>possibility, of the export system.

I agree, but xslt may be necessary to "fit" future xml documents into ez publish. No more news on more xml variants support?

>I don't see the possibility for xslt to take over for the current
>template engine. It's just not the same thing.

Neither do I, but it may be a good idea to let the template syntax evolve into some xml compliant.

>Harry, the .NET template engine you're describing: it sounds
>like it's on a higher level which limits the control. Could this
>kind of functionality be done by adding related objects?

I think Harry refers to the possibility of overloading functions and attributes, so it is imho a different thing.

>E.g. you would like to have a frontpage which has a list of
>news, a list of events and a small calendar. This could be
>three embeded related objects which would be rendered
>according to a template. If this is the functionality then you
>can already do this with eZ publish using related objects
>embeded in xml text.

The point is to have re-usable components. This can partly be done with clever template programming now (it really is programming/hacking around things), but we need more features like fetch filters on attributes and an easy and more general way to pass variables between templates.

Oops, and import/export of classes tied to templates ;-)

--paul

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

Harry Fuecks

Monday 30 June 2003 2:57:12 am

Apologies for long wait - partly thinking and partly workload.

Guess an ASP.NET-like template system wouldn't entirely fit to eZ publish as is, given the potential for content classes, which could make building custom "widgets" alot easier. Exactly how this would fit together I can't quite see at the moment - have more or less grasped a solution to the problem implemented in "normal" PHP but how exactly this would fit to eZ publish content classes has my brain on loop right now.

>>Harry, the .NET template engine you're describing: it sounds
>>like it's on a higher level which limits the control. Could this
>>kind of functionality be done by adding related objects?

>I think Harry refers to the possibility of overloading functions >and attributes

I guess the answer is yes to both. Widgets could be defined as content classes while the template syntax is overloaded to make it "expressive" for a particular widget. Having said that, perhaps "runtime" widgets would be better implemented in PHP along the lines of the current eZ publish data types.

Not too clear... like I say, still working out how I'd do this normally with PHP.

> import/export of classes tied to template

Second that.