Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <46B9B7B2.8000701@reverycodes.com>
Date: Wed, 08 Aug 2007 08:31:46 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
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> <46B5EFB0.9040108@nada.kth.se>
 <46B83C09.6080400@apache.org>
In-Reply-To: <46B83C09.6080400@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Grzegorz Kossakowski wrote:
> Daniel Fagerstrom pisze:
>> 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.

Can you explain what are those 'component parameters' to be made available 
during pipeline execution? Do they exist in 2.1?


>> 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?

It looks *very* heavy, especially since it's done for *each* sax event on *each* 
step of the pipeline. I'd like to avoid doing stuff like this as far as possible.

Vadim