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: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: oceatoon <t.katelbach@systheo.com>
Subject: Re: WishFull thinking JX and SessionContext Authentication
Date: Sat, 22 Jan 2005 20:55:26 +0100
Organization: oceatoon
Lines: 107
Message-ID: <csub51$t9l$1@sea.gmane.org>
References: <csrfka$lku$1@sea.gmane.org> <41F14560.9080100@apache.org>
 <41F17A62.4060600@mobilebox.pl> <41F237E3.9050708@apache.org>
 <41F2428C.9090804@mobilebox.pl> <41F243E1.1050307@mobilebox.pl>
 <41F27653.4040200@nada.kth.se>
Reply-To: t.katelbach@systheo.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Mail-Copies-To: t.katelbach@systheo.com
User-Agent: KNode/0.8.2
Sender: news <news@sea.gmane.org>

> 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