cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy G. Biv" <mi...@pcextremist.com>
Subject Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call them taglibs)
Date Sat, 04 Dec 2004 19:17:53 GMT
Daniel Fagerstrom wrote:

> Stefano Mazzocchi wrote:
>
>> All I ask from a template language:
>>
>>  1) something that HTML designers can edit with Dreamweaver
>>  2) something that doesn't use namespaced tags to identify dynamic 
>> scopes (clashes with #1)
>>  3) something that doesn't use the name taglib
>>
>> That's pretty much all you have to do to make me happy.
>
>
> Dreamweaver friendly means basically that it should be attribute 
> driven I guess?

Any prohibition on (non-HTML) namespaced tags would imply to me that 
arbitrary namespaced attributes would be a no-no in Dreamweaver as 
well.  Stefano, as I haven't ever used Dreamweaver for more than ten 
minutes, is this limitation a rendering issue or data entry issue?  I 
question the position though.  Taking two obvious possibilites:

1. Velocity syntax: just plugs in in the best-case scenario as text but 
suffers from the danger of having the text "#foreach" wrapped in a tag 
by the editor.  Well-formedness is not guaranteed.  (I think.  Correct 
em if I'm wrong.)

2. Namespaced tag or attribute: may not be compatible with Dreamweaver 
(strikes me as a serious limitation that needs to be addressed by the 
Dreamweaver developers IMHO), but can guarantee well-formedness.

I don't think any solution will be perfect.  The best we can hope for is 
straightforward workarounds.

> I'll give some background info and then I'll show how an attribute 
> driven template language for Cocoon could look. The discussion is 
> based on TAL http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL, 
> Tapestry http://jakarta.apache.org/tapestry/ and some of the 
> functionallity in JXTG.

Lucky me, I just made my first site with Plone a couple of months ago.

> We need two kinds of constructions: expressions and directives.
>
> Expressions
> ===========
>
> Expressions are the "${expr}" stuff in e.g. JXTG and should be use 
> able both in text in attributes and element content. Do we need the 
> "$"? Couldn't we just use "{expr}" as in XSLT?

I'm glad someone else said this.  I totally agree.  If I understand 
correctly, the reason behind the '$' character was to differentiate 
JXPath and JEXL expressions.  Since the current thought is that we'll 
standardize the lookup syntax, why the extra character.  It can be said 
that people are used to JXTG, but far more people are used to XSLT-style 
attribute value substitution.

Also bear in mind that JXTemplateGenerator is already written and code 
complete.  Any new syntactic sugar would presumably be in a different 
sitemap component (even if it were abusively named 
org.apache.cocoon.transformation.JXTemplateGeneratorV2).  Everyone used 
to the old syntax just uses the old JXTG implementation in their sitemap 
declarations (I love Cocoon's design for this by the way).

> IIUC TAL doen't use embeded expressions but instead replace element 
> and attribute content with replace directives (in attributes). It 
> might make it even more Dreamweaver friendly as you can look at 
> example content instead of expressions in your design window. But it 
> makes template writing much harder IMO. We could have such replacement 
> directives if people want it but, I would prefer having embeded 
> expresions as well.

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.)

> Directives
> ==========
>
> TAL uses one name spaced attribute for each directive, e.g.:
>
> <p tal:condition="here/copyright"
>    tal:content="here/copyright">(c) 2000</p>

Other than the fact that I would have rathered the attribute were 
tal:test instead of tal:condition for brevity's sake, this syntax had 
proven to be extremely powerful and easy to understand in my experience.

> Tapestry instead uses only one attribute, "jwcid", with the directive 
> name as content.
>
> <tr jwcid="loop">
>   <td><span jwcid="insertFirstName">John</span></td>
>   <td><span jwcid="insertLastName">Doe</span></td>
> </tr>

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

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

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?  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.

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?  Once this happens, what advantage does Cocoon have over 
JSP w/ taglibs?  I'm honestly curious.  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.

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.

> NIH
> ===
>
> First some motivation about why I don't think that TAL or Tapestry 
> templates are good alternatives for using as is in Cocoon (besides 
> that its much more fun to implement them ourselves ;) ). AFAIU both 
> TAL and Tapestries directives are very closely connected to the both 
> frameworks respective component models. We need something that works 
> with our world view. Furthermore TAL is develped by the Zope community 
> so everything is in Phyton style, and at that feels less natural, at 
> least for me.

Yes, the TAL processor doesn't even enforce well-formedness.  It's a 
pattern matching replacement syntax that would require some reworking of 
assumptions in order to work with Cocoon.  It also takes away the 
ability to easily drop a ${value} directive in your attributes and 
content areas, thereby increasing the directive-to-normal markup ratio 
which I care about so much.

> A Proposal
> ==========
>
> Based on the previous I propse that the attribute driven template 
> language should be invoked like:
>
> <element do="<directive>" attr1="...">
>   <content>...</content>
> </element>
>
> The idea is that the attribute "do" triger the execution of the 
> directive. "do" is just an example we could make the trigger attribute 
> configurable and/or namespaced so that it doesn't colide with your 
> "host" XML language.

Interesting, but it worries me.  It helps with the attribute ordering 
issue, but starts to feel a little too much like a formal programming 
language to me.  Today, the syntax handles conditionals, data 
replacement, etc.  As time goes on, the desire to add new directives (or 
God forbid, arbitrary pluggable processing directives) will come.  
Namespace URI versioning would be very important here.  I'm more 
inclined to simply back up and say, "Conditionals get processed first, 
then looping, then content replacement," and be done with it.  As I said 
before, I think more flexible "do" constructs just lend themselves to 
easier handling of complex HTML output-oriented templates.  Once again, 
I'm uneasy with this is direction.

> example:
>
> <div do="if(count(cart/item) == 0)">
>   Your cart is empty
> <div>

<snip what="forEach, for, context, let, macro, eval, content, replace"/>

And would these be chained?

  <table>
    <tr do="if(count(cart/item) == 0); forEach(cart/item)">
      <td>${index}</td>
      <td>${description}</td>
      <td>${price}</td>
    </tr>
  </table>

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.

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

> Connection to JXTG
> ------------------
>
> The directives are almoust defined in such a way that they could be 
> translated to a tag based templating language like:
>
> directive(param_1=value_1,...,param_n=value_n)
>
> <=>
>
> <jx:directive param_1="value_1" ... param_n="value_n"/>
>
> Maybe we could find a attribute directive language that allows for 
> complete correspondance. And make tag or directive syntax selectible 
> and in such way make this effort compatble with JXTG?

We're talking about a radically different syntax.  Shouldn't we refer to 
it with another name even if that name is temporary and trite?  From 
where these discussions are headed, JXTG is frozen in time.  If the 
syntax is changed radically, backward compatibility is out the window.

JX2?
JX-ng?
CTemplates
XTemplates
FlowTemplates
Eugene
Whatever

That or there are substantial redundancies in the code.  A Perl-like 
"there are at least two ways of doing everything."  If that's what 
people here want, so be it.  Not worth starting a fight over.

> Externaly defined directives?
> -----------------------------
>
> If we chose to allow extenally defined directives they probably should 
> be given own namespaces to avoid clashes.

Absolutely agree!  Different problem scopes warrant different identifiers.

> Formating?
> ----------
>
> IMO most of the basic formating can be done in a special conversion 
> layer as we have discussed in the convertor thread.

Agreed.

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

- Miles Elam


Mime
View raw message