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/
