Taglib Block, and Re: Planning Cocoon's future

[Vadim Gritsenko <va...@reverycodes.com>]

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

Re: Taglib Block, and Re: Planning Cocoon's future

[Stefano Mazzocchi <st...@apache.org>]

Bertrand Delacretaz wrote:
> Le 23 nov. 04, à 14:54, Vadim Gritsenko a écrit :
> 
>> ...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...
> 
> 
> I'm +1 on your -1 ;-)
> 
> XSP is used in a lot of existing apps, it works and it doesn't seem to 
> be a heavy burden to carry.
> I don't think there's a real urgency to deprecate XSP, except the desire 
> to move forward of course. But not developing it any further is clear 
> signal already.

I'm working on a reporting web application for gump based on cocoon and 
I tried *hard* not to use XSP but I couldn't since ESQL is the 
best/most-efficient tool for the job when reporting is concerned.

We already made it a block, I don't think we need to deprecate it until 
we have something that is equivalently powerful and yet solves the 
issues with it (being too powerful ;-)

-- 
Stefano.

Re: Taglib Block, and Re: Planning Cocoon's future

[Bertrand Delacretaz <bd...@apache.org>]

Le 23 nov. 04, à 14:54, Vadim Gritsenko a écrit :
> ...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...

I'm +1 on your -1 ;-)

XSP is used in a lot of existing apps, it works and it doesn't seem to 
be a heavy burden to carry.
I don't think there's a real urgency to deprecate XSP, except the 
desire to move forward of course. But not developing it any further is 
clear signal already.

-Bertrand

Re: Taglib Block, and Re: Planning Cocoon's future

[Daniel Fagerstrom <da...@nada.kth.se>]

Vadim Gritsenko wrote:

> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote: 
>
<snip what="Info about taglib"/>

> 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

Ok, thanks for the info. From what you say it seem better to let the 
taglib focus on its close connection to JSP taglib. After having studied 
the code in more detail I don't think it would be worthwhile to refactor 
it to handle the pre-compilation step needed for JXTG.

/Daniel

Re: Taglib Block, and Re: Planning Cocoon's future

[Torsten Curdt <tc...@apache.org>]

>> 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.
> 
> 
> I feel the same way.
> 
> No deprecation before we have general concensus on the suggested 
> template language to use.

...I would also like to see the a comparable functionality
of some logicsheets first. For me this e.g. means merging
ESQL and the SQLTransformer.

I think the signals are already set ...but -1 on the deprecation

cheers
--
Torsten

Re: Taglib Block, and Re: Planning Cocoon's future

[Stefano Mazzocchi <st...@apache.org>]

Vadim Gritsenko wrote:
> 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.

I feel the same way.

No deprecation before we have general concensus on the suggested 
template language to use.

-- 
Stefano.