Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41F243E1.1050307@mobilebox.pl>
Date: Sat, 22 Jan 2005 13:15:29 +0100
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: WishFull thinking JX and SessionContext Authentication
References: <csrfka$lku$1@sea.gmane.org> <41F14560.9080100@apache.org>
 <41F17A62.4060600@mobilebox.pl> <41F237E3.9050708@apache.org>
 <41F2428C.9090804@mobilebox.pl>
In-Reply-To: <41F2428C.9090804@mobilebox.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
>>>
>>>
>>>
>>>
>>> Wouldn't it be better if JXTG supported input modules with syntax like:
>>>
>>> {im:moduleName:valueName}
>>>
>>> ?
>>
>>
>> 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
>>
> 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 );
> }
> 
> 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?


-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65