cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [RFC] "Cocoon Templates": Name and Tag Interface
Date Mon, 29 Nov 2004 13:13:28 GMT
As you probably have noticed, we are working on a replacement on JXTG.

The goal is that it, as far as it is desirable, should be back 
compatible with JXTG. But instead of being implemented as a huge (and 
somewhat scary) monolith, it will be implemented as a taglib framework. 
By implementing it that way it will be much more open for further 
development and the goal is to implement taglibs similar to ESQL etc so 
that it can work as an XSP replacement as well. It should be at least as 
performant as JXTG.

Jonas has submitted an initial implementation based on the design 
discussions on the list, that Leszek is going to commit.


We need your input on chosing a name for the framework. And also on what 
data that should be available for the taglibs and in what way the tags 
should be given access to this data. The design of the tag "interface" 
will be an important question for you when you are going to implement 
tags in the future. And it would also be good if we could agree about 
the main direction of the tag design quite soon, so that we can start 
the development of taglibs in parallel with the framework development. 
Please spend some brain cycles on this.


The goal is that the new template framework should replace JXTG and XSP 
as the "recomended" template system for Cocoon users. It is a community 
effort rather than a one man show. It is based on our previous experince 
of templating solutions.

This should IMO be reflected in the naming. The name should reflect the 
intended purpose rather than being a "brand" name. "JX" in 
JXTemplateGenerator comes from JXPath and as we are going to provide 
support for other expression languages as well, JXTG 2.0 would not be a 
logical name for the framework IMHO.
I would propose that we (analogous with CForms) refer to it as 
"template" in block name, package name, name spaces and so on. When it 
actually delivers what is promised, we can refer to it as Cocoon 
Template or CTemplate.

To show that we care about our users previous investments in Cocoon 
technology, we can say that JXTG has been re-implemented as a Cocoon 
Template tag lib.

Of course other and better naming sugestions are most welcome.

Tag "Interface"

What data should be available for the taglib writer and how should it be 
made accessible? What about thread safety?


This is somewhat OT in the current context but IMO expressions, (the 
stuff inside ${}), should only have access to FOM and preferably just 
read access. IMHO expressions should not have side effects.

What Data in Tags?

A tag need access to:

* The current XMLConsumer for output
* The content of its attributes
* The content of its body (the possibility of executing the body and 
geting the result)

The following data is also useful for some tag libs:

* A variable stack for handling local variables in tags or macros
* The tag repository
* The source resolver
* The component manager (e.g. for geting a DB connection)
* Its parent tag
* The content of its body (the possiblity to get the body unevaluated)

IMHO tags should behave as if they are side effect free. Side efects 
should be performed in flowscripts. From this we can infer that we only 
should have read access to the above data. But in practice it might be 
hard to enforce and furthermore even if the tag behave as it is side 
effect free, it might be better (or the only possiblity) to implement it 
in terms of side effects.

Implementation details are discussed in the section "Adding Executable 
Tags" in

Have I forgotten something or should we remove something?

How to Make Data Accessible in Tags

There are two main type of events in the life cycle of a tag: setup and 
execution. For a thread safe tag, the setup phase can be divided in: 
script compile time setup and execution time setup.

The relation between the tag and the framework has many parallels with 
the relation between a component and a component manager, so similar 
solutions are possible.

We can have reflection based solution with setter injection of 
attributes and possibly the rest of data also. We can have interface 
driven injection, (Avalon framework style), where the tag implements 
various interfaces for geting the various input data types.

We can also have more "static" solutions where the tag has to implement 
a certain interface and get all the data with methods in the interface 
or in one large context object.

Reflection based methods are more flexible, but should probably only be 
performed during script compile time setup, due to keep good performance.

See the above reference for examples and more details.

Thread Safe or Not?

Thread safe tags can have better performance as more work can be done 
during script compile time, but they might be harder to write. What 
should we chose or should we support both types?


Thanks for your attention :)

And as said above, input on the above questions is really appreciated 
and also needed to make this a community effort and achive the goal of 
geting a "recomended" Cocoon template solution.


View raw message