cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Attribute Driven Templates
Date Tue, 07 Dec 2004 17:54:15 GMT
Daniel Fagerstrom wrote:


> When I started working on a attribute template language (ATL) 
> proposal, it was obvious to me that it should be attribute name 
> driven. So why did I end up proposing a content driven one? While the 
> attribute driven is atractive for very simple examples it IMO very 
> soon becomes rather complicated as soon as you try to describe 
> something slightly more complicated. E.g. if we need more than one 
> parameter to the directive, how do we describe that? TAL uses the syntax:
> <textarea rows="80" cols="20"
>          tal:attributes="rows request/rows;cols request/cols">

The problem here is not exactly of having multiple parameters for one 
directive, but more multiple directives with the same name, which 
clashes with the fact that XML require distinct attribute names.

In our annotated-HTML-to-XSL compiler, we avoid this problem by using 
the following notation for attributes:

<textarea rows="80" cols="20" tal:attribute-rows="request/rows" 

The "tal:attribute-*" instruction allows any attribute name to be 
specified, while still imposing uniqueness of the names of dynamically 
evaluated attributes.


>> <tr t:forEach="cart/item">
>> or
>> <tr t:forEach="item in cart/item">
>> for iterators. 
> Here is the questions are if we want to work on a implicitly defined 
> context as in XSLT or if we want to define a loop variable and also if 
> we should use synatctic constructs that are close to natural language 
> like "item in cart/item". I prefer the implictely defined context and 
> would also prefer avoiding complicated syntactic conctructs if possible.

JXTemplate provides both approaches, depending if JXPath or Jexl is used 
[1]. But this is semantically similar to a java.util.Iterator() while 
the "varStatus" variant provides the feature of an indexed loop (i.e. 
"for (int i = 0; i < list.size(); i++)").

This varStatus variant is much more complicated but is sometimes 
invaluable to know where you are in the iteration process.

Note than rather to use an approach or the other depending on the EL 
language used or the attribute, we could use different constructs.

Modify the context object:
  <tr t:foreach="cart/item">

Define an iterator:
  <tr t:loop="item in cart/item">

Define an indexed loop:
  <tr t:indexed-loop="status in cart/item">

(hearing Stefano coming behind me, ready to shout "FS!!!" in my ears...)


> Now, this is IMO, the main question: what level of complexty do we 
> need to handle in Cocoon Templates?
> Visual Design and Programming SoC
> ==========================
> First the reason for caring about ATLs at all is that we want let a 
> designer create examples of the pages in our webapp in Dreamweaver 
> etc. The programmers can give the pages "life" by adding attribute 
> directives. And after that the designers can continue to improve the 
> design in their WYSIWYG tools without affecting or risking the 
> template aspect of the page.
> The template covers two aspects, a visual design aspect and a data 
> injection and controll structure aspect. The first handled by a 
> designer and the second by a programmer. Of course the designer can 
> learn some of the simpler directives by e.g. pattern matching and 
> copying. Or maybe more complicated constructs if he/she happen to have 
> interest and talent in that direction.
> But we should remember that geting data from an object model with an 
> EL and selecting, repeating or recursively applying parts of the 
> template, based on the data structure from the flowscript, _requires_ 
> programming skill. Believing something else is IMO wishfull thinking.

Yep. Adding ATL attributes on the HTML page is a developer's work.

> So, the ATL will make the designers life easier as they can use their 
> favorite WYSIWYG tool. Will it make the programmer life easier? Yes, 
> in the sense that they don't need to be that much involved in changes 
> in the visual design anymore. And No, in the sense that using 
> attribute directives is more complicated than using a tag based TL as 
> JXTG. Now about everything will need to be done within an existing and 
> more or less locked HTML (or other) tag structure.
> Needing to solve the same problem as you solved with JXTG but imposing 
> an extra constraint (the template must be able to show in Dreamweaver 
> all the time) cannot reasonably simplify the problem can it?

Well, you presented some extreme cases. It's unlikely that a single tag 
will hold more that, say, two control structures (e.g. loop and if), 
which keeps the attributes quite readable.

> Combining Directives
> ====================
> If you take a look at your current set of JXTG, Velocity, XSLT etc, 
> you sometimes need to nest several tags from you TL, if, forEach, set 
> etc. If you want to solve the same problem with an ATL, you either has 
> to insert dummy tags that in some way or another doesn't going to 
> effect the WYSIWYG or more realistically put several attribute 
> directives in the same tag. Actually you may end up needing more 
> attribute directives than tag directives, as you might need to remove 
> the surrounding tag etc.
> But wasn't the ATL supposed to lead to much simpler templates than 
> with my current tag based TL? There seem to be a common belief that 
> this should be the case. But I just fail to understand why changing 
> syntax and adding the WYSIWYG constraint should simplifying anything. 
> Except for simplfying SoC between roles in an organization, which is 
> enough as a motivation IMO.
> Ok, so until I am proved wrong I believe that the ability to combine 
> directives is a must, if we want to use the ATL for anything more 
> serious than some cool looking example snippets.
> So, as I wrote in my original post you can either combine directives 
> by having several attributes for the attribute name approach or you 
> can have a sequence of directives as attribute content. Atributes are 
> a set rather than a sequence so you don't have a well defined order 
> and to use the same directive name twice is not allowed.
> You have to impose a predefined order on the directives for the 
> attribute name approach. This is ok if we can restrict the ATL to just 
> contain a handfull directives (say 5). If we have more than so it will 
> be hard to come upp with and remember a "natural" order of the 
> directives. And remember that the order they happen to be written in 
> the template doesn't influence the order they are executed in. If you 
> doubt, think about the precedence order of operators in Java (no not 
> you Vadim, I talk with people with more average attention to detail ;) 
> ). The order between '*' and '+' is obvious, but what about '|' and '^'?
> I proposed 10 directives, Vadim sugested removing one and adding one 
> and Leszek adding two. Remembering predefined order of 10+ directives 
> just seem to complicated to me and maybe they have problems with that 
> in TAL: 
> So to sum up, I believe that attribute name based syntax will create 
> more confusion than it is worth. And I'm affraid that the belief that 
> our templates, in some magical way should lose all complexity just by 
> changing their syntax, might be unjustified.

Well finding a consensus between diverging requirements is always 
difficult, and the opinion of each person regarding one or the other 
solution is always related to its own skills, experience and work 
context. People with strong dreamweaver roundtrip requirements will use 
the attribute syntax even if it sometimes looks awkward, whereas people 
more XML-centric will prefer clear structures that show up in the 
outline view of an XML editor.

We know that one size fits all doesn't exist.

Now going back to the annotated-HTML-to-XSL compiler that we (Anyware) 
wrote many years ago, it allows to mix both syntax, as attributes are 
simply translated to their XSLT equivalent, and you therefore can write 
plain XSLT in the HTML file (aargh! I hear Stefano coming!).

A similar approach could be used for the template language with a single 
engine, by simply converting on the fly directives-as-attributes to 



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message