You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/01/26 09:21:11 UTC
FOM & FAPI (wasRe: FOM & input modules)
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?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Carsten Ziegeler <cz...@apache.org>.
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?
>
Sounds good to me - and we should define the OM (= Java API) and later
wrap it for JS.
Carsten
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Torsten Curdt wrote:
>>
>>>> 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.
>>>
>>>
>>>
>>> sounds good to me ...one tiny thing though: I'd prefer the name
>>> "flow" ...so
>>>
>>> flow.sendPageAndWait(),
>>> flow.getComponent(),
>>> flow.redirect()
>>
>
> Why not cocoon.flow....? Do we really need another entry-point?
Because everything cocoon.xxx should be OM or IM (or only IM, as you
suggested), and be the same everywhere. Having different properties
attached to the cocoon object is what currently confuses people. At
least this is my understanding.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Torsten Curdt wrote:
>
>>> 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.
>>
>>
>> sounds good to me ...one tiny thing though: I'd prefer the name "flow"
>> ...so
>>
>> flow.sendPageAndWait(),
>> flow.getComponent(),
>> flow.redirect()
Why not cocoon.flow....? Do we really need another entry-point?
>> With javaflow the whole "script" naming scheme does not really fit
>> ...even if you get a script-like behaviour with the compiling
>> classloader ...IMO
>
>
> You're falling in the same trap again ;-)
>
> Why should the flowscript API and javaflow API be the same?
As Torsten already said, they should be (if not the same but) close, and +1 to that.
Vadim
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
>>> flow.sendPageAndWait(),
>>> flow.getComponent(),
>>> flow.redirect()
>>>
>>> With javaflow the whole "script" naming scheme does not really fit
>>> ...even if you get a script-like behaviour with the compiling
>>> classloader ...IMO
>>>
>>> WDYT?
>>
>>
>>
>>
>> You're falling in the same trap again ;-)
>>
>> Why should the flowscript API and javaflow API be the same? In
>> javaflow, you have access to Avalon-related data such as the service
>> manager and therefore don't need flow{script}.getComponent().
>
>
> Well, ok... the getComponent() will not be necessary
> (that was stupid ..I should have removed that line)
> ...but I am not proposing the same API - just the
> same naming scheme where possible.
>
> IMHO for the user it would be nice to see that the
> methodnames in flowscript and javaflow are very similiar.
> ...although the APIs can be different I would like to
> see the API being as close as possible.
I tend to agree with that.
--
Stefano.
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Torsten Curdt <tc...@apache.org>.
>> flow.sendPageAndWait(),
>> flow.getComponent(),
>> flow.redirect()
>>
>> With javaflow the whole "script" naming scheme does not really fit
>> ...even if you get a script-like behaviour with the compiling
>> classloader ...IMO
>>
>> WDYT?
>
>
>
> You're falling in the same trap again ;-)
>
> Why should the flowscript API and javaflow API be the same? In javaflow,
> you have access to Avalon-related data such as the service manager and
> therefore don't need flow{script}.getComponent().
Well, ok... the getComponent() will not be necessary
(that was stupid ..I should have removed that line)
...but I am not proposing the same API - just the
same naming scheme where possible.
IMHO for the user it would be nice to see that the
methodnames in flowscript and javaflow are very similiar.
...although the APIs can be different I would like to
see the API being as close as possible.
cheers
--
Torsten
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Torsten Curdt wrote:
>> 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.
>
>
> sounds good to me ...one tiny thing though: I'd prefer the name "flow"
> ...so
>
> flow.sendPageAndWait(),
> flow.getComponent(),
> flow.redirect()
>
> With javaflow the whole "script" naming scheme does not really fit
> ...even if you get a script-like behaviour with the compiling
> classloader ...IMO
>
> WDYT?
You're falling in the same trap again ;-)
Why should the flowscript API and javaflow API be the same? In javaflow,
you have access to Avalon-related data such as the service manager and
therefore don't need flow{script}.getComponent().
So the FSAPI (flowscript API) should be defined separately from the
JFAPI (javaflow API), even if they share some concepts and/or function
names related to the fact that they both manage flow, such as
sendPageAndWait().
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>> 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.
>
>
> sounds good to me ...one tiny thing though:
> I'd prefer the name "flow" ...so
>
> flow.sendPageAndWait(),
> flow.getComponent(),
> flow.redirect()
>
> With javaflow the whole "script" naming scheme does not
> really fit ...even if you get a script-like behaviour
> with the compiling classloader ...IMO
>
> WDYT?
I agree
--
Reinhard
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Torsten Curdt <tc...@apache.org>.
> 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.
sounds good to me ...one tiny thing though:
I'd prefer the name "flow" ...so
flow.sendPageAndWait(),
flow.getComponent(),
flow.redirect()
With javaflow the whole "script" naming scheme does not
really fit ...even if you get a script-like behaviour
with the compiling classloader ...IMO
WDYT?
cheers
--
Torsten
Re: FOM & FAPI (wasRe: FOM & input modules)
Posted by Stefano Mazzocchi <st...@apache.org>.
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.