Guido Casper <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote: > > 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.
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>
