cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Tue, 26 Nov 2002 21:32:30 GMT
Hunsberger, Peter wrote:

>>To be entirely honest with you, I already did this redesign in my head 
>>when I was thinking about how to separate the flow logic from the 
>>sitemap and trying to get rid of actions. I started to think about wild 
>>alternatives, but couldn't find any.
> Well, now you have one....  ;-)

True but I'm not sure I have the time right now (I'm doing a bazillion 
stuff these days, mostly partying with Jon... more on this later) to 
give it a well deserved deep architectural screening from my side. :(

> <snip/>
>>>Personally, I find the sitemap a pretty complex beast that attempts to 
>>>do a awful lot of independent things; separation of flow is a step 
>>>towards breaking this out, but the discussion seems to be centering on 
>>>how to implement two languages simultaneously within the sitemap just 
>>>so one can cleanly separate the business logic from the flow logic.
>>?? sorry, I don't get this. The business logic should reside in java 
>>objects that you write or reuse from the external, I see it like this
>>  resource production logic -> sitemap (declarative)
>>  flow logic -> flowscript (procedural)
>>  business logic -> custom java objects (procedural)
>>and I think this is very clean.
> Well, yes mostly it is, but we have a requirement for very dynamic business
> logic and very dynamic flow logic.  As a result, I'd like to keep as much of
> the logic declarative (specifically, coded in XSLT) as possible.  We really
> need to mix and match business rules, business flow, presentation flow and
> presentation logic on the fly according to a pretty complex set of rules.
> Using XSLT allows us to stay much closer to a rules evaluation model and
> avoid what would otherwise be very complex Java code.  

 From what I read, when you talk about "XSLT" in this context, you are 
talking about a declarative finite state machine approach that has 
nothing to do with tree transformations. So I would suggest you stop 
calling it XSLT or people might get confused about what you are proposing.

The history of computer science showed (after decades of research) that 
procedural and declarative approaches are computationally equivalent. 
For example, it is entirely possible write the same logic in prolog 
(declarative) or pascal (procedural).

Obviously, depending on the logic (and on the programming skills of the 
person writing the code!) the energy used to implement the logic using 
the two approaches varies a lot.

Now, after long reasoning, we came to the conclusion that, given the 
intrinsic declarative nature of the web (being a IoC-based 
architecture), a declarative approach to web resource generation was the 
best choice. Thus the sitemap.

Later we found out that it mixed concerns between flow logic and 
resource production logic.

At this point, we needed to find a way not only to extract this 
information from the sitemap (to separate concerns) but also to make it 
as easy as possible to write it and maintain it.

The first approach followed the FSM model: the model followed the way 
the web is perceived from the webapp developers: a set of states (the 
resources) and a set of transitions between states. The best description 
of a FMS is of declarative nature.

Now, there is no agreement (and will never be) about this, but when 
Edsger W. Dijkstra wrote "Go To Statement Considered Harmful" (read it 
from it created a massive change in 
how high-level languages are described.

I won't go as far as stating that FSM for flow description can be 
considered harmful, but my reasoning is that most of the programmers 
nowadays are used to procedural programming because that's what they 
grew up with (even if declarativeness is more human friendly for 

But anyway, the concept goes down to earth: it is easier to write and 
maintain a FSM or a command line application?

It depends, I hear you say. And you're right.

But it's definately easier to know people that can read say java or C or 
python than can read prolog or lisp or scheme.

Now, XSLT (which is an XML version of DSSSL, which was considered a 
scheme dialect) changes the picture somewhat, even if everybody knows 
how hard it is to find good XSLT-ists, expecially those being able to 
read hardcore XSLT stylesheets (like James Clark's or Norman Walsh's, 
for example).

But I agree that a declarative (or FSM-like) approach to flow 
description is appealing for some cases (like simple workflow engines, 
for example) and this is the reason why I figured that having a way to 
use the cocoon pipelines to "transform" a declarative workflow 
description into a procedural flow description might be appealing and 
architecturally elegant.

True: the complexity of the workflow->flow transformation sheet will be 
pretty big (and we have already decided to stay away from that for the 
sitemap, so I do have some concerns about this approach) but it could 
allow us an *incremental* approach to the search for other ways to 
describe flows. (which was the value of the compiled sitemap 


> I'm not quite sure why you would see procedural logic as being "better"?
> Again, we're coming at this from a rules based approach and as such XSLT
> seems like a more natural fit...

Agreed. 'better' is the wrong term. Let me use the term 'more natural to 
programmers nowadays'. I see three ways of implementing this:

  1) procedural engine and declarative adaptation
  2) declerative engine and procedural adaptation
  3) two separate engines

the first is the one I'm advocating.

for the second, I worry that it will be harder to find people that 
understand what cocoon is doing and this slows down the community building

for the third, I think nobody will stop people from implementing and 
proposing alternative flow engines.

NOTE: the <map:flow> element might need a language="" attribute to 
identify which flow engine to use.

>>But I really don't see any need to go back and refactor the 
>>sitemap+flowscript concept which is, IMO, great.
> Not having had a chance to get my hands dirty with it I can't comment on
> that.  If I may, let me give two example problems that we have, one simple,
> one not so simple and perhaps someone who has had a chance to play with this
> more can explain how flowscript would work with them?


> 1) Presentation flow use case: user has a search screen, search presents a
> list of results, user picks from a list of results and sees the details of a
> given item.  In the case that the search produces only a single result you
> want to jump directly to the details screen and skip the pick list. (Just
> for argument lets say that the two presentation required is complex enough
> that you really don't want to do all presentation from a single XSLT.)  
> With an XSLT template style matcher this is a simple count() of the data
> results picking the resultant presentation transform to apply.  I suspect
> this is pretty trivial for the flowscript model also?

The above is trivial for the sitemap without even having to use flow. 
Just write your URI space so that

  /results -> list of results

  /result(*) -> show result {1}

and the count can be done with a stylesheet or with a parameter to a 
custom generator or with anything you like.

Flow emerges with roundtripping: that is the use of subsequent GET and 
POST http actions. If you go around 'asking for pages' with GET, there 
is absolute no need to specifiy any flow whatsoever, a pure sitemap 
approach is still great.

> 2) Work flow mapping use case:  item requisition document presented as a
> fill in the blanks form.  User does a "Submit for approval".  Business rules
> are such that if user is level X or above and request is for amount Y or
> less it is automatically sent to purchasing, otherwise it is sent to users
> boss for approval before being sent to purchasing. Boss and purchasing both
> need to be presented with screens giving items waiting for approval and be
> able to approve, not approve as appropriate and route documents on as
> appropriate.

Yeah, basic workflow system

> As described, this second is perhaps easier to code as procedural code.


> However, it gets really interesting when the flow has to cross business
> organization boundaries.  Process modeling languages such as BPEL4WS start
> to come into play and one ends up wanting to have a general XML model for
> describing the problem whether internal or extranet related.  This doesn't
> force you into a XSLT processing mode (for the process modeling language) as
> a result, but it seems natural to me?

Have you ever tried? Did you ever estimated the maintenance costs of 
such an approach (compared to a scripting procedural description) based 
on your working environment?

I'm pretty sure that tool vendors will have XML-exporting of their 
workflow descriptions, but that doesn't necessarely mean that those XML 
description will be easy read or cheap to maintain/evolve.

moreover, I think it makes sense to 'adapt' those xml descriptions into 
something that can be directly executed from Cocoon and this is why I 
think it would be nice to have a way to come up with cocoon-generated 
flowscripts even if, at first, it seems like FS even to me.

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message