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
