Hi again...
<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.
Hmm, I guess I've been exploring this long enough that I thought it was
somewhat intuitively obvious, sorry... (Someone has also remarked that this
sounded somewhat like a capability that was in C1.)
I'll skip the background for all this, but basically our requirements are a
bit extreme; 1000's of variations on 100's of UI "screens"; each UI
variation can change over time, and it must be possible to audit the history
of changes and see data in the form that the UI was at the time the data was
originally created. As such, we need to be able to drive ALL UI
construction, validation and workflow dynamically out of a database.
Presentation flow
Cocoon is a good starting point for this, but as we work with Cocoon we end
up coding presentation rules and presentation flow rules in the sitemap. If
we're not careful we also end up coding work flow in the site map. It's
possible to get around this by adding selectors based on parameters and
making a pretty complex sitemap. But now you have a new maintenance
problem; strange sitemap "language", few experts, etc. A similar problem
comes with the coding of actions; I think I can skip details here since
you've remarked (I think) that you see flowscript as helping to remove the
requirement for actions?
Basically, we've got a requirement for a rules based evaluation of context
data. I don't want to code this in the sitemap language and I don't want to
hard code it in Java, I really want dynamic rules evaluation. We know a
functional programming model can provide this. Just so happens we have such
capabilities at hand via XSLT if we can feed it rules selectors described as
XML.
In-other-words: currently, sitemap has access to context via URI,
parameters, generators, etc. Based on this, sitemap spits out a decision on
what transform to use. What I want instead is to feed an XSLT this same set
of context as XML and have the XSLT pick the subsequent transform to use.
The advantages to me are; 1) I can code in XSLT instead of sitemap language;
2) I can optimize the entire chain of events since the transform picking
XSLT can pass on the context to the next transform (standard transform
chaining); 3) I get a functional programming model (not an advantage to
some, I know).
<big snip on discussion of issues functional programming skills/>
>>>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.
I hope it shouldn't be much of an issue. Even with Cocoon as it currently
sits we could almost do this cleanly; plug in a new transformer (sort of)
that takes over for the sitemap at some point, parceling out the rest of the
work as it sees fit. It would be subject to all the normal sitemap
invocation rules, but in our case we might end up with very few pipeline
(matchers) in the pipeline. Depending on how things shake out the new
component(s) might return to the sitemap for final serialization and thus to
Cocoon look exactly like a normal transformer. However, I could also see
how there might be situations where the serialization decision might be part
of the new thingy, and thus the blocks discussion and how to hand off
service calls becomes relevant.
>> <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.
Sorry, I think we crossed paths here. You stated that the decision process
didn't need flow when responding to a GET. However, I was trying to point
out that in this case the sitemap was responding to a POST. For the simple
POST case given here you could in fact code the handling in the sitemap by
having a generator create a count parameter that subsequent sitemap logic
worked against. However, now, you've ended up coding flow decisions in the
sitemap which I'm trying to avoid...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
