cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: What's the use of fillContext method
Date Sun, 05 Aug 2007 11:16:26 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
> 
> 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.

Yeah, I guess that was the reason why this method has been introduced, at all.

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

Ok, I can wait with this change for C2.3 but I really think we should remove it. Or if there
is strong resistance, document it well because 
it's not that obvious.

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

I'm wondering why not to the FlowHelper where context bean is set up?

I'm already moving most of the code of Template and Flow Object Model helpers.

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

Actually my goal is to get rid of both Template and FlowObjectModel helper classes. I'm very
close this achieving it.

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

Ok, I'll move the code to other place and leave it as is for now.

Thanks for keeping eye on my code and e-mails!

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message