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 Mon, 15 Mar 2004 16:20:42 GMT
Guido Casper <gcasper@s-und-n.de> writes:

> 
> Hunsberger, Peter wrote:
> > 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...
> 
> IIUC your example is heaviliy based on XSLT and the fact that 
> flowsript 
> is interpreted rather than compiled.

Yes, though with the compiling class loader, being interpreted wouldn't
really be an issue....

> 
> Do you think you can encapsulate that behind an interface 
> like this? -setState(doc, requestedState, user, optionalObject)
> -getState(doc)
> -getAllowedActions(doc, user)
> 

I was trying to figure that out myself.  I guess the main question I
have is where are these interfaces going to be defined?  If they are
part of flow, then sure: have a function that calls a pipeline and
returns a JS object with these methods attached to it.  

However, I got the impression that not everyone wanted to depend on
flow.  If this is some abstract object that gets tossed to some generic
action handler that would also likely work, in particular, since once
you have that you can wrap it for flow and make both camps happy?

> 
> 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.
 
Well, I don't think it's fair to say XSLT has always been there.  There
currently isn't any out of the box solution for writing flow controllers
with XSLT (for Cocoon or anywhere else that I am aware of).  As such, I
don't think you can say it's not generic or simple.  I think such a
beast could be made completely generic.  However, I also believe that it
wouldn't be simple....

> 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.

Well, given that XSLT is Turing complete I can't imagine what would be
missing?  Such an approach is definitely flexible: it allows for
declarative state control if you want it, and it allows for declarative
rules evaluation if you want that instead.  Given that it can also be
used as the input to generate procedural code, you've basically got all
three worlds?

> 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.

<long-winded-mode>

I don't believe that you are ever going to find a "simple to use" work
flow solution that is also flexible and capable of being used
generically.  Workflow modeling isn't mind boggling complex, but
generally, the people doing it aren't CS majors; they are business
analysts and end users.  Work flow is where flow meets the business.  To
draw an analogy; work flow modeling is for Time like what semantic,
logical and physical modeling is for Data.  You can usually get people
to understand semantics, finding business people that can build you a
good logical ERD is a lot harder.  Getting business people to buy off on
3rd (least of all 5th) normal form physical models is 90% of the time
hopeless.

The same holds true for work flow: a business person can describe the
semantics of document handling just fine.  They can probably give you a
flow chart (maybe even a swim stream flow chart) to describe the work
flow.  Don't expect them to write out provable state logic for you
(least of XSLT rules ;-).

The saving grace is that you don't need to include work flow modeling
capabilities in Cocoon any more than you need to include data modeling
in Cocoon.  What you need is some way to integrate with the models; the
work-flow equivalent of JDO, JDBC and maybe even eventually XQuery.

Asking for a simple bottom up approach for work flow is like asking for
a simple bottom up JDO or XQuery for data.  The usefulness of such a
thing for the general Cocoon community is just about nil; it's just too
big and diverse of community.  (Having said that, I'm the first to admit
that our use cases fall on the far extreme edge of complex compared to
what most people have to do.  I've never seen another project like this
one in my 20+ years of IT and that includes one that was over 500 Person
years of effort.)

</long-winded-mode>

<expanded proposal>

I believe what we need is some way to accommodate everyone, so my
proposal is simply:

1) a flow enabled engine that people can write flow script for directly.
This needs a well defined set of interfaces, probably similar to what is
being proposed for the work flow API;

2) *additionally* some way (Cocoon approved interface) to persist and
retrieve flow-script dynamically to feed it into the above flow engine.

This allows you to wrap a workflow controller (be it state model or
otherwise) around a bunch of Cocoon flows.  People that want to use
state models just write select block like implemetations for the flow
functions.  People that want more, write procedural logic.  For people
like me, we write a way to dynamically produce the flow logic in step 2)
from XML via XSLT to text transforms when the flow retrieve functions
are called.

This suggest that basically what you need for 2) is the ability to
generate a flow script file/object from a pipeline on the fly.  If
you've got that, then you've got everything you need: the source can be
a Reader or it can be a complex pipeline.

This still leaves out the non-flow script people, but frankly I'm not
sure what to do for them?  I guess if they can access 2) from an action
they have the components to build what they want, but darned if I know
what the actual implementation looks like; probably compiling class
loader and flow components coded in Java?

</expanded proposal>


Mime
View raw message