Pier Fumagalli <[EMAIL PROTECTED]> 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.
