cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Flow wishlist :)
Date Fri, 29 Nov 2002 08:45:07 GMT
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                               <>

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

View raw message