cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Experience with workflow at Hippo Webworks
Date Tue, 09 Mar 2004 21:04:25 GMT
Guido Casper <gcasper@s-und-n.de> writes:

> 
> Hunsberger, Peter wrote:
> > However, on the
> > Cocoon side it's not the GUI I'm worried about, it's the underlying
> > engine.   There may still be value in one of the other 
> projects, but I'm
> > personally after very tight integration with Cocoon flow...
> 
> Ah, OK, I'm still not getting how that might work :-)

Well, in theory (not having a specific other project to shoot at), one
possibility might be:

1 - a GUI design tool would create an XML description of a work flow;

2 - the XML would be stored into a repository accessible to Cocoon;

3 - some generic Cocoon generator would be extended for a specific
application implementation to spit out instance specific XML for a given
"document";

4 - some generic Cocoon XSLT would take the data from steps 2 and 3 and
combine them to spit out some instance specific Flowscript.

The magic in this scenario is step 3, I know how to do this for our
specific implementation, but I'm not quite sure I can make the leap to
anything generic.

There are other ways of trying to attack this, but let me just throw
this one out for the moment as a straw man...



Mime
View raw message