cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject FOM & FAPI (wasRe: FOM & input modules)
Date Wed, 26 Jan 2005 08:21:11 GMT
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.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message