Reinhard Poetz wrote:
If we have JXPath as default expression language one could use $cocoon as context object for JXPath and get the alternative possiblity: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}
{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
