Re: [Plan] The future of Cocoon
On Wed, 26 May 2004, Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) many people talking about deprecate XSP but can i ask something? is any better alternative to produce xml quering databases? i think that until now the way ESQL--XML-- any tranfrormation -- .. has no better alternative --stavros - cleaning up the caching/store mess - remove deprecated blocks etc. I like it, I like it! :-) (yep, twice). Starting on 2.2 to bring the current 2.1 to a level of complete solidity of contracts and features is, IMVHO, an optimal idea, and puts us in the position (also) to start using the Linux-like versioning scheme. 2.2 will be our stable tree, and all crummy development (real blocks, and you name it) can easily happen in 2.3 which will always be kept as unstable, to end up with a 2.4 release! :-P Now, the only thing I'm horrified about is that voice about a BRANCH in our current CVS (aaag)... I'd say we clear out the 2.2 CVS repo and do a clean re-import of 2.1.5, or switch to Subversion now, but purlllease don't add any branch in the tree... If someone wants, I can rename the 2.2 repository into a 2.3 straight away (so that we ain't going to lose anything)... Pier
Re: [Plan] The future of Cocoon
[EMAIL PROTECTED] wrote: On Wed, 26 May 2004, Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) many people talking about deprecate XSP but can i ask something? is any better alternative to produce xml quering databases? i think that until now the way ESQL--XML-- any tranfrormation -- .. has no better alternative No there isn't. And until there is, XSP can't be deprecated. Hence Carsten saying, and provide a viable alternative. Upayavira - cleaning up the caching/store mess - remove deprecated blocks etc. I like it, I like it! :-) (yep, twice). Starting on 2.2 to bring the current 2.1 to a level of complete solidity of contracts and features is, IMVHO, an optimal idea, and puts us in the position (also) to start using the Linux-like versioning scheme. 2.2 will be our stable tree, and all crummy development (real blocks, and you name it) can easily happen in 2.3 which will always be kept as unstable, to end up with a 2.4 release! :-P Now, the only thing I'm horrified about is that voice about a BRANCH in our current CVS (aaag)... I'd say we clear out the 2.2 CVS repo and do a clean re-import of 2.1.5, or switch to Subversion now, but purlllease don't add any branch in the tree... If someone wants, I can rename the 2.2 repository into a 2.3 straight away (so that we ain't going to lose anything)... Pier
RE: [Plan] The future of Cocoon
Pier Fumagalli wrote: On 26 May 2004, at 10:17, Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. I like it, I like it! :-) (yep, twice). Starting on 2.2 to bring the current 2.1 to a level of complete solidity of contracts and features is, IMVHO, an optimal idea, and puts us in the position (also) to start using the Linux-like versioning scheme. Yupp! 2.2 will be our stable tree, and all crummy development (real blocks, and you name it) can easily happen in 2.3 which will always be kept as unstable, to end up with a 2.4 release! :-P Yepp ! Now, the only thing I'm horrified about is that voice about a BRANCH in our current CVS (aaag)... I'd say we clear out the 2.2 CVS repo and do a clean re-import of 2.1.5, or switch to Subversion now, but purlllease don't add any branch in the tree... Yes, I think we should wait for the switch (next monday I think it was) and then continue. If someone wants, I can rename the 2.2 repository into a 2.3 straight away (so that we ain't going to lose anything)... We should just properly import it into svn. Carsten
Re: [Plan] The future of Cocoon
Carsten Ziegeler wrote:
Now as we have 2.1.5 out, I think we should talk about the future
a little bit - we already have discussed several things in the
past and I want to try to summarize things.
First, I heard in the past complains from users at conferences where
I presented Cocoon, that it's not identifiable what our plans for
the future (or for upcomming versions) are. We often discuss this
openly in our mailing lists, but we rarely put the results to a
prominent place (TODO/planning document). So imho we should at least
try to do this :) (and yes, I'm of course guilty for not doing this
as well).
We need also to organise our docs so that modern techniques are
explained first, in order for newbies not to get lost in the amount of
possible ways to solve a problem.
Ok, the first plan for the future is obvious: the move to svn :)
But what else?
We have come to the conclusion that real blocks might take a little bit
longer than we have expected. So we agreed on not affecting the
current development of Cocoon by the real blocks development. Which means
we have to develop the blocks system separately from Cocoon
until the block system is stable enough to be merged into
Cocoon. This allows us to release new versions of Cocoon (like 2.2)
without waiting for blocks to be working/finished.
We started with Cocoon 2.2 right after the release, so we can
put anything into it we want. I hope to implement the virtual
sitemap components soon, for example. I guess (fear?) that we will
have one or two maintenance releases for 2.1.x (2.1.6 etc.). For
example fixing the dispose problem in the tree processor.
In general, I think we should try to see 2.2 as the consolidation
version. In the past we added a lot of features, blocks, components
which resulted in the fact that we have in some places concurring
solutions that could be combined a little bit.
One good example is form handling where we agreed on concentrating
on CForms. We could try this in other areas as well.
Of course this does not mean that we shouldn't add new features
for 2.2, but imho we should try to consolidate what we currently
have as well.
Some things that come to my mind for 2.2:
- first finished version of CForms.
- deprecate XSP (and provide a viable alternative)
-1: XSP has been moved to its own block meaning it's no more core, but
hundreds (if not thousands) or people are using it on a daily basis. We
can drive people towards new techniques such as flow/jxtemplate, but
cannot deprecate what's has been a central part of Cocoon for so many years.
Personal note: your post made many people rush into my office saying
What, what, deprecate XSP? He's crazy! ;-)
- cleaning up the caching/store mess
What's left to do here?
- remove deprecated blocks etc.
Mmh... this breaks compatibility. Taking Ugo's idea, what about creating
an additional categorization level for blocks, such as experimental,
samples, applications, deprecated, archive?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [Plan] The future of Cocoon
Sylvain Wallez wrote: -1: XSP has been moved to its own block meaning it's no more core, but hundreds (if not thousands) or people are using it on a daily basis. We can drive people towards new techniques such as flow/jxtemplate, but cannot deprecate what's has been a central part of Cocoon for so many years. Personal note: your post made many people rush into my office saying What, what, deprecate XSP? He's crazy! ;-) Now they are calling me crazy - well... :) Deprecating doesn't mean removing! by deprecating we show our users that we think that there are better ways than XSP. And we show that we are not developing this technique further (of course bug fixes etc will be applied) That's all. We *can* than remove XSP in another minor or major release, but we don't need to. So, this is just a signal. - cleaning up the caching/store mess What's left to do here? I will write an RT soon (next week I guess). - remove deprecated blocks etc. Mmh... this breaks compatibility. No, it doesn't :) (Well, yes, it does, but) According to our versioning guide we can remove deprecated things with a new minor version and we can start following this - we don't have to. I think there is currently only one deprecated block anyway. Taking Ugo's idea, what about creating an additional categorization level for blocks, such as experimental, samples, applications, deprecated, archive? Í have nothing against it - but at some point of time you have to get rid off deprecated things; otherwise you kill your architecture sooner or later. So deprecating things soon, give an alternative and then remove the deprecated things after a time is imho the right way to go. Otherwise deprecating doesn't make that much sense. Carsten
Re: [Plan] The future of Cocoon
Ugo Cei wrote:
Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto:
Some things that come to my mind for 2.2:
- first finished version of CForms.
- deprecate XSP (and provide a viable alternative)
- cleaning up the caching/store mess
- remove deprecated blocks etc.
- Differentiate between blocks that provide a service to other blocks
and blocks that contain just samples or small applications built upon
cocoon (petstore, tour, linotpye). Maybe samples-only blocks should
be a separate download.
+1
-Deprecate blocks that haven't been maintained in a long while or
don't serve any evident purpose. Web3, apples, python, php, asciiart
come to mind. Maybe I'm wrong about some of them but I just want to
make a point, we can then decide on a case-by-case basis.
+1
- Review the implications and the implementation of pooling.
A big +1.
- Reduce unneeded dependencies on Avalon, where possible.
+1. Stated differently: introduce constructor and property dependency
injection.
- Review the logging framework. Log4j is the de-facto standard and we
have blocks that complain if Log4j is not properly configured, so
let's accept it and stop reinventing the wheel.
See my answer to Carsten.
- Drop that Excalibur datasource. Components that need a DS should get
one provided by the container via JNDI. If we don't have a container
(running via the CLI, for instance), let the environment provide one
and bind it to a JNDI namespace.
Mmmhh... defining the JNDI datasources is container-specific, and
therefore makes the applications not self-contained. Furthermore,
subsitemaps (and blocks in the future) can come with their own
datasources used locally. I'm not sure this is compatible with the
global declaration induced by JNDI.
- Write more tests (you knew this one was coming ;-) ).
Don't we have enough of them? :-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Plan] The future of Cocoon
Sylvain Wallez dijo: Personal note: your post made many people rush into my office saying What, what, deprecate XSP? He's crazy! ;-) lol. Just yesterday we had a little discussion about that in the office. We wonder why nobody commented about XSP deprecation! :-D We have 2 application running XSP. I think what Carsten thought is to let the XSP block live alone. No dependencies to it at all. Currently, there are many blocks requiring XSP just for samples and that is not good. Also you end up including the block even when the overall application don't use XSP at all. As a sample there is auth-fw and the session-fw. I am +1 to start cleaning XSP from the other blocks. Best Regards, Antonio Gallardo.
Re: [Plan] The future of Cocoon
Antonio Gallardo wrote:
Sylvain Wallez dijo:
Personal note: your post made many people rush into my office saying
What, what, deprecate XSP? He's crazy! ;-)
lol. Just yesterday we had a little discussion about that in the office.
We wonder why nobody commented about XSP deprecation! :-D
We have 2 application running XSP.
I think what Carsten thought is to let the XSP block live alone. No
dependencies to it at all. Currently, there are many blocks requiring XSP
just for samples and that is not good.
Hehe. Isn't it a good indicator that XSP is still well alive, even if
not the latest fashion?
Also you end up including the block even when the overall application don't use XSP at all. As a sample there is auth-fw and the session-fw.
Uh? Where does the need to include it come from? From samples?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [Plan] The future of Cocoon
Ah, btw, I added all points to a new document under planning/roadmap.xml.
So, feel free to update that doc as well.
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 4:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [Plan] The future of Cocoon
Ugo Cei wrote:
Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto:
Some things that come to my mind for 2.2:
- first finished version of CForms.
- deprecate XSP (and provide a viable alternative)
- cleaning up the caching/store mess
- remove deprecated blocks etc.
- Differentiate between blocks that provide a service to
other blocks
and blocks that contain just samples or small applications
built upon
cocoon (petstore, tour, linotpye). Maybe samples-only
blocks should
be a separate download.
+1
-Deprecate blocks that haven't been maintained in a long while or
don't serve any evident purpose. Web3, apples, python, php,
asciiart
come to mind. Maybe I'm wrong about some of them but I just want to
make a point, we can then decide on a case-by-case basis.
+1
- Review the implications and the implementation of pooling.
A big +1.
- Reduce unneeded dependencies on Avalon, where possible.
+1. Stated differently: introduce constructor and property dependency
injection.
- Review the logging framework. Log4j is the de-facto
standard and we
have blocks that complain if Log4j is not properly configured, so
let's accept it and stop reinventing the wheel.
See my answer to Carsten.
- Drop that Excalibur datasource. Components that need a DS
should get
one provided by the container via JNDI. If we don't have a
container
(running via the CLI, for instance), let the environment
provide one
and bind it to a JNDI namespace.
Mmmhh... defining the JNDI datasources is container-specific, and
therefore makes the applications not self-contained. Furthermore,
subsitemaps (and blocks in the future) can come with their own
datasources used locally. I'm not sure this is compatible with the
global declaration induced by JNDI.
- Write more tests (you knew this one was coming ;-) ).
Don't we have enough of them? :-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [Plan] The future of Cocoon
Antonio Gallardo wrote: lol. Just yesterday we had a little discussion about that in the office. We wonder why nobody commented about XSP deprecation! :-D Yepp, I did the same. Perhaps it's because most people only read the first two or three senctences of an email? :) We have 2 application running XSP. Good luck! I think what Carsten thought is to let the XSP block live alone. No dependencies to it at all. Currently, there are many blocks requiring XSP just for samples and that is not good. Also you end up including the block even when the overall application don't use XSP at all. As a sample there is auth-fw and the session-fw. I am +1 to start cleaning XSP from the other blocks. Yes, thanks, Antonio, this is imho an important point. Carsten
Re: [Plan] The future of Cocoon
Sylvain Wallez wrote: - Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the environment provide one and bind it to a JNDI namespace. Mmmhh... defining the JNDI datasources is container-specific, and therefore makes the applications not self-contained. Furthermore, subsitemaps (and blocks in the future) can come with their own datasources used locally. I'm not sure this is compatible with the global declaration induced by JNDI. Subsitemaps can define local datasources? Really? I tried to, in the past, but could never make this work. Now I'm not interested anymore, since I always use Hibernate and not XSP. Anyway, this request was inspired by this principle: If you're running in a J2EE environment, use it's features, don't reimplement them and by the desire to drop everything that is not strictly necessary. I must admit that this desire might not be common to everyone and the current situation has the advantage of being immediately usable by novices without knowing how to properly configure a J2EE container. So, I'll drop this for the moment. We already have lot of other things to do. Ugo
Re: [Plan] The future of Cocoon
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
-1: XSP has been moved to its own block meaning it's no more
core, but hundreds (if not thousands) or people are using
it on a daily basis. We can drive people towards new
techniques such as flow/jxtemplate, but cannot deprecate
what's has been a central part of Cocoon for so many years.
Personal note: your post made many people rush into my office
saying What, what, deprecate XSP? He's crazy! ;-)
Now they are calling me crazy - well... :)
Deprecating doesn't mean removing! by deprecating we show our users
that we think that there are better ways than XSP. And we show that
we are not developing this technique further (of course bug fixes
etc will be applied) That's all. We *can* than remove XSP in another
minor or major release, but we don't need to. So, this is just
a signal.
Before envisionning the deprecation of XSP (which I'm currently
against), we must ensure alternative technologies provide a similar
level of performance and those of the XSP features that are clean from
a MVC POV.
These criticisms are of course about JXTemplate:
- performance can be far better if we refactor it to remove the cascade
of if (event instanceof xxx) used to interpret the template.
- we need cacheable JXTemplates
- we need an equivalent to ESQL which is sooo cool to extract data from
a database.
Time for a featured JellyGenerator or TempoGenerator?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Plan] The future of Cocoon
On 27 May 2004, at 11:05, Carsten Ziegeler wrote: Yes, I think we should wait for the switch (next monday I think it was) and then continue. Kewl by me... BTW, I looked around, but do we have a clear layout on how we're going to organize our SVN repository? Pier smime.p7s Description: S/MIME cryptographic signature
Re: [Plan] The future of Cocoon
Ugo Cei wrote:
Sylvain Wallez wrote:
- Drop that Excalibur datasource. Components that need a DS should
get one provided by the container via JNDI. If we don't have a
container (running via the CLI, for instance), let the environment
provide one and bind it to a JNDI namespace.
Mmmhh... defining the JNDI datasources is container-specific, and
therefore makes the applications not self-contained. Furthermore,
subsitemaps (and blocks in the future) can come with their own
datasources used locally. I'm not sure this is compatible with the
global declaration induced by JNDI.
Subsitemaps can define local datasources? Really? I tried to, in the
past, but could never make this work. Now I'm not interested anymore,
since I always use Hibernate and not XSP.
map:components
datasources
jdbc name=local-ds
urljdbc:blah/url
/jdbc
/datasources
/map:components
Anyway, this request was inspired by this principle: If you're
running in a J2EE environment, use it's features, don't reimplement
them and by the desire to drop everything that is not strictly
necessary.
I must admit that this desire might not be common to everyone and the
current situation has the advantage of being immediately usable by
novices without knowing how to properly configure a J2EE container.
Exactly. And this goes back to what I said yesterday: many Cocoon users
aren't very skilled in J2EE techniques and having a self-contained
application is easier for them.
So, I'll drop this for the moment. We already have lot of other things
to do.
Yep :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [Plan] The future of Cocoon
Yes, Nicola suggested: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108556233024477w=2 Carsten -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED] Sent: Thursday, May 27, 2004 4:50 PM To: [EMAIL PROTECTED] Subject: Re: [Plan] The future of Cocoon On 27 May 2004, at 11:05, Carsten Ziegeler wrote: Yes, I think we should wait for the switch (next monday I think it was) and then continue. Kewl by me... BTW, I looked around, but do we have a clear layout on how we're going to organize our SVN repository? Pier
Re: [Plan] The future of Cocoon
On Thu, May 27, 2004 at 04:54:54PM +0200, Sylvain Wallez wrote: Ugo Cei wrote: Sylvain Wallez wrote: - Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the environment provide one and bind it to a JNDI namespace. Mmmhh... defining the JNDI datasources is container-specific, and therefore makes the applications not self-contained. Furthermore, subsitemaps (and blocks in the future) can come with their own datasources used locally. I'm not sure this is compatible with the global declaration induced by JNDI. Subsitemaps can define local datasources? Really? I tried to, in the past, but could never make this work. Now I'm not interested anymore, since I always use Hibernate and not XSP. map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components WOW SHIT ! :) Couldn't express it better. Right now I am also using Hibernate but at my XSP times when XConfToolTask was too much for me, configuring cocoon.xconf by hand everytime I upgraded was a real nightmare. Is it possible to place custom Avalon components here also ? LG PS. cocoon really needs more documentation -- __ | / \ |Leszek Gawron// \\ \_\\ //_/ [EMAIL PROTECTED] _\\()//_ .'/()\'. Phone: +48(501)720812 / // \\ \ \\ // recursive: adj; see recursive | \__/ |
RE: [Plan] The future of Cocoon
Sylvain Wallez wrote: Before envisionning the deprecation of XSP (which I'm currently against), we must ensure alternative technologies provide a similar level of performance and those of the XSP features that are clean from a MVC POV. Sure. We can only deprecate something if we have an alternative. These criticisms are of course about JXTemplate: - performance can be far better if we refactor it to remove the cascade of if (event instanceof xxx) used to interpret the template. - we need cacheable JXTemplates - we need an equivalent to ESQL which is sooo cool to extract data from a database. Time for a featured JellyGenerator or TempoGenerator? Hey, don't spoil my RT :) Yes, there are only a few things to tackle before my TempoGenerator can fully replace our jx template one. Some things already work :) I'm planning to put up an RT on this, so we can then discuss this in a separate thread. But I think most of your points are already taken into account. Carsten
Re: [Plan] The future of Cocoon
Sylvain Wallez wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components Ouch! I had this need one and a half year ago [1] and couldn't satisfy it. Don't remember what I did and why it didn't work, and now that I have a solution, I don't need it anymore. Ugo [1] http://beblogging.com/blog/2002/11/21/195906
Re: [Plan] The future of Cocoon
Sylvain Wallez wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components Ouch! I had this need one and a half year ago [1] and couldn't satisfy it. Don't remember what I did and why it didn't work, and now that I have a solution, I don't need it anymore. Ugo [1] http://beblogging.com/blog/2002/11/21/195906
RE: [Plan] The future of Cocoon
Leszek Gawron wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components WOW SHIT ! :) Couldn't express it better. Right now I am also using Hibernate but at my XSP times when XConfToolTask was too much for me, configuring cocoon.xconf by hand everytime I upgraded was a real nightmare. Don't want to spoil the party here, but this is imho not a guaranteed feature of the sitemap. It works now, but never was intended to be possible. It accidentally sneaked into the code :( We *can* make this officially but this requires a vote. For example, the new tree processor orginally written for 2.2 (using Fortress) did imho not support this. Carsten
Re: [Plan] The future of Cocoon
Carsten Ziegeler wrote:
Leszek Gawron wrote:
map:components
datasources
jdbc name=local-ds
urljdbc:blah/url
/jdbc
/datasources
/map:components
WOW SHIT ! :)
Couldn't express it better. Right now I am also using
Hibernate but at my XSP times when XConfToolTask was too much
for me, configuring cocoon.xconf by hand everytime I upgraded
was a real nightmare.
Don't want to spoil the party here, but this is imho not a guaranteed
feature of the sitemap. It works now, but never was intended to be
possible. It accidentally sneaked into the code :(
You're absolutely right, Carsten. This wasn't possible with the compiled
sitemap engine, and is possible - although not official - with the
TreeProcessor because map:components in a sitemap is handled exactly
as cocoon in cocoon.xconf.
Hence, any component declaration can be add there. Selectors also
inherit their parent components, meaning in my example we add a
datasource, but any datasource defined in cocoon.xconf or even parent
sitemaps are available.
We *can* make this officially but this requires a vote. For example, the new tree processor orginally written for 2.2 (using Fortress) did imho not support this.
Don't know if it does support it now, but adding it would be IMO fairly
easy.
Now I'm all of course for making this official, furthermore considering
that blocks will need more than just sitemap components.
Ready to start a vote?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Plan] The future of Cocoon
On Thu, May 27, 2004 at 07:40:19PM +0200, Sylvain Wallez wrote: Carsten Ziegeler wrote: Leszek Gawron wrote: map:components datasources jdbc name=local-ds urljdbc:blah/url /jdbc /datasources /map:components I just tried this and could not make it work :( Even tried changing url to dburl. Trying to get a connection from flowscript it could only find datasources defined in cocoon.xconf, not in my sitemaps. Maybe I am just too excited to figure this out ;) You're absolutely right, Carsten. This wasn't possible with the compiled sitemap engine, and is possible - although not official - with the TreeProcessor because map:components in a sitemap is handled exactly as cocoon in cocoon.xconf. Hence, any component declaration can be add there. Selectors also inherit their parent components, meaning in my example we add a datasource, but any datasource defined in cocoon.xconf or even parent sitemaps are available. We *can* make this officially but this requires a vote. For example, the new tree processor orginally written for 2.2 (using Fortress) did imho not support this. Don't know if it does support it now, but adding it would be IMO fairly easy. Now I'm all of course for making this official, furthermore considering that blocks will need more than just sitemap components. Ready to start a vote? Early +1 because I like the idea of not having to restart Cocoon for every cocoon.xconf change. IIUC, if we can move some things into the top sitemap, we can be more modular, and change configs without restarting. --Tim Larson
Re: [Plan] The future of Cocoon
Tim Larson wrote: We *can* make this officially but this requires a vote. For example, the new tree processor orginally written for 2.2 (using Fortress) did imho not support this. Don't know if it does support it now, but adding it would be IMO fairly easy. Now I'm all of course for making this official, furthermore considering that blocks will need more than just sitemap components. Ready to start a vote? Early +1 because I like the idea of not having to restart Cocoon for every cocoon.xconf change. IIUC, if we can move some things into the top sitemap, we can be more modular, and change configs without restarting. This indeed would be wonderful. I happened to have it on my plate to figure out how to add or change datasource configurations at runtime. --Greg Weinger
Re: [Plan] The future of Cocoon
Carsten Ziegeler wrote: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. All request's named how should I implement that? finish at use flow + forms + O/R mapping tool while there is still no direct support for nor Hibernate neither OJB in cocoon. I have some useful code and examples for Hibernate I am not able to contribute because of the licensing issues. Hugo offered some help with cocoondev.org hosting of non ASF stuff but I think he's busy lately because he does not return e-mails. I use Hibernate via open session in view pattern while I think it would be really great if cocoon supported it via some component (I'll start another thread about hibernate support in near future). Leszek Gawron
Re: [Plan] The future of Cocoon
Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto: Some things that come to my mind for 2.2: - first finished version of CForms. - deprecate XSP (and provide a viable alternative) - cleaning up the caching/store mess - remove deprecated blocks etc. - Differentiate between blocks that provide a service to other blocks and blocks that contain just samples or small applications built upon cocoon (petstore, tour, linotpye). Maybe samples-only blocks should be a separate download. -Deprecate blocks that haven't been maintained in a long while or don't serve any evident purpose. Web3, apples, python, php, asciiart come to mind. Maybe I'm wrong about some of them but I just want to make a point, we can then decide on a case-by-case basis. - Review the implications and the implementation of pooling. - Reduce unneeded dependencies on Avalon, where possible. - Review the logging framework. Log4j is the de-facto standard and we have blocks that complain if Log4j is not properly configured, so let's accept it and stop reinventing the wheel. - Drop that Excalibur datasource. Components that need a DS should get one provided by the container via JNDI. If we don't have a container (running via the CLI, for instance), let the environment provide one and bind it to a JNDI namespace. - Write more tests (you knew this one was coming ;-) ). Fire at will, Ugo -- Ugo Cei - http://beblogging.com/
