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.
I was more thinking of Avalon components. That would mean if you need a hook to call a pipeline generated JS object that hook would need to be created (instead of using the one from the flow layer - hope I'm making sense :-).
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....
OK.
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?
OK. TBH I don't know exactly what "Turing complete" means and I don't think I can build such a thing with XSLT.
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.
AFAICS JDO and XQuery _have_ been created bottom up (the same is true for JDBC). Neither would be there without 20 years of SQL (and other database) experience (and the way JDO was born was eagerly debated - to say the least). I don't think JDO fits each and every problem already being effectively solved with plain SQL before (I want my workflow engine "talk SQL" :-).
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,
Here I think we disagree. <skip-elaboration/> :-)
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;
Yes, it might be just a first step and the basis for futher evolution. But it might very well already be a solution for a bunch of problems.
2) *additionally* some way (Cocoon approved interface) to persist and retrieve flow-script dynamically to feed it into the above flow engine.
Yes, it certainly might be a nice workflow implementation to have.
Guido
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>
-- 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 -------------------------------------------------
