cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [CRAZY IDEA] sitemaps in javascript
Date Tue, 28 Feb 2006 20:53:05 GMT
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 :)


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

View raw message