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='org.apache.cocoon.foo.Bar']">
<html:h1><value-of select="baz"/></html:h1>
etc.
</template>
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 so.
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!
Con
> -----Original Message-----
> From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 2 November 2004 5:30 a.m.
> To: [EMAIL PROTECTED]
> 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
>
