> Then I think that it shouldn't be part of the JXTG code but rather part
> of the TemplateObjectModelHelper or some supporting classes, that in
> turn are used by JXTG. This way it could be used outside JXTG.
>
>>>>> Wouldn't it be better if JXTG supported input modules with syntax
>>>>> like:
>>>>>
>>>>> {im:moduleName:valueName}
HOw about ${inputmodulename(params)}, so it stays jexl like syntax?
> Don't know if I like that, modules and expressions are a little bit
> overlapping as many modules are using JXPath. The question is who should
> call who. And I'm not certain that:
>
> {im:flow-attr:jexl:foo.bar}
>
> would help making Cocoon easy to use and understand ;)
That's another story ;)
>
>>>> Don't know :) Sure, this is one solution - my idea is a little bit
>>>> different:
>>>> we could provide a pluggable object model and then use this object
>>>> model in jxtg,
>>>> but also in input modules - so in fact you would only need one input
>>>> module and can use the same syntax there as in jxtg. I'm not sure if
>>>> this makes sense, but if it does, we wouldn't need input modules
>>>> anymore.
>
> >>> Carsten
>
> Makes sense to me, I would also prefer going this direction. Having one
> prefered way to access things and using it everywhere will make Cocoon
> easier to learn. And we can focus our work on one implementation.
>
> We need to identify which modules that give access to something that not
> allready is part of FOM and discuss which of them that we want to make
> accessable from FOM.
>
> Then we could put all the module in a block and thus get rid of the most
> exotic (mis)uses of the module concept from core.
>
> Maybe we could make the FOM pluggable so that we have a configuration
> where one decides what object that shoud be part of FOM.
>
> Then on the other hand we shouldn't overdo it. More specialized pluging
> can always be done in flow:
>
>>> don't we have a pluggable object model ? :))
>>>
>>> function doIt() {
>>> var objectModel = {};
>>>
>>> objectModel.pluggedIn1 = entityFromDatabase();
>>> objectModel.pluggedIn2 = request.getParameter( "skin" );
>>>
>>> cocoon.sendPage( "view/myview.jx", objectModel );
>>> }
>
> I would go further:
>
> function doIt() {
> var objectModel = {};
>
> objectModel.pluggedIn1 = entityFromDatabase();
> objectModel.pluggedIn2 = request.getParameter( "skin" );
>
> return objectModel;
> }
>
> <match pattern="foo">
> <call function="doIt"/>
> <generate type="jx" src="foo"/>
> ...
> </match>
>
> Or whatever syntax we choose for (flow)script actions. The idea is that
> the flow context is the return value from the function.
>
> I'll start to discuss design and work on this after the JXTG refactoring
> if no one else does it before me and if the community agrees.
>
>>> Other data that is not directly available from flow (like
>>> authentication context can be accessed with input modules that are
>>> already available).
>>>
>> something like this in flow would be useful:
>>
>> function doIt() {
>> var objectModel = {
>> skin: cocoon.inputModule.defaults.getValue( "skin" )};
>>
>> cocoon.sendPage( "view/myview.jx", objectModel );
>>
Talking about making cocoon easy to understand, I have a hard time seeing
the pros and cons of the pluggable ObjectModels, certainly because I don't
see the whole picture around it(maybe some naive explaining would
help,THX). OTOH, I can see great use of the last one (IM).
> I would prefer to do as outlined above, identify what or maybe if we are
> missing something from some input modules and make that functionality
> available in $cocoon or through flow.
if input modules are functional in jx and Flow what else do we need appart
for writting all the IM's we need.
regards
Tibor
