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...
IIUC your example is heaviliy based on XSLT and the fact that flowsript is interpreted rather than compiled.
Do you think you can encapsulate that behind an interface like this? -setState(doc, requestedState, user, optionalObject) -getState(doc) -getAllowedActions(doc, user)
IIRC some time ago you had/have a project describing page flow with XSLT rather than flowscript, stating that flowscript in some cases (like extremely complex page flows) being too limited and XSLT being a superior approach. TBH I remember me reasonating to a certain extend. However now that flowscript is available and of common use, I guess there are not many people looking back. And I think that simply is because it's so simple to use (and flexible at the same time). XSLT has been always there - just being too difficult to come up with an approach generic and simple enough to be widely used.
Although I'm unsure (and would be happy being proved wrong) I don't believe (this time :-) that such an approach would be flexible enough to acommodate all thinkable needs.
Again, I remember a lot of people (not only on this list) talking about visually designing page flow. I don't know a single effective (and still flexible enough) approach. Workflow may be a different beast than page flow but no matter what, it should be simple to be used and therefore prefer a bottom-up approach (growing from simple use cases while providing hooks for more complex ones) rather than an universal one-size-catches-all design.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------