cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [Ann/RFC] Virtual Sitemap Components
Date Tue, 12 Apr 2005 12:46:04 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>> Sylvain Wallez wrote:
>>> Sorry, not much time to dig into the implementation for now, but I 
>>> will :-)
>> Good :)
> In order to have a better opinion on the naming issue (virtual-blah / 
> special src="..." / no src) I started digging in the implementation.
> VPCs aren't an easy problem, and what follows isn't a criticism of the 
> hard work that's been done but a desire to have a robust implementation. 

Don't worry, without feedback it is hard to learn anything. And the more 
community involvement, the better IMO.

> This may also bring some light on this naming issue.
>                                 -- oOo --
> First of all, let's detail the process that happens to build and use 
> VPCs.
> 1 - TreeBuilder creates the TreeProcessor
> 1.1 - A service manager is built with the contents of <map:components>
> 1.1.1 - This manager has its own Avalon context object, that inherits 
> the context of the parent service manager
> 1.1.2 - Some of these components are VPCs. Important point: these are 
> pooled components for which no instance is created at this time.
> 1.2 - The TreeBuilder crawls the sitemap program to build the 
> ProcessingNode tree
> 1.2.1 - parsing of <map:components> invokes VPCNodeBuilder that stores 
> the processing node for a VPC in the Avalon context (see 1.1.1)

I felt a little bit unsure of the life cycle aspects of storing the 
ProcessingNode in the Avalon Context and considered puting them in the 
TreeProcessor instead, then they could be found by searching first the 
current processor, and if not found the parent processor and so on. As 
it would have required a little bit more work and the code I started 
from stored it in the node in the Avalon Context, I decided to continue 
that way and wait for your and others feedback.

I would prefer not using the Avalon Context for this.

> 2 - TreeProcessor is invoked to build a pipeline
> 2.1 - The processing tree is executed and feeds a pipeline object with 
> pipeline components
> 2.2 - The pipeline object looks up pipeline components
> 2.2.1 - VPCs are instanciated and get their processing node from the 
> Avalon context (they've been put there in 1.2.1)
> 2.3 - The pipeline calls setup() on pipeline components
> 2.3.1 - VPCs invoke their processing node to build their partial pipeline
> 2.4 - The pipeline calls generator.generate().
>                                 -- oOo --
> A first important point: the current implementation relies on the fact 
> that VPCs are pooled and that no instance is created at startup. 
> Should some instances be pre-allocated at startup, they will fail in 
> getting their processing node and throw an exception. Fixing this 
> mostly requires to get the processing node later in the lifecycle, 
> e.g. in setup(), so that's not much a problem.


>                                 -- oOo --
> What we see here is that VPCs aren't regular components from the way 
> their "configuration" is parsed. This configuration isn't parsed by 
> the component itself, but by the surrounding environment which is the 
> TreeProcessor.
> Considering the way component declaration includes are handled today 
> (parsing included sources on the fly rather than building a large 
> single expanded configuration), this means that VPC declarations must 
> be kept in the sitemap file and cannot be located in included files. 
> Users have to be clearly warned about this unless we refactor the 
> include mechanism.
> The service manager in 2.2 allows for a flat fortress-style naming of 
> components and the enclosing elements for selectors is useless when 
> individual components specify their class names (e.g. source factories 
> or input modules, but not datasources which use hints such as "jdbc" 
> or "j2ee"). What this means is that <map:generators> 
> <map:transformers> etc are useless and can potentially be omited. Now 
> the TreeProcessor specifically relies on them to build VPCs.
>                                 -- oOo --
> Nothing seriously blocking here, but a general feeling that sitemap 
> fragments used by VPCs are really of a different nature than component 
> configuration. IMO placing them in <map:components> is mixing 
> different concerns and may bring confusion and component management 
> problems in the future. You may consider this as FUD, but this isn't 
> my intent: I express my bad feelings about this.
>                                 -- oOo --
> So in the end, my opinion is that sitemap fragments for VPCs should be 
> declared in their own section of the sitemap, just as views, resources 
> and flows. Components for VPCs will be added to the ServiceManager by 
> the TreeBuilder (let's recall that TreeBuilder has full control on the 
> ServiceManager as it is the one that creates it).
> Rather than having TreeProcessor and ServiceManager mix their stuff in 
> a single <map:components>, this allows the TreeProcessor to augment 
> the ServiceManager with components that are aliased to their 
> corresponding processing nodes. Concerns a kept separate for the 
> sitemap writer, but remain unified as regular components from the 
> outside world.
> So, WDYT? 

I don't have any strong opinions about this. For the moment I don't 
think we should details (that could change) in the current 
implementation affect the syntax to much, and is leaning slightly 
towards Stefano's proposal.

But I would prefer waiti to decide about this until we have discussed 
how we want to handle components in blocks. There are several issues 
around that: Naming and look up scheme. Should we differ between 
internal and exposed components? Should it be possible to re export 
components from connected blocks etc.

There have been so many changes on component handling, with includes of 
booth components and roles and foregin component containers, so it seem 
to me that it could require an unified view rather than just discussing 
the various pieces. Maybe you or Carsten could summarize the recent 
adistions and give your view on future additions that you might have in 


View raw message