Better templates in Cocoon?

There have been lots of discussions about templating systems in Cocoon lately.

It started with the need to refactor the JXTemplateGenerator (which works well, thanks, but the code could be better structured for maintainability), and quickly branched out to “how about a new and improved templating system”.

You often learn a lot in such collective discussions with the brilliant people who are around cocoon-dev. Me, I’ve learned/realized three important things:

  1. Attribute-based template languages (like Zope’s TAL, thanks Chregu for the link), are much more tool-friendly (read Dreamweaver-friendly) than tag-based syntaxes, like our current JXTG.

    The main reason is that attributes quickly become “invisible” to the page designer, yet they move with the elements when cut and pasted or duplicated. And there are several such syntaxes around, so designers are getting used to working with them.

  • Having one syntax for templating, that can be used either for the Cocoon Generator or Transformer stages, would bring big benefits.

    See my Alice and Bob story for details, there has been some argument but mostly agreement, assuming it’s doable. I think it is.
  • It seems very possible today to replace XSLT (for simple cases) with a much simpler transformation language (a la TAL) in Cocoon, and this would bring huge benefits as XSLT is the stumbling block today for many people starting with Cocoon. It’s not a problem for larger projects where you have the budget to learn or hire experts, but I’m sure it is a blocking factor for many smaller projects.

    XSLT won’t go away for sure, its power is really useful when you need it, but for simple things it is simply too costly to learn. We need something better, there are some alternatives in Cocoon today but none is really satisfactory.
  • There’s some additional information, summaries and mailing list references on the Cocoon wiki.

    We live in exciting times – an experimental “template” block was added recently to the Cocoon trunk, and several people seem to be available to work on this, so it might become a reality rather sooner than later. Stay tuned.

    2 Responses to Better templates in Cocoon?

    1. Brian Ewins says:

      Bertrand – I don’t use cocoon, but I was intrigued by the discussions. Tag and attribute template markup were discussed, so I presumed the use-case was xml, but then so were velocity syntax and there was a lot of noise about being DW friendly. Has using DW’s own (comment-based) template syntax come up?
      We wrote our own template system based on that a couple of years back (using struts-tiles-a-like JSP tags to replace content of editable regions, library items, and URLs), to stop copy & paste of html assets to jsp and back, while not retraining the DW users. DW4 didn’t have an EL, but MX templates – soon to be also in Nvu – are more of a transformation language; if you export a template as XML the processing pipeline is pretty obvious.

    2. > …I presumed the use-case was xml, but then
      > so were velocity syntax and there was a lot
      > of noise about being DW friendly….

      You’re right that the recent discussions cover both “XML templating” and “HTML templating”, I’d be very happy if we can find a way of doing both with the same tool.

      > Has using DW’s own (comment-based) template
      > syntax come up?

      No – as I see it the goal is not to interpret DW templates, only to be able to use DW to edit our templates. I doubt a comment-based syntax would be welcome.

      The big advantage of using namespaced elements or attributes is that the corresponding elements or attributes are first-class citizens in the XML processing tree, whereas using comments as processing/template instructions bends the spec a bit.

    %d bloggers like this: