Hunsberger, Peter wrote:
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. :(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.... ;-)
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.<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.
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 http://www.acm.org/classics/oct95/) 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 non-programmers)
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 implementation).
[snip]
Agreed. 'better' is the wrong term. Let me use the term 'more natural to programmers nowadays'. I see three ways of implementing this: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...
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?
Fair.
1) Presentation flow use case: user has a search screen, search presents aThe above is trivial for the sitemap without even having to use flow. Just write your URI space so that
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?
/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.
Bingo.
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?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?
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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
