cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Wed, 27 Nov 2002 02:41:17 GMT
Hunsberger, Peter wrote:
> Stefano, thanks for taking the time to reply in detail.

You're welcome. There is much more to learn when somebody is against my 
ideas than when people agree with me. :-D

> I'm going to snip
> most of the discussion to keep this somewhat terse, but do have a couple of
> further comments...
> <small snip >
>>>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.
> Well, no;  I'm proposing using XSLT to implement a parser that invokes
> subsequent transforms....  

Then I'm totally lost. Please, explain more on this.

> The input tree is built up in the standard Cocoon
> ways, and serves as the input for the decision tree.  The XSLT implements
> the rules that run over this data to determine what subsequent transform to
> invoke.  (One ends up transforming current context into new context plus new
> transform.)

Yeah, I'm definately lost.

> <big snip on historical intro/>
>>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.
> You forgot Haskell :-)
>>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).
> I think we're pretty much in agreement.  The biggest issue I see is that
> even though it's hard to find good functional programmers its probably just
> as hard to get developers who can write easy to understand rules handling
> engines in Java (or JavaScript).  Thus, for us there isn't much choice, this
> is going to get messy either way.  

Good point.

> <medium sized snip/>
>>>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.
> Understandable, but what seems at odds with this, is that eventually, Cocoon
> is going to run a transform of some form.  Now it may be that XSP allows it
> not to really be a functional model, but if one wants to stay pure to the
> XML/XSLT model then anyone that uses Cocoon is sooner or later going to have
> at least some understanding of functional programming?

Another good point.

>>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.
> Yes, and if blocks gets done properly there should be nothing to stop one
> from implementing extensions to the sitemap handler in a modular way. :-)

well, I don't know about htat.

> <small snip/>
>>>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.
> The multiple/single results are in response to a POST of the search form
> input...??? 

why not? all optimized search engines save your results in cache so that 
they don't have to redo the query every time.

Stefano Mazzocchi                               <>

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

View raw message