cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Attribute Driven Templates
Date Tue, 07 Dec 2004 16:40:10 GMT
Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:

<snip what="thing discussed in another mail"/>

> Here, I just want to comment that I find way more intuitive and user 
> friendly following constructs:
>
>> if(<test>)
>> ----------
>>
>> example:
>>
>> <div do="if(count(cart/item) == 0)">
>
>
> <div t:if="cart/item">
> and
> <div t:unless="cart/item">
> for conditions. 

My example should have been:

<div do="if(cart/item)">

and I'm ok with

<div do="unless(cart/item)">

if people want it.

Concerning attribute name v.s. attribute content based syntax I agree 
with you and others that the former is slightly easier to get used to 
for simple examples. When studying TAL and Tapestry I found TAL examples 
(that is based on attributes) easier to understand than the, IMO, rather 
cryptic Tabestry syntax (based on attribute content). Tapestry make 
things even worse by using "jwcid" as attribute name instead of e.g. 
"do" or "tl:do".

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">

While thinking about how to use a syntax like that for defining a macro 
that both need a name and anumber of parameters, my entusiasm for the 
approach started to decrease. We also have the question about how solve 
the problem with having more than one. But before discussing that I'll 
comment some more constructions.

>>   Your cart is empty
>> <div>
>>
>> forEach(<sequence>)
>> -------------------
>>
>> example:
>>
>> <table>
>>   <tr do="forEach(cart/item)">
>
>
> <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.

>>     <td>${index}</td>
>>     <td>${description}</td>
>>     <td>${price}</td>
>>   </tr>
>> </table>
>>
>> for(var=<name>,begin=<expr>,end=<expr>,step=<expr>)
>> ---------------------------------------------------
>
> Is it necessary? Current jxtg does not have it (IIRC). 

I don't think it is necessary. I included it as jxtg has it.

>> context=<expr>
>> --------------
>>
>> Set the current evaluation context for expressions.
>>
>> example:
>>
>> <table do="context=/shopping/cart">
>
>
> <table t:for="/shopping/cart">
> or t:context, or some such.
>
> ... and the rest is similar. I also feel that expressions like 
> "if();context();let();for();etc;etc;etc" are too complicated for what 
> is necessary in Cocoon Templates. 

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.

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?

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: 
http://zope.org/Wikis/DevSite/Projects/ZPT/RemoveInsaneConstructs.

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.

/Daniel



Mime
View raw message