Re: [CRAZY IDEA] sitemaps in javascript

[Antonio Gallardo <ag...@agssa.net>]

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.

Re: [CRAZY IDEA] sitemaps in javascript

[Daniel Fagerstrom <da...@nada.kth.se>]

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* <agallardo@agssa.net 
> <ma...@agssa.net>> 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.
> 
> 

Re: [CRAZY IDEA] sitemaps in javascript

[Peter Hunsberger <pe...@gmail.com>]

On 2/27/06, Irv Salisbury <ir...@gmail.com> wrote:
> 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)

I've just got to ask why you've got such a large amount of stuff going
into the sitemap?  Is there no back end database that can be used for
configuration data once you've got the basic flow mapped out?

We tend to use the sitemap at a very high level, only _major_
constructs have their own entries and these serve as generic entry
points for the finer grained subcomponents based on them.  This way,
even without a back end database you can avoid having to configure
everything in the sitemap.  For example, we may have a matcher on
things like:

foo/*.display
foo/*.edit
foo/*.list
foo/*.grid

where display, edit, list and grid are main screen types.  A generic
generator then picks up the wild card pattern and uses it to
effectively pick subclasses for these types (not necessarily
literally, but you should get the idea?).  Normal query parameters or
whatever then do specific page selection and configure the resultant
page more precisely.

In our case we're currently have 12 or so generators that build 1000's
of different screens.  The main reason for even having this many
generators is that they map to major orthogonal slices of the
application (eg. validation, or page generation, or system wide data
or authentication data) that have very different usage and caching
patterns.  In theory we'll eventually cut this number in half as we
find the more general patterns of usage.  We have 3 action handlers,
one of which is used just for parameter forwarding, one for
authentication and one for everything else...  There's a single
reader, a couple of modules, and 30 or so XSLT.  We've still got a
1000 line sitemap, but probably about a 1/4 of that is for testing
purposes and another 1/4 of it can eventually disappear as we refine
things even further.

<snip/>

--
Peter Hunsberger

Re: [CRAZY IDEA] sitemaps in javascript

[Irv Salisbury <ir...@gmail.com>]

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 <ag...@agssa.net> 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.
>
>