cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: FOM & input modules
Date Mon, 24 Jan 2005 10:25:37 GMT
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


Mime
View raw message