cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinhard_po...@yahoo.de>
Subject Templating Engine - Next steps?
Date Mon, 01 Nov 2004 16:30:19 GMT
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

Mime
View raw message