cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: What's the use of fillContext method
Date Sat, 04 Aug 2007 12:27:54 GMT
Grzegorz Kossakowski skrev:
> Hi,
> 
> I would like to know what's real use of from 
> o.a.c.environment.TemplateObjectModelHelper.fillContext() method? For 
> me, this method looks like trying to work-around bad design.
> 
> Basically, this method gets context bean and tries to add all its 
> properties (may be "dynamic properties" like entries in Map) to the 
> object model. I believe that this is really hacky and was invented 
> because JEXL doesn't have concept of context bean, only of variables. 
> Thus the need for mapping of context to the variables.

I think that the functionality can be convenient when you have a 
flowscript that just access e.g. a business bean from e.g. Hibernate. 
Then you just use the bean as business object in the sendPage function 
and can access its properties directly from JEXL.

> My own opinion is that we should remove this method completely and let 
> JEXL access context bean's properties this way:
>   contextBean.some_property
> 
> If someone want's "some_property" to be accessed directly, she should 
> add it to variables. I think that's much more clean and reliable contract.

Might be, but I don't think it is a strong enough reason to introduce 
back incompatibility.

> You may wonder why I want to remove it at all. My goal is to get rid of 
> TemplateObjectModelHelper which scope is narrowed to template, only. 
> This stops me from having unified object model across all Cocoon parts. 
> To achieve unified architecture, I want to make Cocoon areas (like 
> flowscript) respectively responsible for various object model entries 
> creation to be also responsible for addition this entries to the 
> ObjectModel. Now, the situation is rather confusing because flowscript 
> creates context bean and inserts it to the "component object model" (the 
> one passed to Cocoon's components) and later template creates Object 
> Model by collecting various bits of information.
> I've started to alter this in r562102[1].

I'd suggest that you move the code in 
TemplateObjectModelHelper.getTemplateObjectModel that fills the object 
model with attributes (or properties) to 
o.a.c.components.flow.AbstactInterpreter.forwardTo. The forwardTo method 
should also set up a local object model context for this information so 
that the object model doesn't become cluttered with data from earlier 
(e.g. internal) forwardTo calls. By moving the setup code from 
JXTemplateGenerator to AbstractInterpreter.forwardTo the context 
properties are available for all components, not just the 
JXTemplateGenerator.

The setup of "cocoon.parameters" must still be done in 
JXTemplateGenerator of course. Ths setup of the context bean property in 
fillNewObjectModelWithFOM seem redundant, it is already done in 
AbstactInterpreter.forwardTo.

> What's your opinion? I would only want to add that removal of 
> fillContext is probably back-incompatible change.

It would, and it seem like an unnecessary step to me.

/Daniel

Mime
View raw message