Hunsberger, Peter wrote:
You're welcome. There is much more to learn when somebody is against my ideas than when people agree with me. :-DStefano, thanks for taking the time to reply in detail.
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.
why not? all optimized search engines save your results in cache so that they don't have to redo the query every time.<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...???
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
