cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From oceatoon <t.katelb...@systheo.com>
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:
> 
> {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


Mime
View raw message