cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oceatoon <>
Subject Re: WishFull thinking JX and SessionContext Authentication
Date Sat, 22 Jan 2005 19:55:26 GMT
> 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:
> {}
> 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.


View raw message