Guido Casper <[EMAIL PROTECTED]> 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...
