cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Taglib Block, and Re: Planning Cocoon's future
Date Tue, 23 Nov 2004 13:54:57 GMT
Reinhard Poetz wrote:
> 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

Mime
View raw message