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]> 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.
