Re: Flow wishlist :)

[Stefano Mazzocchi]

Hunsberger, Peter wrote:

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.)

yeah, you could implement what you want using dynamically added PI (processing instructions) for the C1 reactor, but it would end up being very messy anyway.

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.

Ok, let's start from these requirements.

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.

well, that's what it was designed for. The design of the sitemap was *explicitly* meant to be static and remains so. So far, nobody was able to come up with an example where dynamically generated pipelines were the *only* way to solve a functional requirement.

Anyway, I'll be strongly against adding dynamic pipeline generation capabilities, either in the sitemap or in the flowmap.

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?

Yes, I don't see the need for writing your own actions once you start using flowscript attached to your sitemap.

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.

Look: I really don't get what you mean by this. Sorry, I'm slow sometimes: can you show me an *explicit* example of your functional needs? otherwise I don't feel I can be much helpful if we keep this level of abstraction without me understanding where you want to go.

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.

Sounds like the good old 'golden-hammer' antipattern to me. But I won't comment further until I understand your requirements.

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.

That's one way of looking at it. Another is that your functional logic could be directly included in the generator.

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).

I don't get it: you say that your requirements are so horrible that you need to keep all your rules into a database (which is a questionable sentence right there, but I don't have details to judge it). Then you say that a sitemap becomes a mess. Result: you want to write a XSLT stylesheet that uses extensions to connect to a database to obtain dynamically generated pattern-matching rules to transform an XML representation of your request context into a directly-digestible output?

how that is goint to be any better than a sitemap+flowmap is *very* hard to see from where I stand.

moreover, it sounds like an optimal solution to kill your webapp performances: that stylesheets becomes your bottleneck. So either you write your own xslt engine (or extend an existing one) to be able to optimize those database-extracted rules, or you're goint to have *serious* scalability issues right there.

In both cases, big implementation PITA.

End result? your people might know the XSLT syntax, but one thing is to know the syntax of a language, another is to be able to read a stylesheet that includes hard-core functional programming connected to external datasource via extensions.

If you think that is going to be easier for you to find people able to read/write/maintain those hard-core stylesheets than it will be to find people that can learn the sitemap syntax and a read a few lines of javascript, I think you have some thick walls to crash into in your future :)

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.

Yes. If you write your own transformer that does everything for you, then there is no problem, you can do it even today.

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.

It is *NOT* a transformer decision to drive the serialization process. It's against both SoC and IoC! There is nothing planned for Cocoon Blocks that will allow this to happen and as soon as I have to vote around here, you'll get my -1 on anything that makes possible for one pipeline component to modify dynamically the pipeline execution, including choosing a serializer.

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]