cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: FOM & FAPI (wasRe: FOM & input modules)
Date Wed, 26 Jan 2005 14:06:53 GMT
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>> Hmm, the question is: how can a pluggable object model work - or how 
>>> can it be extended? What about using...input modules for exactly 
>>> this? We create a way of "mounting" input modules into the object 
>>> model, like this:
>>> <object-model>
>>>   <mount input-module="skin" path=""/>
>>> </object-model>
>>> And then you can simple access the info by ${}.
>> I like it. Object model and input modules are just different names for 
>> similar things: accessing environmental data. Also, it's better to 
>> attach IMs to the cocoon object rather than as root variables, as it 
>> avoids name clashes with template variables.
>> Something we have to be careful of, though, is that properties of the 
>> cocoon object comes both from the OM (request, response, context) and 
>> modules, and that it should be forbidden to have IMs having the same 
>> name as OM keys.
>> I also would like to insist on the fact that FOM (flow object model) 
>> is nothing more than OM (object model) that we have everywhere in 
>> Cocoon, but rewrapped as JS objects. So we should better concentrate 
>> on the OM itself and let its JS counterpart follow its evolutions.
> Thinking further (while sleeping!), it seems to me that over time we 
> have abused the cocoon object in flowscript by making it an entry point 
> not only to the OM, but also to some flowscript-specific utilities, e.g. 
> getComponent(), processPipelineTo(), makeWebContinuation(), and of 
> course cocoon.sendPageAndWait()
> And this causes a lot of confusion, as we use the same "cocoon" name in 
> other places (jxtg) with only the OM meaning.
> So I think we should clearly separate the FOM (the JS wrapper of the OM) 
> from the FAPI, the flowscript API which gathers flowscript-related 
> utility functions by attaching them for a new "flowscript" object.
> We would therefore have:
> - cocoon.request, cocoon.context, cocoon.mymodule, etc.
> - flowscript.sendPageAndWait(), flowscript.getComponent(), 
> flowscript.redirect(), etc.
> Of course, if we choose to go that way, we must keep the current 
> functions on the cocoon object for back compatibility but clearly mark 
> them as deprecated.
> IMO, that separation would clarify things a lot, by clearly defining a 
> single object model, be it in Java, flowscript, jxtg, etc.

Makes perfect sense.

But I think that cocoon.getComponent() would make more sense than 
flowscript.getComponent() and also cocoon.request should be just 'request'.

I'm aware this is back compatibility nightmare... but consider it 

View raw message