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?
The syntax above is based on that the new pluggable expressions are used like
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.
<snip/>
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:
{ex:$cocoon/request/foo}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.
/Daniel
