Much of what you asking for is on its way and there is plenty of room
for contributions ;)
Sitemap inheritance (or actually servlet inheritance), is part of the
block architecture and implemented nearly a year ago. The blocks
architecture still need some polishing before its ready for prime time,
but we are not that far away.
With the blocks architecture the sitemap doesn't need to be the "main"
controller anymore. It will be possible to have e.g. a flowscript
controller (or any servlet) as the main controller instead. It could be
implemented and integrated right away if someone is interested to work
on it.
For aggregation and content based routing, pull pipelines are superior.
Axis2 have already developed much of the infrastructure that is needed.
Sylvain started to look on how to integrate that in Cocoon during ther
last ApacheCon. Pull pipelines also would make a huge difference in
performance for work with huge XML documents from e.g. data bases.
In short, there are some really interesting projects to work on for
those who are interested :)
/Daniel
Irv Salisbury skrev:
I have to admit that the cocoon sitemaps we use for our projects have
gotten out of hand. If a new person started working on it, they would
need a sitemap for the sitemaps. Because of the common stuff we want to
do across projects, we actually start with sitemap xml snippets that we
include with DTD includes. (Yes I know it is ugly but the best we could
come up with for common sitemap stuff without true includes)
Now, once you get past that, there are a ton of common resource calls
with parameters. Each of these uses aggregation and the cinclude
transformer. The cinclude transformer of course has calls to cocoon://
pipelines. So, now the spaghetti starts getting nasty. All of this is
in the name of reuse and without having true inheritance and an easy
aggregation mechanism, we have had to do these things.
Add in the mix of flowscript and you really have a nightmare on your
hands. We have tried to keep to rules of what goes where, but somebody
new coming onto our project would need at least a couple weeks and a
roadmap to find their way around.
Having a nice, clean include mechanism and an easy inline way of doing
aggregation, coupled with the ability to do easy content based routing
(yeah don't get me started on that one) and our sitemap would be a LOT
cleaner. We accomplish content based routing by using XMLBeans, calling
a pipeline that fills up the bean in flowscript, checking the values,
then calling the appropriate other pipelines. The back and forth of
this is pretty nasty.
So, I would wholeheartedly agree that either javascript or java (my
preference) for a sitemap language would be great. To offer the
possiblity of not having to pass XML through the pipeline would be even
better. For performance reasons, if I could just manipulate java (using
hibernate or the like) the only go to XML for the final step is great.
This can be accomplished somewhat with the current system, but you still
have to go back and forth from flowscript to sitemap, and get all the
yuck with that.
Irv
On 2/1/06, *Antonio Gallardo* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Sylvain Wallez wrote:
> Experience showed that the sitemap language is actually very simple,
> and that people quickly find it more productive to write their
sitemap
> with a content-assist editor. In this regard, the WebTools XML
editor
> auto-learning feature does quite a good job once a sitemap contains
> one instance of each of the base instructions (match, generate,
> transform, etc).
Here a fully commented schema for all the cocoon special files will
help
a lot for newbies.
>
> Now, to speak clearly, I'm thinking about closing Lepido at Eclipse,
> first because for a number of reasons on which I could expand it
> didn't attract people, and because the future of Cocoon is so
unclear
> to me that investing in the development of a tool that may quickly be
> obsolete looks like wasted energy.
Wow! :-(
I installed Lepido. I wanted to reach you sometimes to speak about the
Lepido future and how to start working on it.
Best Regards,
Antonio Gallardo.
