Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <46B5EFB0.9040108@nada.kth.se>
Date: Sun, 05 Aug 2007 17:41:36 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: What's the use of fillContext method
References: <46B254A8.2050604@tuffmail.com> <46B470CA.9050808@nada.kth.se>
 <46B5B18A.3010203@apache.org>
In-Reply-To: <46B5B18A.3010203@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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