cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RANT] The Flow...
Date Fri, 07 Mar 2003 12:51:25 GMT
Hunsberger, Peter wrote:
> Pier Fumagalli <> wrote:
> <snip on how Pier arrived at the following:/>
>>What I would love to have, before even touching the flow 
>>_implementation_, is a consistent language-unaware definition 
>>of the object model that flow scripts will live into, define 
>>bindings from this object model to JavaScript, so that we all 
>>know what we are _supposed_ to implement, why, where and when.
> Yes please!  But while you are at it, don't you really want to define a
> complete Cocoon object model and not just one for flow (I think that's maybe
> what you're already doing?)?

Cocoon already defines a pretty clear 'object model' in terms of the 
interfaces that it exposes and the public methods of its main classes.

This has been designed years ago and it's still very solid.

>  Part of the issue is, where does work flow,
> and business logic fit into the big picture.  It's pretty clear that there
> are things we don't want in "flow" as such, but we need to know where they
> do fit in the "big picture":  all of Cocoon needs to hit the same object
> model, not just flow...

This is FUD. Cocoon provides extremely solid contracts. We are now 
introducing a new layer and this layer needs contracts. The collection 
of these contracts between flowscript and the cocoon internals are what 
I previously called 'Flow Object Model' (I dislike the term 'cocoon 
object model' because it triggers out-of-track thoughts like these)

The cocoon internals *are* solid and well defined.

The exposure of *all* these contracts to the flow might be dangerous 
since the flow should not have the ability to "abuse" the underlying 
framework (to follow IoC completely).

So, we provide an 'object model' that is given to each flowscript and 
it's the only way the flow can interact with the cocoon internals (thus 
is sandboxed).

The problem we are now facing is that some of us believe that the FOM 
(flow object model) is not very well designed from an OO-elegance point 
of view.

of course, things like elegance are highly debetable and might lead to 
personal friction and ego touching problems. But I think the biggest 
problem we face is lack of documentation and lack of visibility of what 
the flow capabilities really are.

The flow grew from an experiment into an important subsystem.

We must now polish the way the contracts are exposed since this hasn't 
been done so far.

NOTE: this is a natural way of building things. first you experiment, 
then you make it working, then you add features, but when asked to 
provide long-term support, you go back on the drawing table and see how 
things turned out and polish things.

This is exactly what Pier is calling for.

And I agree this community-driven FOM polishing is really needed before 
we can feel safe announcing a beta release where we become committed to 
long-term maintenance of those contracts.

Note that this doesn't have to be taken like a critique to those who 
drove the flow so far (Ovidiu and Chris), but, at the contrary, as a 
statement of maturity for a technology that is no longer considered an 
experiment, but an important feature of our framework.

I really hope nobody forgets all this.

View raw message