Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
...
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 meant that the code should be *called* from AbstractInterpreter.forwardTo.
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.
Being more explicit I suggest that the parameter setup part of
FlowObjectModelHelper.fillNewObjectModelWithFOM is factored out to an
own helper method e.g.
FlowObjectModelHelper.fillNewObjectModelWithParameters. Then the
(modified) fillNewObjectModelWithFOM is called in
AbstractInterpreter.forwardTo (in an own environment context). Which
means that the flow context info is available in the object everywhere
and not just in JXTG. In JXTG.performGeneration just the parameters are
set with fillNewObjectModelWithParameters.
But this far we only have access to the sitemap component parameters
from the object model in JXTG, shouldn't they be accessible in all
sitemap components?
For all sitemap components that means that the component parameters
needs to be pushed to the object model before looking up the component
from the service manager. By doing that the parameters are available in
the object model if it is injected or looked up in the service method.
For the pipeline components this needs to be done in the setGenerator
etc methods in the AbstractProcessingPipeline. For actions, matchers etc
it probably needs to be done in the ProcessingNode.invoke methods.
Next the setup methods for the pipeline components (in
AbstractProcessingPipeline.setupPipeline) and the
SitemapExecutor.invokeAction etc methods that are called in the
ProcessingNode.invoke methods for actions etc, needs to be executed when
the right parameters are pushed on the object model.
What is most complicated (and something we maybe don't have to care
about), is making the right component parameters available while
executing a pipeline. To get it right we need something like:
Generator -> EnvironmentChanger -> Transformer -> EnvironmentChanger ->
... -> EnvironmnetChanger -> Serializer
where the EnvironmentChanger wraps the XMLConsumer for the next
component and pops the current component parameters and push the ones
for the next component for each SAX event. See
o.a.c.environment.internal for some such code. There is also a fair
amount of environment changing code in pipelines in the abandoned VPC
code
http://svn.apache.org/repos/asf/cocoon/whiteboard/virtual-processing-components/.
Kind of complicated I'm afraid. But handling of sitemap component
parameters is one of the more complicated areas in Cocoon.
WDYT?
/Daniel
