cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Attribute Driven Templates
Date Sat, 04 Dec 2004 22:42:13 GMT
Roy G. Biv wrote:
> Daniel Fagerstrom wrote:
> I as well.  In addition, I think that the optimum template language 
> would be as close to the appearance of the output document as possible.  
> (Yet another reason I don't personally care for explicit forEach, if and 
> chose elements; they make it harder to see at a glance how it will look 
> after processing.)

Tend to agree, I use XSLT (2.0) for all kind of things, and am happy 
whith many aspects of it, but sometimes it is a little bit of "write 
only", i.e. it easy to expres things in it (once you get used), but it's 
verbosity can hide the message, when you try to understand your or 
others code.

> I'm a big fan of namespacing the attribute for reasons of versioning as 
> well as clearly marking which directives belong to which processor -- 
> both for the processor and for the template author.

Agree, no idea why Tapestry don't use name space for marking directives.

>> A problem with "attribute name as directive" is that xml attributes 
>> are unordered. So in the case you need e.g. a double loop over an 
>> element, test if you want to perform a loop or do a loop and test each 
>> element, a mechanism for deciding the order is needed. TAL uses a 
>> predetermined order for the directives. That is far to implicit for my 
>> taste and it doesn't solve the double loop. I would prefer to do 
>> something more explicit like:
>> <p tal:define-1="x /a/long/path/from/the/root"
>>    tal:condition-2="x"
>>    tal:content-3="x/txt"
>>    tal:attributes-4="class x/class">Ex Text</p>
> Sounds good on paper, sounds like a royal PITA in practice.  Determining 
> whether attribute  A should be set before the first condition but after 
> the second condition which determines the content...  Complexity can 
> rise dramatically and quickly with this.  I'd say the template should 
> lose the ability to do a small set of corner cases if, 95% of the time, 
> the simpler syntax has noticeably lower complexity.

Might be, I have not used TAL. When I read about the default ordering I 
thought that in most cases I will only use one directive, so in the 
cases where I use several I will need to check the manual anyway. As I 
want to avoid "to much magic" being explicit seemed better. But maybe 
the default order is so natural so that you learn it at once?

> I think the desire for this comes from the desire to make HTML-oriented 
> templates from the template directives.  Is this correct and is this the 
> correct focus? 

Stefano's focus seem to be on HTML. My focus is lost long time ago ;) 
Designing a attribute driven template language seemed like a fun thing 
to do.

Is it the correct focus? If we find an efficient and easy to understand 
way of writing HTML templates, it will work well for numerous other XML 
formats that have similar structure, so it should be important enough. I 
don't know if the concept of "correct focus" is that relevant in open 
source development. Things will be done by people who have a itch to 
scratch, if it seem fun and interesting enough, if it gets enough 
attention, if influencial people says that it is important and by 
numerous other reasons.

> If the template language is focused on producing 
> semantic XML -- where the XML reflects the structure of the problem at 
> hand and not its presentational form -- simpler syntaxes are much more 
> useful.  As is the case with Plone, the focus on HTML output mandates 
> more complex processing options than is otherwise necessary.

I think that having complicated processing options only is a problem if 
they make simple things complicated. As long as you can resist spending 
to much time talking about complicated corner cases when you teach the 
technology, it will work well even for those who are less comfortable 
with complicated constructs.

> If HTML output is a primary design concern and HTML templates are made 
> so much easier/possible, will anyone on a deadline keep SoC firmly in 
> their heads?

Do they now?

IMO HTML already gives you god SoC in many cases. As long as you write 
for modern browsers, HTML is an excelent language for describing content 
in a rather wide area. Then you put all styling in CSS.

In more complex use cases or when you have regularity along dimensions 
that not is covered by the HTML-template/CSS solution, a solution with 
more layers might be better. But it all depends on the task, excecive 
layering for simple tasks is IMO an anti pattern.

> Once this happens, what advantage does Cocoon have over 
> JSP w/ taglibs?  I'm honestly curious.

Cocoon had the advantage that you can put all your side effects in the 
flow layer, and let the pipeline be completely declarative. Which 
reduces complexity and make things easier to test and understand. You 
can in a simple way choose how in how many step you will handle your 
output based on the SoC you find best for the problem at hand. Also you 
will get standard components for everything that people find important 
enough to invest time in it.

> If HTML-oriented templates are 
> the norm, and the pipelines would consist of the successor to JXTG and 
> an HTML serializer, what's the point?  I don't mean to invoke a 
> slippery-slope fallacy as I think this is a real possibility.

I just can't see this as a problem, If people can solve simple things in 
a simple way, isn't that much better.

In my webapps I use short pipelines for some stuff and long for other, 
it all depends on what problem decomposition I found reasonable and 

I doubt that the people who constructed pipelines in UNIX consider it a 
failure that UNIX have so many well designed commands for simple tasks, 
that most of the time the commands are executed without being in a pipeline.

> When the XML and the logical data structure are intimately related, 
> things tend to fall into place with a minimum of decision making.  Then 
> transform.  Then serialize.

In many cases yes, in many other cases no ;)


> So much for avoiding the complexity of a general programming language.  
> Simpler may leave fewer options, but that's not always a bad thing.  If 
> all options need to be handled, you're looking back at XSP, the ultimate 
> in this area.

It doesn't have side effects and it have quite limited access to data in 
Cocoon, thats important differences.

>> Several directives
>> ------------------
>> So, how do we handle multiple directives for one element? We could 
>> handle the TAL example above like:
>> <p 
>> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">

>>   Ex Text
>> </p>
> Yeah, that's what I thought.  I pity the template writer that much 
> content with someone else's templates.

No one forces you to use it, it will not hurt you as long as you don't 
use it, as the syntax is simple for simple cases. The example was taken 
from the TAL manual for illustrating a mechanism, not for being a 
realistic example.

> I still think macros should be handled in transformations rather than 
> Java code, but there it is.

Macros are written in the template language it self, no need for Java or 
a foreign transformation language. Basic directives like if are written 
in Java.


View raw message