cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 21:28:15 GMT
Leo Sutic <> writes:

> So what about this rule-based flow processor? I think you're 
> attacking the wrong problem. Before we ask ourselves whether 
> it should be allowed in Cocoon, we have to ask ourselves what 
> problem it solves that can't be solved with the current flow. 
> Otherwise we get it completely backwards.

I think I've touched on that a little already, but to make it explicit
once more: we will have 1000's of URLs to map.  We are developing tools
to allow our Business Analysts to map flows and keeping developers out
of the loop.  This isn't a complete answer to your question, but I
simply don't have the time to get into specifics at the moment.
> Whoever wrote the rule based flow did so to solve a problem. 
> But if we start talking about whether to adopt the rule-flow 
> before we start talking about the problem that prompted its 
> creation, then we're locking ourselves 
> into one solution - the rule-flow.

1) I'm not asking anyone to adopt rule based flow.  I'm asking for a way
for me to be able to plug in rule based flow without having to modify

2) I'm certainly not advocating rule based flow over JavaScript Flow.

> Do you see *why* this is backwards?
> A solution has been presented: The rule based flow processor. 
> But (1) what is the problem it solves? And (2) why do we need 
> the rule based flow processor to solve it?
> Once (1) has been made clear, perhaps we find that it can be 
> solved with the current flow processor. Then we can do so and 
> save ourselves a lot of code maintenance. So you'll get what 
> you need (a solution to the basic problem), but not what you 
> want (a rule based flow processor).
For this particular set of problems there is no way we are going to
write JavaScript based flow by hand.  As Stephano and I discussed last
November there may be a way of generating JavaScript flow from our XML
descriptions, but I don't have enough experience to know if that's
possible yet.  The BPEL4WS spec is huge (95 pages in v1.0 and that
doesn't get into a lot of specifics).  Our subset will be small in
comparison but still pretty complex. 

> Hunsberger, Peter wrote:
> > As I discussed with you when the flow sitemap integration 
> discussions
> > where in full swing I do have a long term agenda (XSLT 
> managed flow) 
> > and I would like to see a way of including it in Cocoon without 
> > breaking existing functionality...
> This is the wrong approach.
> Peter, you don't want XSLT managed flow. What you want is a 
> solution to the problem that you have decided that XSLT 
> managed flow is a 
> solution for. (Did you follow me there?)

I don't know why you presume to know what we want?  It's not XSLT based
flow specifically, it's rule based flow and it's a different than
JavaScript based flow. This isn't something that has appeared out of the
blue.  I've discussed it on the list many times.  The theory behind it
is very different from what most developers run into most of the time,
but it's well established within the realms of Computer Science and the
problem domains it is useful in is well understood (within the circles
that it is applied).  I simply don't have time to rehash it once more.

> You have a problem. You think that XSLT managed flow is a 
> solution. You therefore try to get XSLT managed flow into Cocoon.
> Instead:
> You have a problem. Explain it. Say that XSLT managed flow is 
> *one* possible solution. Maybe we can find a one-line change 
> in Cocoon that will solve your problem without adding a whole 
> flow implementation.
> Isn't that better?
> You get what you need (a solution) but not what you want 
> (XSLT managed 
> flow). And we avoid adding yet another implementation of core 
> services.

Go back to last Novembers discussions on this issue.  We went through
this entire issue at that time. At that point Stephano felt the hooks we
needed would probably end up in Cocoon. It's not so clear that they will
anymore, or if they do that the semantics will be very generalized.  I'm
not asking for additional core services.  I'm (more-or-less) asking for
ways to treat flow as a generalized component.

I'm not asking anyone to change the way JavaScript flow works, I'm just
supporting Sylvain and Marc's position that there should be ways to hook
other alternatives in and providing an existing use case that
demonstrates there are other alternatives (lest anyone think that they
are the only ones with the need).  


View raw message