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 Tue, 07 Aug 2007 09:31:53 GMT
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/


Mime
View raw message