cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conal Tuohy" <>
Subject RE: Templating Engine - Next steps?
Date Mon, 01 Nov 2004 23:08:57 GMT
Coincidentally I'm just starting work on a templater too. I have been using JXTemplate and
I really like it, but a few things have frustrated me about it, too. 

Perhaps it's unusual, but I really like it BECAUSE it's like XSLT, and I don't mind at all
that it's not like Java. The things I don't like about it are mostly things where it differs
from XSLT:

In order of priority:

1) JXTemplate has jx:macro elements, which are like <xsl:template name="foo">, but there's
no equivalent to <xsl:template match="foo" mode="bar">. 

To me, pattern-matching is the thing I need most. I'd like something like:

<template match="[class/name='']">
	<html:h1><value-of select="baz"/></html:h1>

2) It has 2 expression languages! So you need to say "#{foo}" instead of "foo".

I think it should have 1 language, but it could be pluggable. My preferred language is JXPath
rather than Jexl, partly because of the specific needs I have in mind (navigating TMAPI object
graphs), for which JXPath is ideal. I also think that Jexl is too close to Java and hence
a bit over-powered. You can call arbitrary Java methods in JXPath too, but it uses an extension
function. I don't know if there are things that Jexl can do that JXPath can't? I don't think

3) Logically it is very similar to XSLT, but it has a different syntax for everything; forEach
instead of for-each, <var set="foo" value="bar"/> instead of <variable name="foo"
select="bar"/>, "macro" instead of "template", etc. 

I think the syntax should be same as XSLT much as possible, to aid in learning, and to help
avoid typographical errors.

3) jx:macro elements don't seem to have access to global variables (strange scoping rules)

4) no jx:attribute

That's my list! 


> -----Original Message-----
> From: Reinhard Poetz []
> Sent: Tuesday, 2 November 2004 5:30 a.m.
> To:
> Subject: Templating Engine - Next steps?
> After a lot of mails talking about expression languages and 
> templating enginges 
> I try to summarize the current state of our discussion.  I 
> see following 
> requirements so far (in brackets you find the name of the 
> person that brought up 
> the requirement):
>   - control structures like for/each, if, choose (RP)
>   - call methods in a _simple/natural_ way on passed objects (RP)
>   - stream objects (DOM, XMLizable, ...?) (RP)
>   - define macros/taglibs (see cForm macros) (RP)
>   - works as a Transformer (SAX pipeline) (GP)
>   - Ability to directly produce SAX events, for efficency 
> reasons. (SW)
>   - one default expression language (CZ)
>     it thing most people prefer the "dotted" JEXL syntax
>   - support for additional expression languages (SW)
>   - use the TemplateObjectModelHelper as Cocoon wide object model (CZ)
> and not to forget
>   - cacheability (RP)
>     (BTW, has caching been implemented to everybodies satisfaction or
>     are there open issues or possible improvements? Leszek?)
> and one issue that bugs me for a long time ...
>   - add support for dynamic attributes - similar to xsl:attribute (RP)
>                                    - o -
> So, how do we continue to meet all these requirements?
>   A.) Rewrite/refactor JXTemplate
>       - break it up in smaller, easier 
> understandable/maintainable pieces
>       - deprecate #{} syntax and make expression languages plugable as
>         Sylvain suggested
>       - investigate the performance problems (I guess there are only
>         problems if macros are used)
>       - add the missing things from above
>   B.) use Garbage
>   C.) talk with Carsten about Tempo
>   D.) completly new templating engine
>                                    - o -
> In my opinion we should write JXTemplate 2.0 which would be 
> from the user's POV 
> as similar as possible to 1.0.
> Technically this could be a complete rewrite (use garbage, 
> tempo or really from 
> scratch) or at least a major refactoring.
> Calling it JXTemplate is better for marketing reasons because 
> it shows more 
> stability than telling our user base that they should use 
> something completly 
> different in the future. Calling it differently gives another 
> impression than 
> incrementing version numbers.
> WDOT ...
>   * are there any missing requirments?
>   * or is it too much (FS)?
>   * which alternative do you prefer?
> Don't forget, this is no vote ;-)
> -- 
> Reinhard

View raw message