Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > > Hunsberger, Peter wrote: > > 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.
Ok, I'll bite, where is the documentation? (No I don't mean Javadoc!) > > > 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. Well yes, that's fine, it's the things not yet designed I'm worried about... Where do new things go? Not how do I work with old things. In particular, if something doesn't go in flow (yet it's being prototyped with JavaScript) how should it eventually be hooked into Cocoon? <snip on stuff I agree with/>
