cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Flow wishlist :)
Date Mon, 25 Nov 2002 16:47:04 GMT
> hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in my 
> head, but I have several great examples of where having that would rock 
> the planet.... but still, I'm afraid of people going back adding 
> programmatical logic to the sitemap....
> ... but it would be *so* cool to have a Workflow definition language 
> created as markup and then having a pipeline that generates the 
> flowscript by XSLT transformation!

I've been exploring the ability to define flow via XSLT and parsed markup
for some time now. I've a conceptual design in my head so far, but it is
very different from what exists in Cocoon so far, and different from
generating flowscript:  it seems to me that the essential requirement here
is just to be able to drive Cocoon via XSLT parsing of the current context
(request, session, etc. as the user sees fit).  As such, you're talking
about a pluggable replacement for the entire sitemap handler it's really a
very different processing model from the current sitemap.  

I think another way to understand it is as though one was adding the
equivalent of XSLT chaining to the XSLT language:  process this DOM/SAX
stream up to this point; make a decision on what to chain in next and hand
the whole thing over to some subsequent transform/serialization process that
inherits the processed stream as it's starting point.  This is different
from included XSLT templates since each sequence of chained transforms
begins as though it was starting fresh from the other (no name collision).
It's different from the current Cocoon sitemap (but functionally equivalent)
since it allows an XSLT to make the decisions instead of the Sitemap.  The
appeal to me is that such a design is consistent with the functional
programming model of XML/XSLT...

> I know, I know, it smells of FS all around, but this would make it *so* 
> easy to be able to connect cocoon to existing workflow editing systems.
> Gosh, I have to think about that.
> What do you people think?

This is an important piece to the future of Cocoon. My personal functional
requirements are to stay within the XML/XSLT processing model as much as
possible and not design a new language (a Sitemap language), and not require
the use of compiled code (Java).  I don't know if others would think these
are reasonable requirements or not, but if you see the value of such then I
think it seems to suggest a very different Cocoon model then the current
sitemap.  As such, I think it might be worth exploring what happens if you
throw the current model up in the air and do some design work from scratch:
if we didn't have site maps, knowing what we know now, how would we get all
this functionality?  If that matches up with sitemaps, flow, etc. fine then
add in the new syntax to support it.  However, if it's a new way of doing
things then it at least has to wait for blocks to be implemented, and more
likely it's a Cocoon 2.5 or 3.0 type of thing...

To unsubscribe, e-mail:
For additional commands, email:

View raw message