You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/11/23 11:53:25 UTC
Planning Cocoon's future
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?
--------------------------------------------------------
(based on xdocs/plan/roadmap.xml)
- stable Cocoon Forms
the status is summarizes by Sylvain[1]
- move service manager into our code repository
done my Carsten
- Virtual Sitemap Components
Vadim started with the implementation
- inheritable views
don't know the status (I think Carsten is/was working on it)
- move to Subversion
done
- migrate to official rhino_1.6
done
- deprecate XSP
to be done (needs an alternative)
Daniel, are you working on a JXTG 2.0?
- Cleaning up the caching/store mess
don't know, does it work now as it should?
- separate blocks from Core
that's my job: I'm working on a block-builder and a block-deployer
that will make this separation possible and will give us the chance
of a smooth transition from our current monolytic system to a decentral
blocks orientated system:
* every block get's a descriptor containing all meta information like
author, license, status, block references and library references
--> should as close as possible to the needs of RealBlocks
* enhance jars.xml to become a repository (only needs an id attribute
for all entries so they can be references and looked up)
* setup the new block centric build system parallel to the existing one
* when everything works fine and a vote is passed,
the old build system will be removed
* move blocks into [svn]/cocoon/blocks --> blocks are independant units
with their own lifecycle
- reduce Cocoon core to a minimum
to be done
- versioning guide
done for Ccooon core; needs enhancements because of the more
independant blocks and their own lifecycles
- rethink our distribution policy
with the new block building system we can distribute Cocoon as binary again;
we have to decide which blocks are part of an official Cocoon distribution
- new documentation system
consider the efforts on users list and restructure the docs;
separation of blocks also requires splitting up the docs
Could people knowing more about those points give some feedback?
Anything else open for 2.2?
So let's talk about a schedule ...
----------------------------------
Many things are already done. Open issues that may take longer are:
- VirtualSitemapCompoents
- stabelize cForms
- new block building and deploying mechanism (+ transition see above)
- docs
- clean up
The first three tasks have to be done before we can release a contract-stable
Cocoon 2.2 beta1. I plan to have implemented deployer and builder by the end of
January. Then we could release a beta1 in February ;-) Is this a realistic
timeframe for others, especially those who work on cForms (Sylvain, Tim) and
virtualComponents (Vadim)?
Cocoon 2.3
----------
To make it short: I want Cocoon 2.3 be based on whiteboard/kernel. AFAIK the
implementation of kernel is stable and "only" needs to be merged with ECM.
Are there any reasons not to make Pier's kernel the official base of Cocoon 2.3?
If not, Pier should have the "permission" to move its kernel into an offical 2.3
directory in our SVN whenever he thinks it's time for it. (... I prepare a vote
after the discussion)
Cocoon 2.1
----------
As being said, we expect further patch rleases (2.1.7 and 2.1.8), especially
after cForms has become stable.
release date of 2.1.7 (with or without a stable cForms block): February 2005?
Thanks for reading!
--
Reinhard
[1] http://nagoya.apache.org/eyebrowse/BrowseList?
listName=cocoon-dev@xml.apache.org&by=thread&from=902090
Re: Planning Cocoon's future
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 23 nov. 04, à 16:42, Reinhard Poetz a écrit :
> ...So if you (vadim, betrand, sylvain) tell me that we should wait for
> a working replacement I don't have a problem to drop this point...
+1
Actually we might need to invent a new status for XSP: it's not
deprecated, we don't recommend using it and we're not looking to
develop it any further. But we recognize it's important for some users,
and as such are in no hurry to kill it.
-Bertrand
Re: Planning Cocoon's future
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez 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?
>> --------------------------------------------------------
>> (based on xdocs/plan/roadmap.xml)
>>
>> - stable Cocoon Forms
>> the status is summarizes by Sylvain[1]
>
>
>
> I need to invest more time into this...
At least a wiki summary or over-working the existing cforms roadmap entries in
Bugzilla would be cool ;-) <hint/> ;-)
>
>> - Virtual Sitemap Components
>> Vadim started with the implementation
>
> You have also to consider my "multi-relative" sourceresolving RT
> (http://www.mail-archive.com/dev@cocoon.apache.org/msg24485.html)
Yep, of course!
>
>> - inheritable views
>> don't know the status (I think Carsten is/was working on it)
>
>
>
> Inheritable views should come as a fee bonus with VSCs, as views can
> simply be turned into virtual serializers.
>
>> - deprecate XSP
>> to be done (needs an alternative)
>
>
>
> Deprecate? It's not mainstream, but used a lot in many places. The risk
> if XSPs are deprecated and then removed is that people will start using
> JSPGenerator to write quickly some custom generator, which IMO would be
> a very bad thing.
I read src/documentation/xdocs/plan/roadmap.xml and there was an entry that we
want to deprecate it. Not more, not less :-)
So if you (vadim, betrand, sylvain) tell me that we should wait for a working
replacement I don't have a problem to drop this point.
>> Daniel, are you working on a JXTG 2.0?
>>
>> - Cleaning up the caching/store mess
>> don't know, does it work now as it should?
>>
>> - separate blocks from Core
>> that's my job: I'm working on a block-builder and a block-deployer
>> that will make this separation possible and will give us the chance
>> of a smooth transition from our current monolytic system to a
>> decentral
>> blocks orientated system:
>>
>> * every block get's a descriptor containing all meta information
>> like
>> author, license, status, block references and library references
>> --> should as close as possible to the needs of RealBlocks
>> * enhance jars.xml to become a repository (only needs an id
>> attribute
>> for all entries so they can be references and looked up)
>> * setup the new block centric build system parallel to the
>> existing one
>> * when everything works fine and a vote is passed,
>> the old build system will be removed
>> * move blocks into [svn]/cocoon/blocks --> blocks are
>> independant units
>> with their own lifecycle
>
>
>
> I hadn't had a chance yet to look at your job, but had some random
> thoughts about an easier handling of blocks, buy simply allowing
> cocoon.roles and cocoon.xconf to be split in several smaller files:
> - the role manager could search all "cocoon.roles" files present in the
> classpath to build the main role manager
> - the root component manager could assemble all *.xconf files present in
> WEB-INF.
> That way, a "block" (better named a "module") would be composed of a
> xxx.jar containing a cocoon.roles snippet, and a xxx.xcconf configuring
> that block's component definition. Adding/removing a module from Cocoon
> would then simply a matter of moving around these two files.
Your ideas are worth to be investigated further! :-)
I'll comment on this by the end of the week in a separate thread
>
>> - reduce Cocoon core to a minimum
>> to be done
>>
>> - versioning guide
>> done for Ccooon core; needs enhancements because of the more
>> independant blocks and their own lifecycles
>>
>> - rethink our distribution policy
>> with the new block building system we can distribute Cocoon as
>> binary again;
>> we have to decide which blocks are part of an official Cocoon
>> distribution
>>
>> - new documentation system
>> consider the efforts on users list and restructure the docs;
>> separation of blocks also requires splitting up the docs
>>
>>
>> Could people knowing more about those points give some feedback?
>> Anything else open for 2.2?
>>
>>
>> So let's talk about a schedule ...
>> ----------------------------------
>> Many things are already done. Open issues that may take longer are:
>>
>> - VirtualSitemapCompoents
>> - stabelize cForms
>> - new block building and deploying mechanism (+ transition see above)
>> - docs
>> - clean up
>>
>> The first three tasks have to be done before we can release a
>> contract-stable
>> Cocoon 2.2 beta1. I plan to have implemented deployer and builder by
>> the end of
>> January. Then we could release a beta1 in February ;-) Is this a
>> realistic
>> timeframe for others, especially those who work on cForms (Sylvain,
>> Tim) and
>> virtualComponents (Vadim)?
Sylvain, as you are one of them knowing what we have to do to make cForms stable
and implement virtual sitemap components, is this a realistic schedule (first
contract stable beta in February 2005)?
>> Cocoon 2.3
>> ----------
>> To make it short: I want Cocoon 2.3 be based on whiteboard/kernel.
>> AFAIK the
>> implementation of kernel is stable and "only" needs to be merged with
>> ECM.
>>
>> Are there any reasons not to make Pier's kernel the official base of
>> Cocoon 2.3? If not, Pier should have the "permission" to move its
>> kernel into an offical 2.3 directory in our SVN whenever he thinks
>> it's time for it. (... I prepare a vote after the discussion)
>
> If the kernel is stable, should it really be 2.3 or can it be 2.2?
I would say that we plan 2.2 without kernel and *if* Pier has finished the
integration before we want to release our first 2.2beta (stable contracts!), we
can talk again but we shouldn't bind us now to wait for it (I don't want to wait
as long as we waited for 2.1).
Maybe I'm too pessimistic but if Pier integrates kernel and Cocoon 2.2 by the
end of the year, it will take us another 5 month to be able to release a
contract stable version.
Worst case would be that 2.3 follows 2.2 pretty soon ;-)
The drawback is that we would have different kind of blocks which would be
incompatible to each other. But this is the same with Eclipse plugins too. 2.1
plugins don't work in 3.0 or vice verca.
>> Cocoon 2.1
>> ----------
>> As being said, we expect further patch rleases (2.1.7 and 2.1.8),
>> especially after cForms has become stable.
>>
>> release date of 2.1.7 (with or without a stable cForms block):
>> February 2005?
>
> Maybe earlier?
Why not! beginning of January?
--
Reinhard
Re: Planning Cocoon's future
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard,
first of all, many thanks for moving this forward.
Sylvain Wallez 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?
>> --------------------------------------------------------
>> (based on xdocs/plan/roadmap.xml)
>>
>> - stable Cocoon Forms
>> the status is summarizes by Sylvain[1]
>
>
>
> I need to invest more time into this...
>
>> - Virtual Sitemap Components
>> Vadim started with the implementation
>
>
> You have also to consider my "multi-relative" sourceresolving RT
> (http://www.mail-archive.com/dev@cocoon.apache.org/msg24485.html)
>
>> - inheritable views
>> don't know the status (I think Carsten is/was working on it)
>
> Inheritable views should come as a fee bonus with VSCs, as views can
> simply be turned into virtual serializers.
yey!
>> - deprecate XSP
>> to be done (needs an alternative)
>
> Deprecate? It's not mainstream, but used a lot in many places. The risk
> if XSPs are deprecated and then removed is that people will start using
> JSPGenerator to write quickly some custom generator, which IMO would be
> a very bad thing.
Yep, same feeling here.
>> Daniel, are you working on a JXTG 2.0?
>>
>> - Cleaning up the caching/store mess
>> don't know, does it work now as it should?
>>
>> - separate blocks from Core
>> that's my job: I'm working on a block-builder and a block-deployer
>> that will make this separation possible and will give us the chance
>> of a smooth transition from our current monolytic system to a
>> decentral
>> blocks orientated system:
>>
>> * every block get's a descriptor containing all meta information
>> like
>> author, license, status, block references and library references
>> --> should as close as possible to the needs of RealBlocks
>> * enhance jars.xml to become a repository (only needs an id
>> attribute
>> for all entries so they can be references and looked up)
>> * setup the new block centric build system parallel to the
>> existing one
>> * when everything works fine and a vote is passed,
>> the old build system will be removed
>> * move blocks into [svn]/cocoon/blocks --> blocks are
>> independant units
>> with their own lifecycle
>
>
>
> I hadn't had a chance yet to look at your job, but had some random
> thoughts about an easier handling of blocks, buy simply allowing
> cocoon.roles and cocoon.xconf to be split in several smaller files:
> - the role manager could search all "cocoon.roles" files present in the
> classpath to build the main role manager
> - the root component manager could assemble all *.xconf files present in
> WEB-INF.
>
> That way, a "block" (better named a "module") would be composed of a
> xxx.jar containing a cocoon.roles snippet, and a xxx.xcconf configuring
> that block's component definition. Adding/removing a module from Cocoon
> would then simply a matter of moving around these two files.
yes, a great first step thing would be to remove the need for the
xconfpatch ant task.
>> - reduce Cocoon core to a minimum
>> to be done
>>
>> - versioning guide
>> done for Ccooon core; needs enhancements because of the more
>> independant blocks and their own lifecycles
>>
>> - rethink our distribution policy
>> with the new block building system we can distribute Cocoon as
>> binary again;
>> we have to decide which blocks are part of an official Cocoon
>> distribution
if the deployment is easy enough, I would say none :-)
>> - new documentation system
>> consider the efforts on users list and restructure the docs;
>> separation of blocks also requires splitting up the docs
>>
>> Could people knowing more about those points give some feedback?
>> Anything else open for 2.2?
See my next RT.
>>
>>
>> So let's talk about a schedule ...
>> ----------------------------------
>> Many things are already done. Open issues that may take longer are:
>>
>> - VirtualSitemapCompoents
>> - stabelize cForms
>> - new block building and deploying mechanism (+ transition see above)
>> - docs
>> - clean up
>>
>> The first three tasks have to be done before we can release a
>> contract-stable
>> Cocoon 2.2 beta1. I plan to have implemented deployer and builder by
>> the end of
>> January. Then we could release a beta1 in February ;-) Is this a
>> realistic
>> timeframe for others, especially those who work on cForms (Sylvain,
>> Tim) and
>> virtualComponents (Vadim)?
>>
>>
>> Cocoon 2.3
>> ----------
>> To make it short: I want Cocoon 2.3 be based on whiteboard/kernel.
>> AFAIK the
>> implementation of kernel is stable and "only" needs to be merged with
>> ECM.
>>
>> Are there any reasons not to make Pier's kernel the official base of
>> Cocoon 2.3? If not, Pier should have the "permission" to move its
>> kernel into an offical 2.3 directory in our SVN whenever he thinks
>> it's time for it. (... I prepare a vote after the discussion)
>
> If the kernel is stable, should it really be 2.3 or can it be 2.2?
my suggestion would be: leave the kernel out and let's keep working on
allowing us to deploy and ship the blocks in binary format.
classloading isolation will happen later, when the need will be
impossible for people to avoid ;-)
>> Cocoon 2.1
>> ----------
>> As being said, we expect further patch rleases (2.1.7 and 2.1.8),
>> especially after cForms has become stable.
>>
>> release date of 2.1.7 (with or without a stable cForms block):
>> February 2005?
>
>
>
> Maybe earlier?
>
> Sylvain
>
--
Stefano.
Re: Planning Cocoon's future
Posted by Sylvain Wallez <sy...@apache.org>.
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?
> --------------------------------------------------------
> (based on xdocs/plan/roadmap.xml)
>
> - stable Cocoon Forms
> the status is summarizes by Sylvain[1]
I need to invest more time into this...
> - Virtual Sitemap Components
> Vadim started with the implementation
You have also to consider my "multi-relative" sourceresolving RT
(http://www.mail-archive.com/dev@cocoon.apache.org/msg24485.html)
> - inheritable views
> don't know the status (I think Carsten is/was working on it)
Inheritable views should come as a fee bonus with VSCs, as views can
simply be turned into virtual serializers.
> - deprecate XSP
> to be done (needs an alternative)
Deprecate? It's not mainstream, but used a lot in many places. The risk
if XSPs are deprecated and then removed is that people will start using
JSPGenerator to write quickly some custom generator, which IMO would be
a very bad thing.
> Daniel, are you working on a JXTG 2.0?
>
> - Cleaning up the caching/store mess
> don't know, does it work now as it should?
>
> - separate blocks from Core
> that's my job: I'm working on a block-builder and a block-deployer
> that will make this separation possible and will give us the chance
> of a smooth transition from our current monolytic system to a
> decentral
> blocks orientated system:
>
> * every block get's a descriptor containing all meta information
> like
> author, license, status, block references and library references
> --> should as close as possible to the needs of RealBlocks
> * enhance jars.xml to become a repository (only needs an id
> attribute
> for all entries so they can be references and looked up)
> * setup the new block centric build system parallel to the
> existing one
> * when everything works fine and a vote is passed,
> the old build system will be removed
> * move blocks into [svn]/cocoon/blocks --> blocks are
> independant units
> with their own lifecycle
I hadn't had a chance yet to look at your job, but had some random
thoughts about an easier handling of blocks, buy simply allowing
cocoon.roles and cocoon.xconf to be split in several smaller files:
- the role manager could search all "cocoon.roles" files present in the
classpath to build the main role manager
- the root component manager could assemble all *.xconf files present in
WEB-INF.
That way, a "block" (better named a "module") would be composed of a
xxx.jar containing a cocoon.roles snippet, and a xxx.xcconf configuring
that block's component definition. Adding/removing a module from Cocoon
would then simply a matter of moving around these two files.
> - reduce Cocoon core to a minimum
> to be done
>
> - versioning guide
> done for Ccooon core; needs enhancements because of the more
> independant blocks and their own lifecycles
>
> - rethink our distribution policy
> with the new block building system we can distribute Cocoon as
> binary again;
> we have to decide which blocks are part of an official Cocoon
> distribution
>
> - new documentation system
> consider the efforts on users list and restructure the docs;
> separation of blocks also requires splitting up the docs
>
>
> Could people knowing more about those points give some feedback?
> Anything else open for 2.2?
>
>
> So let's talk about a schedule ...
> ----------------------------------
> Many things are already done. Open issues that may take longer are:
>
> - VirtualSitemapCompoents
> - stabelize cForms
> - new block building and deploying mechanism (+ transition see above)
> - docs
> - clean up
>
> The first three tasks have to be done before we can release a
> contract-stable
> Cocoon 2.2 beta1. I plan to have implemented deployer and builder by
> the end of
> January. Then we could release a beta1 in February ;-) Is this a
> realistic
> timeframe for others, especially those who work on cForms (Sylvain,
> Tim) and
> virtualComponents (Vadim)?
>
>
> Cocoon 2.3
> ----------
> To make it short: I want Cocoon 2.3 be based on whiteboard/kernel.
> AFAIK the
> implementation of kernel is stable and "only" needs to be merged with
> ECM.
>
> Are there any reasons not to make Pier's kernel the official base of
> Cocoon 2.3? If not, Pier should have the "permission" to move its
> kernel into an offical 2.3 directory in our SVN whenever he thinks
> it's time for it. (... I prepare a vote after the discussion)
If the kernel is stable, should it really be 2.3 or can it be 2.2?
> Cocoon 2.1
> ----------
> As being said, we expect further patch rleases (2.1.7 and 2.1.8),
> especially after cForms has become stable.
>
> release date of 2.1.7 (with or without a stable cForms block):
> February 2005?
Maybe earlier?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Planning Cocoon's future
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-11-23 at 18:07 +0100, Reinhard Poetz wrote:
> Jonas Ekstedt wrote:
>
> >
> > The idea of the transformer is to be a replacement for JXTG.
>
> Citing Vadim talking about JXTG 2.0: "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."
>
Yes, after having seen the benchmarks in [1] it doesn't seem like such a
good idea anymore.
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105029949912114&w=2
Cheers Jonas
Re: Planning Cocoon's future
Posted by Reinhard Poetz <re...@apache.org>.
Jonas Ekstedt wrote:
>
> The idea of the transformer is to be a replacement for JXTG.
Citing Vadim talking about JXTG 2.0: "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."
--
Reinhard
Re: Planning Cocoon's future
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
>On Tue, 2004-11-23 at 12:51 +0100, Daniel Fagerstrom wrote:
>snip...
>
>
>>The main question now IMO is what tag framework we should base JXTG 2.0
>>on. The candidates that has been mentioned this far are: Jelly, the
>>taglib, Carsten's taglib and Jonas taglib (are there more alternatives).
>>I discussed Jelly with Carsten and the conclusion was that it doesn't
>>fit that well in Cocoon. I don't know Carsten's plans for his taglib.
>>Jonas need to some advertising of his taglib and explain how it relates
>>to the alternatives.
>>
>>
>
>Hello, I didn't have the time to do a proper presentation of the
>template transformer last week but I'll try to explain it a bit. First
>of all let me say that I have updated the download and the new version
>can be found at:
>http://home.student.uu.se/j/joek8725/template.zip
>
>The idea of the transformer is to be a replacement for JXTG. All JX tags
>can easily be implemented as Tag classes. It supports JSTL expressions
>using commons-el but not XPath (XPath support could perhaps be provided
>using JSTLs ability to define functions). Expressions are also
>converted using the conversion block discussed before.
>
>Similar to taglib it allows extending by tag classes. These tags are
>configured in sitemap.xmap (as opposed to taglib which does it in
>cocoon.xconf) which allows for reconfiguration without restarting
>cocoon.
>
>Variables are done a wee bit differently to taglib. The transformer has
>a stack of maps that contains all variables. The
>TemplateObjectModelHelper populates the bottom Map. Tags can then
>introduce new variable contexts by pushing and popping maps on the
>stack. The variables in lower maps are still "gettable" but can be
>overloaded by whatever variables the tags introduce in the new context.
>As an example here is the ForTag:
>
>public class ForTag extends AbstractTag {
>
> String var;
> int begin;
> int end;
> int step;
> RecordingConsumer recorder;
>
> public void start() {
> var = getAttribute("var", null);
> begin = evalInt(getAttribute("begin"));
> end = evalInt(getAttribute("end"));
> step = evalInt(getAttribute("step", "1"));
>
> recorder = new RecordingConsumer();
> transformer.pushConsumer(recorder);
> }
>
> public void end() {
> SaxBuffer buffer = recorder.getSaxBuffer();
>
> variables.push();
> for (int i = begin; i <= end; i+= step) {
> if (var != null)
> variables.put(var, new Integer(i));
> play(buffer);
> }
> variables.pop();
> }
>
>}
>
>As you can see in the end() method the variable context is first pushed
>(which adds a Map on the stack) and later popped when the buffer has
>been played.
>
>Another feature visible from the sample above is that it allows tags to
>do whatever it wants with the body content. The transformer keeps a
>stack of consumers that tags operate on by pushing and popping.
>Currently I've implemented a RecordingConsumer and an IgnoringConsumer
>(which simple ignores the body content).
>
>To summarize the template transformer is basically a merge of the
>features of taglib (tag classes) and jxtg (expression evaluation) with
>the added benefit of object conversion.
>
>Cheers Jonas
>
Thanks for your explanation. I have evaluated your code in more detail
and have some comments:
First I think your code is much easier to follow than the taglib. Your
design is much simpler whithout losing any power, AFAICS. And as one of
the main requirements for the JXTG successor is suportable code, I think
that it would be better to base JXTG 2.0 on your code than the taglib.
The variable stack and configuring the choice of taglibs in the sitemap
seem better than the coresponding things for taglib.
The major point to make it suitable for replacing JXTG, is to package it
as a generator instead and implement it with pre-compilation of the
template as in JXTG. One of the advantages with JXTG is it's performance
and without pre-compilation I would guess that it hard to match that
performance. See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105029949912114&w=2.
Another important point from my POV is how to write tags. After having
compared Jelly's taglib mechanism with the JSP inspired way I must say
that I prefer Jelly's way. In Jelly you just have a "doTag(XMLOutput)"
instead of the JSP taglib inspired "begin()" and "end()" methods. And if
you want to use the content of your tag you just call
"invokeBody(XMLOutput)", and the framework take care of all XML
recording etc.
I'll give a more detailed explanation and some design ideas for the two
above points in another post.
---o0o---
Now some less important and technical points about the code:
For attribute and character evaluation in the tag framework, IMHO it
should be the taglib's responsibility to parse the text and find the
expressions inside "${<expr>}". Then the taglib let the expression
language (EL) component take care of the expression. In your
implementation the EL component takes care about the whole text.
I think the TemplateTransformer should be completely responsible for
handling the consumer stack. That makes the contracts and the concern
areas for the Consumers more focused.
o.a.c.xml.ContentHandlerWrapper does the same thing as the
AbstractIdentityTransformer, AFAICS.
/Daniel
Re: Planning Cocoon's future
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-11-23 at 12:51 +0100, Daniel Fagerstrom wrote:
snip...
> The main question now IMO is what tag framework we should base JXTG 2.0
> on. The candidates that has been mentioned this far are: Jelly, the
> taglib, Carsten's taglib and Jonas taglib (are there more alternatives).
> I discussed Jelly with Carsten and the conclusion was that it doesn't
> fit that well in Cocoon. I don't know Carsten's plans for his taglib.
> Jonas need to some advertising of his taglib and explain how it relates
> to the alternatives.
Hello, I didn't have the time to do a proper presentation of the
template transformer last week but I'll try to explain it a bit. First
of all let me say that I have updated the download and the new version
can be found at:
http://home.student.uu.se/j/joek8725/template.zip
The idea of the transformer is to be a replacement for JXTG. All JX tags
can easily be implemented as Tag classes. It supports JSTL expressions
using commons-el but not XPath (XPath support could perhaps be provided
using JSTLs ability to define functions). Expressions are also
converted using the conversion block discussed before.
Similar to taglib it allows extending by tag classes. These tags are
configured in sitemap.xmap (as opposed to taglib which does it in
cocoon.xconf) which allows for reconfiguration without restarting
cocoon.
Variables are done a wee bit differently to taglib. The transformer has
a stack of maps that contains all variables. The
TemplateObjectModelHelper populates the bottom Map. Tags can then
introduce new variable contexts by pushing and popping maps on the
stack. The variables in lower maps are still "gettable" but can be
overloaded by whatever variables the tags introduce in the new context.
As an example here is the ForTag:
public class ForTag extends AbstractTag {
String var;
int begin;
int end;
int step;
RecordingConsumer recorder;
public void start() {
var = getAttribute("var", null);
begin = evalInt(getAttribute("begin"));
end = evalInt(getAttribute("end"));
step = evalInt(getAttribute("step", "1"));
recorder = new RecordingConsumer();
transformer.pushConsumer(recorder);
}
public void end() {
SaxBuffer buffer = recorder.getSaxBuffer();
variables.push();
for (int i = begin; i <= end; i+= step) {
if (var != null)
variables.put(var, new Integer(i));
play(buffer);
}
variables.pop();
}
}
As you can see in the end() method the variable context is first pushed
(which adds a Map on the stack) and later popped when the buffer has
been played.
Another feature visible from the sample above is that it allows tags to
do whatever it wants with the body content. The transformer keeps a
stack of consumers that tags operate on by pushing and popping.
Currently I've implemented a RecordingConsumer and an IgnoringConsumer
(which simple ignores the body content).
To summarize the template transformer is basically a merge of the
features of taglib (tag classes) and jxtg (expression evaluation) with
the added benefit of object conversion.
Cheers Jonas
Re: Planning Cocoon's future
Posted by Sylvain Wallez <sy...@apache.org>.
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)
>> Daniel, are you working on a JXTG 2.0?
>
>
> No, not yet. I sumarized my view of the results of the discussion this
> far in a previous mail:
>
>> The conclusion was IIRC, that we like JXTG but not it's
>> implementation (to large and scary) and that we need the ability to
>> add custom tags. The implementation would be easier to follow and
>> more reusable if the object model was factored out (using Carsten's
>> TemplateObjectHelper), factoring out the expression language and
>> possibly make it plugable and writing the tags as custom tags.
>>
>> We don't want to complicate life for the users (and ourselves) by
>> differ from JXTG whithout very good reasons, and in that case we
>> should deprecate the things that we don't like. So the "new" template
>> generator should include the JXTG tags.
>
>
> The main question now IMO is what tag framework we should base JXTG
> 2.0 on. The candidates that has been mentioned this far are: Jelly,
> the taglib, Carsten's taglib and Jonas taglib (are there more
> alternatives). I discussed Jelly with Carsten and the conclusion was
> that it doesn't fit that well in Cocoon. I don't know Carsten's plans
> for his taglib. Jonas need to some advertising of his taglib and
> explain how it relates to the alternatives.
Sorry, I don't understand here: taglib is a transformer whereas JXTG is
a generator (the JXT Transformer is basically the JXTG reading its input
from the incoming stream rather than a source), which allows to cache
the compiled template. Can the taglib transformer be turned into a
generator (I guess yes), and use some template caching?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Taglib Block, and Re: Planning Cocoon's future
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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.
Taglib Block, and Re: Planning Cocoon's future
Posted by 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: Planning Cocoon's future
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>>> 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.
>>
>>
>>
>> Sounds good. Does anybody feel responsible driving this effort so
>> that we can depcrecate XSP in 2.2?
>
> Templating is one of my strongest interest in cocoon. I am not that
> experienced to be able to come up with some templating solution myself
> but with a little design help from someone I could surely take a big
> part of work. Daniel would you help?
>
Sure!
I'll try to write down some more detailed thoughts about JXTG 2 design
as soon as I find time.
/Daniel
Re: Planning Cocoon's future
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
>> 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.
>
>
> Sounds good. Does anybody feel responsible driving this effort so that
> we can depcrecate XSP in 2.2?
Templating is one of my strongest interest in cocoon. I am not that
experienced to be able to come up with some templating solution myself
but with a little design help from someone I could surely take a big
part of work. Daniel would you help?
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Planning Cocoon's future
Posted by Reinhard Poetz <re...@apache.org>.
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)
>> Daniel, are you working on a JXTG 2.0?
>
>
> No, not yet. I sumarized my view of the results of the discussion this
> far in a previous mail:
>
>> The conclusion was IIRC, that we like JXTG but not it's implementation
>> (to large and scary) and that we need the ability to add custom tags.
>> The implementation would be easier to follow and more reusable if the
>> object model was factored out (using Carsten's TemplateObjectHelper),
>> factoring out the expression language and possibly make it plugable
>> and writing the tags as custom tags.
>>
>> We don't want to complicate life for the users (and ourselves) by
>> differ from JXTG whithout very good reasons, and in that case we
>> should deprecate the things that we don't like. So the "new" template
>> generator should include the JXTG tags.
>
>
> The main question now IMO is what tag framework we should base JXTG 2.0
> on. The candidates that has been mentioned this far are: Jelly, the
> taglib, Carsten's taglib and Jonas taglib (are there more alternatives).
> I discussed Jelly with Carsten and the conclusion was that it doesn't
> fit that well in Cocoon. I don't know Carsten's plans for his taglib.
> Jonas need to some advertising of his taglib and explain how it relates
> to the alternatives.
>
> 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?
>
> 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.
Sounds good. Does anybody feel responsible driving this effort so that we can
depcrecate XSP in 2.2?
--
Reinhard
Re: Planning Cocoon's future
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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)
> Daniel, are you working on a JXTG 2.0?
No, not yet. I sumarized my view of the results of the discussion this
far in a previous mail:
> The conclusion was IIRC, that we like JXTG but not it's implementation
> (to large and scary) and that we need the ability to add custom tags.
> The implementation would be easier to follow and more reusable if the
> object model was factored out (using Carsten's TemplateObjectHelper),
> factoring out the expression language and possibly make it plugable
> and writing the tags as custom tags.
>
> We don't want to complicate life for the users (and ourselves) by
> differ from JXTG whithout very good reasons, and in that case we
> should deprecate the things that we don't like. So the "new" template
> generator should include the JXTG tags.
The main question now IMO is what tag framework we should base JXTG 2.0
on. The candidates that has been mentioned this far are: Jelly, the
taglib, Carsten's taglib and Jonas taglib (are there more alternatives).
I discussed Jelly with Carsten and the conclusion was that it doesn't
fit that well in Cocoon. I don't know Carsten's plans for his taglib.
Jonas need to some advertising of his taglib and explain how it relates
to the alternatives.
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?
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.
WDYT?
/Daniel
Re: Planning Cocoon's future
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Ugo:
Ugo Cei dijo:
> Il giorno 23/nov/04, alle 11:53, Reinhard Poetz ha scritto:
>
>> release date of 2.1.7 (with or without a stable cForms block):
>> February 2005?
>
> Nah. I propose Christmas 2004 ;-). Now, seriously, we should aim for a
> shorter release cycle. There is already the upgrade to DELI that
> Antonio wanted to commit shortly before the latest release, but was
> delayed.
Thanks for the big hint. I will try to review the patch and commit it over
the weekend. ;-)
Best Regards,
Antonio Gallardo
Re: Planning Cocoon's future
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 23/nov/04, alle 11:53, Reinhard Poetz ha scritto:
> release date of 2.1.7 (with or without a stable cForms block):
> February 2005?
Nah. I propose Christmas 2004 ;-). Now, seriously, we should aim for a
shorter release cycle. There is already the upgrade to DELI that
Antonio wanted to commit shortly before the latest release, but was
delayed. And there might be some new bugs (see the recent message about
problems with Lenya). If we fix those bugs (assuming they can be
confirmed), let's release ASAP. Ideally when Carsten comes back from
his holidays, or even before if someone else wants to play the release
manager.
Ugo
--
Ugo Cei - http://beblogging.com/