Re: 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.
... unless cocoon.request, response, context are implemented as corresponding
input modules ... then everything under cocoon. becomes an input module ;-)
Vadim
Lazy mode and compiling classloader (was Re: FOM input modules)
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
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
On Tue, 25 Jan 2005 23:58:41 +0100, Sylvain Wallez [EMAIL PROTECTED] 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)
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
Re: Lazy mode and compiling classloader (was Re: FOM input modules)
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: FOM input modules
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
Re: FOM input modules
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
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
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
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
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
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
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
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
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
