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 , but there's no equivalent to . To me, pattern-matching is the thing I need most. I'd like something like: 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, instead of , "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:reinhard_poetz@yahoo.de] > Sent: Tuesday, 2 November 2004 5:30 a.m. > To: dev@cocoon.apache.org > 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 >