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 Sun, 23 Jan 2005 15:19:46 GMT
oceatoon wrote:
>>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
> HOw about ${inputmodulename(params)}, so it stays jexl like syntax?

The syntax above is based on that the new pluggable expressions are used 

jxpath:$a+2, jexl:a+2 or just $a+2

if we had jxpath as default expression language. Then the idea was to 
make a pluggable expreesion embeding of input modules also so that input 
modules are considered as some kind of expressions. That would give the 
syntax above.

Now I'm not certain about how that should work as expressions take an 
ExpressionContext as input and input modules takes an object model.


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

The idea with input modules was to give access to various context 
objects, request, session etc in e.g. the sitemap. This task overlaps 
quite a lot with the flow object model (FOM) in flow and especially with 
the "view" FOM that is used in JXTG.

For making Cocoon easier to understand and maintain it is better to have 
one way of doing a thing than two essentially equivalent that are used 
in different contexts.

So the question is, should we focus on making the FOM the main way of 
accessing things in Cocoon or should we focus on IMs.

Carsten's suggestion IIUC is to focus on the FOM, something that I agree 
completely with. If we do that we should have some kind of expression 
module that could replace all other IMs and that could be used like:


etc. By doing that people only have to learn FOM and can use that 
everywhere. If we go this way we must see what IMs that do things that 
not are part of FOM and maybe find a way to make them pluggable in FOM.

The other alternative is to make IMs available in flow and JXTG. In any 
case we should be able to use everything that is usable from IMs in flow 
and JXTG as well, so we should do something about it.


View raw message