Daniel Fagerstrom pisze:
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.
Done r562896.
I'm already moving most of the code of Template and Flow Object Model
helpers.
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.
Since I wanted to remove FlowObjectModelHelper class completely I moved
fillContext() method to the ObjectModel interface. I think this
method is closely related to the actual ObjectModel usage and we should not
have to seek for it in helper classes.
When it comes to parameters I was going to move this one line to the code of
generator itself. I don't see value of having one-liner method.
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?
I was thinking about the same but since I have other goals (like evaluating
expressions in sitemap) I decided to give a rest whole idea.
It's not that hard to put this one line in component's setup/generate method so
parameters are available in ObjectModel.
What much more important is below, *shiver*...
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?
I fear that I have overlooked whole that you brought above and it's not
handling of parameters availability in ObjectModel for sitemap
components :-(
Current design of ObjectModel works well in Stack-like environments when each
local context lives on top of another one. It will broke
miserably when used in few components in the same pipeline.
Let's suppose first component puts parameters to ObjectModel on its own during setup phase, then second component would do the same and thus
cover parameters from first component making them unavailable. I forgot the way pipeline components are executed, thanks for reminding and
pointing out this issue.
My gut feeling is that EnvironmentChanger will not be a piece of cake,
unfortunately.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
