Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
After releasing Cocoon 2.1.6 it's time to plan our future. A few month ago we
updated our roadmap in SVN. According to this we agreed that 2.2 is a
consolidated version of 2.1.
So what are the changes and what's their current status? --------------------------------------------------------
<snip/>
- deprecate XSP to be done (needs an alternative)
ATM, I'm -1 on deprecating XSP. There is just not enough information yet to make such a decision - we have some wishes but nothing concrete yet.
<snip/>
For the taglib I have not been able to find any documentation of how it works and the design behind it (any pointers?), and have not found time to read the code. Vadim used it in the faces block so it is probably reasonably good. Vadim, can you (and other users of taglib), tell about your experience from using it?
Taglib block is an attempt to mimick JSP taglib classes, with account of differences such as System.out vs SAX XMLConsumer. It provides interfaces:
* Tag * BodyTag * IterationTag
And base classes:
* TagSupport
It also provides some Cocoon specific interfaces / classes such as:
* TransformerTag, TransformerTagSupport * XMLConsumerTag, XMLConsumerTagSupport * XMLProducerTag, XMLProducerTagSupport
It also has expression language built-in which is based on jxpath, and that's where I'm disagreeing with initial author. I'm thinking it should be more in-line with JSP spec and simpy use JSP expression language as-is. This would allow full JSTL taglib implementation in Cocoon, so that you can use 3rd party JSP editors to create JSP pages and then simply run them in Cocoon (almost) unmodified as long as JSP page is well-formed XML.
Additionally, JSP EL can be extended with Cocoon OM objects and easy access to variables passed from the flow. JXPath also could be plugged in, but only as an alternative, instead of main implementation (which is currently a bit broken anyway).
About faces block; usage of taglib block there provided for an easy "migration path" of JSP JSF taglibs into Cocoon Faces taglibs, and final result is such that I can use very similar JSP JSF pages and Cocoon Faces pages - the only difference is addition of namespace declarations and removal of JSP taglib instructions. Both use same expression language, so your 3rd party JSF editor can resolve and validate expressions (and may be even code completion).
IMHO, if the taglib is good enough, the best approach for JXTG 2.0 would be to refactor the JXTG tags to taglib tags, factor out the object model and make the expression language plugable.
The problem I'm seeing with this is that JXTG should be implemented as *generator*, with template pre-parsing, pre-processing, template caching, and other features, whereas Taglib is *transformer* and can not provide these options.
Currently I'm seeing taglib as a step-up stone from JSP into the world of Cocoon - once JSP EL and JSTL support is added to it, that is.
PS Folks who currenly stuck with JSP are welcome to volunteer
Vadim
