cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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="cocoon.skin"/>
>>> </object-model>
>>>
>>> And then you can simple access the info by ${cocoon.skin.something}.
>>
>>
>>
>>
>> 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.
> 
> WDYT?

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 
brainstorming.
-- 
Stefano.


Mime
View raw message