cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: WishFull thinking JX and SessionContext Authentication
Date Sat, 22 Jan 2005 15:50:43 GMT
Leszek Gawron wrote:
> Leszek Gawron wrote: 
>> Carsten Ziegeler wrote:
>>> Leszek Gawron wrote:
>>>> Carsten Ziegeler wrote:
>>>>> oceatoon wrote:
>>>>>> This is wishfull thinking and probably no news to those 
>>>>>> refactoring JX. But
>>>>>> access to the session context object like the session-context 
>>>>>> input module
>>>>>> would be great (like for example with the authentication context).

>>>>>> I have
>>>>>> found other post asking about and for this sort of functionality.

>>>>>> it would
>>>>>> smoothen quite a bit the access to such inportant elements as the

>>>>>> ones in
>>>>>> session-context (like authentication data).
>>>>> Yes, this should be possible, I agree. I hope that the refactored 
>>>>> version will be pluggable to plug-in some kind of adapter to access 
>>>>> "own data" like the authentication context etc.

You don't need to just hope, you can either implement it or describe how 
it should work so that someone else can do it ;)

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}

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 ;)

>>> 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"/>

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 );
> that would require FOM to be extended. WDYT?

IIRC modules was part of flow once but removed after a vote as people 
thought that most of the things you can do with modules can be done in a 
less clumsy way with the FOM and ordinary JS constructs and that where 
was no reason do duplicate functionality.

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.


View raw message