You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/01/24 07:30:34 UTC
FOM & input modules
Daniel Fagerstrom wrote:
> So the question is, should we focus on making the FOM the main way of
> accessing things in Cocoon or should we focus on IMs.
>
> Carsten's suggestion IIUC is to focus on the FOM, something that I agree
> completely with.
I agree with this too.
If we do that we should have some kind of expression
> module that could replace all other IMs and that could be used like:
>
> {ex:$cocoon/request/foo}
>
> etc. By doing that people only have to learn FOM and can use that
> everywhere. If we go this way we must see what IMs that do things that
> not are part of FOM and maybe find a way to make them pluggable in FOM.
hmmm, than we could have something like
{$defaults/skin}
{$language/locale}
And as you can see, I think we can skip the input module name, if all objects
are part of the plugable object model.
> The other alternative is to make IMs available in flow and JXTG.
The like the idea of a plubable object model much more.
> In any
> case we should be able to use everything that is usable from IMs in flow
> and JXTG as well, so we should do something about it.
--
Reinhard
Re: FOM & input modules
Posted by Peter Hunsberger <pe...@gmail.com>.
On Tue, 25 Jan 2005 23:58:41 +0100, Sylvain Wallez <sy...@apache.org> wrote:
<snip/>
> 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.
+1 Yes, please.
--
Peter Hunsberger
Re: Lazy mode and compiling classloader (was Re: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Thank you, that's much clearer than my explanation (though I meant the
> same ;-)
LOL!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Lazy mode and compiling classloader (was Re: FOM & input modules)
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Reinhard Poetz wrote:
>>
>>
>
>>>> After some experiments with the new compiling classloader stuff, I
>>>> personally don't feel a need for a scripting action solution. But
>>>> this highly depends on your skills.
>>>
>>>
>>>
>>>
>>> Interesting, do you mean that you write ordinary actions and use the
>>> compiling classloader on them?
>>
>>
>>
>> I tried it and it worked for me. Currently, *you* have to make sure
>> that the sitemap reloads (e.g. adding a space character) but if I
>> understood Sylvain's mail to his "lazy mode" implementation correctly,
>> this will help to get rid of this (ugly) workaround.
>
>
>
> Ahem, no: the lazy mode only loads (and therefore compiles) components
> the first time they are looked up in the service manager. That means
> that currently you have to "touch" the sitemap in order for classes to
> be reloaded.
>
> But the actual purpose of the lazy mode is not only fast startup time,
> but also fast *reload* time: the idea is that when a source file is
> changed, Cocoon is restarted in the same way as a ?cocoon-reload=true,
> therefore recompiling everything that needs to be recompiled and
> garbaging all instances of the previous versions of recompiled classes.
>
> But that reloading isn't there yet.
Thank you, that's much clearer than my explanation (though I meant the same ;-)
--
Reinhard
Lazy mode and compiling classloader (was Re: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Reinhard Poetz wrote:
>
>>> After some experiments with the new compiling classloader stuff, I
>>> personally don't feel a need for a scripting action solution. But
>>> this highly depends on your skills.
>>
>>
>>
>> Interesting, do you mean that you write ordinary actions and use the
>> compiling classloader on them?
>
>
> I tried it and it worked for me. Currently, *you* have to make sure
> that the sitemap reloads (e.g. adding a space character) but if I
> understood Sylvain's mail to his "lazy mode" implementation correctly,
> this will help to get rid of this (ugly) workaround.
Ahem, no: the lazy mode only loads (and therefore compiles) components
the first time they are looked up in the service manager. That means
that currently you have to "touch" the sitemap in order for classes to
be reloaded.
But the actual purpose of the lazy mode is not only fast startup time,
but also fast *reload* time: the idea is that when a source file is
changed, Cocoon is restarted in the same way as a ?cocoon-reload=true,
therefore recompiling everything that needs to be recompiled and
garbaging all instances of the previous versions of recompiled classes.
But that reloading isn't there yet.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>
> <snip/>
>
>>> If you need the above i18n stuff in all your pipelines you could just
>>> call a (flow)script action without any match criterion in the
>>> begining of your pipeline and let it calculate the locale and put it
>>> in a context variable where it is visible in the rest of the pipelines.
>>
>>
>> After some experiments with the new compiling classloader stuff, I
>> personally don't feel a need for a scripting action solution. But this
>> highly depends on your skills.
>
>
> Interesting, do you mean that you write ordinary actions and use the
> compiling classloader on them?
I tried it and it worked for me. Currently, *you* have to make sure that the
sitemap reloads (e.g. adding a space character) but if I understood Sylvain's
mail to his "lazy mode" implementation correctly, this will help to get rid of
this (ugly) workaround.
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> If you need the above i18n stuff in all your pipelines you could just
>> call a (flow)script action without any match criterion in the begining
>> of your pipeline and let it calculate the locale and put it in a
>> context variable where it is visible in the rest of the pipelines.
>
> After some experiments with the new compiling classloader stuff, I
> personally don't feel a need for a scripting action solution. But this
> highly depends on your skills.
Interesting, do you mean that you write ordinary actions and use the
compiling classloader on them?
/Daniel
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>>>
>>>>> Please note that I'm not suggesting to remove the current input
>>>>> modules. This is all about making Cocoon more coherent, not about
>>>>> introducing back incompability. If we find a good way to replace
>>>>> input modules I would suggest that we move them from core to an
>>>>> input module block so that they become optional.
>>>>>
>>>>> WDYT?
>>>>
>>>>
>>>> Having only one input module that uses a Cocoon wide object model is
>>>> IMO a good idea. We should go through the list of all input modules
>>>> and look where it makes sense to extend the object model.
>>>
>>>
>>> I wrote the slightly commented list of input modules that you cutted
>>> away from my post in the hope of geting some input about that. I use
>>> modules that overlaps with FOM in nearly all of my sitemaps so I
>>> don't have much opinion about the more exotic modules.
>>>
>>> The things that I need that not is part of FOM is some type of
>>> handling of global or sitemap specific data corresponding to e.g.,
>>> DefaultsModule or GlobalInputModule. But it is rather the handling of
>>> application parameters than the actual input module solution that I
>>> need.
>>>
>>> Also I have used the BaseLinkModule and some own module for URL
>>> rewriting purposes.
>>>
>>> Both application parameters and better sitemap related URL handling
>>> could be part of the Context object IMO.
>>>
>>>> Creating a modules block that contains all existing input modules
>>>> for backwards-compatibility sounds good to me too.
>>>>
>>>> One question remains: Should it be allowed to add your
>>>> project-specific extenstions to the object model? e.g. I like to use
>>>> chained input modules (i18n issues) or my own constants input modules.
>>>
>>>
>>>
>>>
>>> Could you explain your use case a little bit more.
>>
>>
>>
>> Something like this:
>> <component-instance name="l"
>> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
>> logger="core.modules.input">
>> <!-- first try the 'locale' request param -->
>> <input-module name="request-param"/>
>> <!-- next the session attribute -->
>> <input-module name="session-attr"/>
>> <!-- next try the request locale attribute -->
>> <input-module name="request-language"/>
>> <!-- finally use a default value -->
>> <input-module name="settings"/>
>> </component-instance>
>>
>> This is useful to determine the language of my application but needs
>> to be configurable. Don't know if such a chain module should be part
>> of the object model, but why not.
>
>
> Why not? Because chain modules and the rest of the meta modules IMO
> sucks from readability POV. Without the comments the above snippet would
> have said nothing to me. I would guess that if you had written the above
> code in terms of flowscript it would have been much easier to see what
> happens.
good idea! I haven't thought much about this yet, but I think you're right. (I
was just a user who found a solution for this problem :-) )
> If you need the above i18n stuff in all your pipelines you could just
> call a (flow)script action without any match criterion in the begining
> of your pipeline and let it calculate the locale and put it in a context
> variable where it is visible in the rest of the pipelines.
After some experiments with the new compiling classloader stuff, I personally
don't feel a need for a scripting action solution. But this highly depends on
your skills.
>
> To me that is less magic than having a XML based semi program language
> in your configuration.
>
> The original idea with input modules, giving pluggable access to
> environment properties was a good idea IMO. Even if the inteface with
> all the configuration parameters smells FS to me. But then a small
> program language is build on top of that in terms of the meta modules
> with more or less obscure programming constructs.
>
> IMO we should try to give this a fresh look and try to get rid of the
> need to use meta modules. So I don't feel any entusiasm for pluggin in
> modules in the object model.
>
> From the discussion this far my conclusion is that we need to
> strengthen the context model with same kind of application global
> parameters, better info for URL rewriting and also that we need
> (flow)script actions for an easy way to put application specific data in
> the object model.
ok, sounds reasonable
> But I have not yet seen any use cases that convinces me about the
> necesity in pluging input modules into the object model.
>
> Maybe our anti FS task force have some wise words to add ;)
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:
>>> Daniel Fagerstrom wrote:
>>>>
>>>> Please note that I'm not suggesting to remove the current input
>>>> modules. This is all about making Cocoon more coherent, not about
>>>> introducing back incompability. If we find a good way to replace
>>>> input modules I would suggest that we move them from core to an
>>>> input module block so that they become optional.
>>>>
>>>> WDYT?
>>>
>>> Having only one input module that uses a Cocoon wide object model is
>>> IMO a good idea. We should go through the list of all input modules
>>> and look where it makes sense to extend the object model.
>>
>> I wrote the slightly commented list of input modules that you cutted
>> away from my post in the hope of geting some input about that. I use
>> modules that overlaps with FOM in nearly all of my sitemaps so I don't
>> have much opinion about the more exotic modules.
>>
>> The things that I need that not is part of FOM is some type of
>> handling of global or sitemap specific data corresponding to e.g.,
>> DefaultsModule or GlobalInputModule. But it is rather the handling of
>> application parameters than the actual input module solution that I need.
>>
>> Also I have used the BaseLinkModule and some own module for URL
>> rewriting purposes.
>>
>> Both application parameters and better sitemap related URL handling
>> could be part of the Context object IMO.
>>
>>> Creating a modules block that contains all existing input modules for
>>> backwards-compatibility sounds good to me too.
>>>
>>> One question remains: Should it be allowed to add your
>>> project-specific extenstions to the object model? e.g. I like to use
>>> chained input modules (i18n issues) or my own constants input modules.
>>
>>
>>
>> Could you explain your use case a little bit more.
>
>
> Something like this:
> <component-instance name="l"
> class="org.apache.cocoon.components.modules.input.ChainMetaModule"
> logger="core.modules.input">
> <!-- first try the 'locale' request param -->
> <input-module name="request-param"/>
> <!-- next the session attribute -->
> <input-module name="session-attr"/>
> <!-- next try the request locale attribute -->
> <input-module name="request-language"/>
> <!-- finally use a default value -->
> <input-module name="settings"/>
> </component-instance>
>
> This is useful to determine the language of my application but needs to
> be configurable. Don't know if such a chain module should be part of the
> object model, but why not.
Why not? Because chain modules and the rest of the meta modules IMO
sucks from readability POV. Without the comments the above snippet would
have said nothing to me. I would guess that if you had written the above
code in terms of flowscript it would have been much easier to see what
happens.
If you need the above i18n stuff in all your pipelines you could just
call a (flow)script action without any match criterion in the begining
of your pipeline and let it calculate the locale and put it in a context
variable where it is visible in the rest of the pipelines.
To me that is less magic than having a XML based semi program language
in your configuration.
The original idea with input modules, giving pluggable access to
environment properties was a good idea IMO. Even if the inteface with
all the configuration parameters smells FS to me. But then a small
program language is build on top of that in terms of the meta modules
with more or less obscure programming constructs.
IMO we should try to give this a fresh look and try to get rid of the
need to use meta modules. So I don't feel any entusiasm for pluggin in
modules in the object model.
From the discussion this far my conclusion is that we need to
strengthen the context model with same kind of application global
parameters, better info for URL rewriting and also that we need
(flow)script actions for an easy way to put application specific data in
the object model.
But I have not yet seen any use cases that convinces me about the
necesity in pluging input modules into the object model.
Maybe our anti FS task force have some wise words to add ;)
/Daniel
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>>
>>> Please note that I'm not suggesting to remove the current input
>>> modules. This is all about making Cocoon more coherent, not about
>>> introducing back incompability. If we find a good way to replace
>>> input modules I would suggest that we move them from core to an input
>>> module block so that they become optional.
>>>
>>> WDYT?
>>
>>
>>
>> Having only one input module that uses a Cocoon wide object model is
>> IMO a good idea. We should go through the list of all input modules
>> and look where it makes sense to extend the object model.
>
>
> I wrote the slightly commented list of input modules that you cutted
> away from my post in the hope of geting some input about that. I use
> modules that overlaps with FOM in nearly all of my sitemaps so I don't
> have much opinion about the more exotic modules.
>
> The things that I need that not is part of FOM is some type of handling
> of global or sitemap specific data corresponding to e.g., DefaultsModule
> or GlobalInputModule. But it is rather the handling of application
> parameters than the actual input module solution that I need.
>
> Also I have used the BaseLinkModule and some own module for URL
> rewriting purposes.
>
> Both application parameters and better sitemap related URL handling
> could be part of the Context object IMO.
>
>> Creating a modules block that contains all existing input modules for
>> backwards-compatibility sounds good to me too.
>>
>> One question remains: Should it be allowed to add your
>> project-specific extenstions to the object model? e.g. I like to use
>> chained input modules (i18n issues) or my own constants input modules.
>
>
> Could you explain your use case a little bit more.
Something like this:
<component-instance name="l"
class="org.apache.cocoon.components.modules.input.ChainMetaModule"
logger="core.modules.input">
<!-- first try the 'locale' request param -->
<input-module name="request-param"/>
<!-- next the session attribute -->
<input-module name="session-attr"/>
<!-- next try the request locale attribute -->
<input-module name="request-language"/>
<!-- finally use a default value -->
<input-module name="settings"/>
</component-instance>
This is useful to determine the language of my application but needs to be
configurable. Don't know if such a chain module should be part of the object
model, but why not.
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>>
>> Please note that I'm not suggesting to remove the current input
>> modules. This is all about making Cocoon more coherent, not about
>> introducing back incompability. If we find a good way to replace
>> input modules I would suggest that we move them from core to an input
>> module block so that they become optional.
>>
>> WDYT?
>
>
> Having only one input module that uses a Cocoon wide object model is
> IMO a good idea. We should go through the list of all input modules
> and look where it makes sense to extend the object model.
I wrote the slightly commented list of input modules that you cutted
away from my post in the hope of geting some input about that. I use
modules that overlaps with FOM in nearly all of my sitemaps so I don't
have much opinion about the more exotic modules.
The things that I need that not is part of FOM is some type of handling
of global or sitemap specific data corresponding to e.g., DefaultsModule
or GlobalInputModule. But it is rather the handling of application
parameters than the actual input module solution that I need.
Also I have used the BaseLinkModule and some own module for URL
rewriting purposes.
Both application parameters and better sitemap related URL handling
could be part of the Context object IMO.
> Creating a modules block that contains all existing input modules for
> backwards-compatibility sounds good to me too.
>
> One question remains: Should it be allowed to add your
> project-specific extenstions to the object model? e.g. I like to use
> chained input modules (i18n issues) or my own constants input modules.
Could you explain your use case a little bit more.
Considering allowing project specific object model extensions, if we add
better URI and application parameter handling to e.g. the context
object, I'm satisfied with that. For project specific extensions I think
flowscript will be enough especially if we make it easier to use with
(flow)script actions.
But Carsten seemed to see a need for plugable object model extensions
and maybe other does. Please describe your use cases so that we can
discuss how to solve them.
/Daniel
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Please note that I'm not suggesting to remove the current input
>>> modules. This is all about making Cocoon more coherent, not about
>>> introducing back incompability. If we find a good way to replace
>>> input modules I would suggest that we move them from core to an
>>> input module block so that they become optional.
>>>
>>> WDYT?
>>
>> Having only one input module that uses a Cocoon wide object model is
>> IMO a good idea. We should go through the list of all input modules
>> and look where it makes sense to extend the object model.
>>
>> Creating a modules block that contains all existing input modules for
>> backwards-compatibility sounds good to me too.
>>
>> One question remains: Should it be allowed to add your
>> project-specific extenstions to the object model?
>
> Yes :)
>
>> e.g. I like to use chained input modules (i18n issues) or my own
>> constants input modules.
>>
> 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}.
Thats ok for me. Any ideas about how to implement it? Right now the we
have the FlowObjectModelHelper that just take an object model and
creates a ExpressionContext (as you implemented most of it you already
know this ;) ). I guess we should make the $cocoon part of the template
object model a component so that we can configure it and don't have to
create it from scratch for each use of it. But at the same time it must
depend on the current object model. Any ideas about how to do that?
/Daniel
Re: FOM & input modules
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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.
... unless cocoon.request, response, context are implemented as corresponding
input modules ... then everything under "cocoon." becomes an input module ;-)
Vadim
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.
FOM & FAPI (wasRe: FOM & input modules)
Posted by Sylvain Wallez <sy...@apache.org>.
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 & input modules
Posted by Sylvain Wallez <sy...@apache.org>.
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM & input modules
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>>
>> Please note that I'm not suggesting to remove the current input
>> modules. This is all about making Cocoon more coherent, not about
>> introducing back incompability. If we find a good way to replace input
>> modules I would suggest that we move them from core to an input module
>> block so that they become optional.
>>
>> WDYT?
>
>
> Having only one input module that uses a Cocoon wide object model is IMO
> a good idea. We should go through the list of all input modules and look
> where it makes sense to extend the object model.
>
> Creating a modules block that contains all existing input modules for
> backwards-compatibility sounds good to me too.
>
> One question remains: Should it be allowed to add your project-specific
> extenstions to the object model?
Yes :)
> e.g. I like to use chained input
> modules (i18n issues) or my own constants input modules.
>
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}.
Carsten
Re: FOM & input modules
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
>
> Please note that I'm not suggesting to remove the current input modules.
> This is all about making Cocoon more coherent, not about introducing
> back incompability. If we find a good way to replace input modules I
> would suggest that we move them from core to an input module block so
> that they become optional.
>
> WDYT?
Having only one input module that uses a Cocoon wide object model is IMO a good
idea. We should go through the list of all input modules and look where it makes
sense to extend the object model.
Creating a modules block that contains all existing input modules for
backwards-compatibility sounds good to me too.
One question remains: Should it be allowed to add your project-specific
extenstions to the object model? e.g. I like to use chained input modules (i18n
issues) or my own constants input modules.
--
Reinhard
Re: FOM & input modules
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> So the question is, should we focus on making the FOM the main way of
>> accessing things in Cocoon or should we focus on IMs.
>>
>> Carsten's suggestion IIUC is to focus on the FOM, something that I
>> agree completely with.
>
>
> I agree with this too.
>
> If we do that we should have some kind of expression
>
>> module that could replace all other IMs and that could be used like:
>>
>> {ex:$cocoon/request/foo}
>
If we have JXPath as default expression language one could use $cocoon
as context object for JXPath and get the alternative possiblity:
{ex:request/foo}
for objects in $cocoon
>>
>> etc. By doing that people only have to learn FOM and can use that
>> everywhere. If we go this way we must see what IMs that do things
>> that not are part of FOM and maybe find a way to make them pluggable
>> in FOM.
>
>
> hmmm, than we could have something like
>
> {$defaults/skin}
> {$language/locale}
>
> And as you can see, I think we can skip the input module name, if all
> objects are part of the plugable object model.
Yes that would be nice, the question is that can be done in a way that
is back compatible with current module syntax.
>> The other alternative is to make IMs available in flow and JXTG.
>
>
> The like the idea of a plubable object model much more.
Thats good :) Ok so now we have two questions what objects that are
available in input modules but currently not is easy to access from the
object model do we want to make easier to access and how do we implement
it. I think we should focus on the first question right now.
Taking a quick look at the modules I would sugest that we have some sets
of modules with various properties:
Overlaps with FOM
-----------------
These modules does thing that is easy to do with FOM and an expression
language AFAIU:
FlowAttributeModule
FlowContinuationModule
HeaderAttributeModule
RawRequestParametersModule
RealPathModule
RequestAttributeModule
RequestModule
RequestURIModule
SessionAttributeModule
SessionModule
Might be interesting in FOM
---------------------------
These give access to objects that not are part of FOM AFAIK and could be
usable both in the sitemap, JXTG and flow:
DefaultsModule
GlobalInputModule
NamingInputModule
PropertiesFileModule
XMLFileModule
We have some modules that are functions on URIs rather than accessing
some object:
DigestMetaModule
URLDecodeModule
URLEncodeModule
And some that apply some functionality on an object that is part of FOM:
BaseLinkModule
--- o0o ---
Besides the listed modules we have a set of meta modules that AFAIU
gives the possiblity to create some kind of "expressions" based on
modules, is this needed when we have flow and expression languages on a FOM?
There are also some modules that I don't know anything about and didn't
list.
Also all more advanced use of input modules could probably better be
replaced by a short flowscript call. And we should at least take into
account the possiblity that we don't need any pluggable object models at
all and that flow is enough.
--- o0o ---
Please note that I'm not suggesting to remove the current input modules.
This is all about making Cocoon more coherent, not about introducing
back incompability. If we find a good way to replace input modules I
would suggest that we move them from core to an input module block so
that they become optional.
WDYT?
/Daniel