cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)
Date Wed, 12 Nov 2003 15:47:03 GMT
Stefano Mazzocchi wrote:

> As a general feeling, I like what I see.
> A few comments inside.
> On 12 Nov 2003, at 14:34, Sylvain Wallez wrote:
>> Unico Hommes wrote:
>> <snip/>
>>>> 1/ Virtual components
>>>> Virtual components are sitemap snippets that can be used in place 
>>>> of "regular" components. I many languages, these are called 
>>>> "macros". With sitemap statements as components, virtual components 
>>>> are a breeze to implement: just lookup the component, and see if 
>>>> what's returned is a regular sitemap component (e.g. a Serializer) 
>>>> or if it's a ProcessingNode. If it's a regular sitemap component, 
>>>> add it to the pipeline, and otherwise invoke the ProcessingNode.
>>>> What I'm not sure about here, is if its possible (or even 
>>>> desirable) that we can have two different implementation interfaces 
>>>> for a single role.
>>> The problem with Fortress here is that it forces the role to be the 
>>> implementation interface. It is also due to the way Fortress handles 
>>> meta data.
>>> Can't virtual components just implement their respective pipeline 
>>> component interfaces: Transformer, Generator, Serializer? This way 
>>> we'd treat them just as regular pipeline components.
>> The problem of virtual components is that they have to add components 
>> to the pipeline that's being built (e.g. a virtual serializer will 
>> add zero or more transformers and a serializer).
> Why don't we use virtual component just like what they are: an 
> assembly of components that, from the outside, look just like another 
> component? it feels like we hardwire the various components into one 
> an expose that as it was a regular component.
> Sounds elegant to me.
>> The only way in which they can implement the regular interface (e.g. 
>> Serializer) is by creating a local internal pipeline that will be 
>> connected to the global one. But it looks like going this way will 
>> require heavy complex changes in the pipeline machinery that I think 
>> should be avoided.
> I'm might be underestimating the required changes, but why is it so? 
> [curious more than anything]

Well, for now its mainly a feeling brought by some questions raised 
while considering these "internal pipelines":
- which pipeline implementation should be chosen (caching, non-caching, 
etc)? I would say that the sitemap that "drives" request processing 
defines it, but how can internal pipelines know it if we only go through 
e.g. the Serializer interface?
- currently, a pipeline object represents the whole processing chain, 
from generator to serializer. With internal pipelines, they'll need to 
accept to be "partial processing chains", i.e. missing either a 
generator or a serializer.

Your "hardwiring" proposal may be a simple solution to this, by avoiding 
the need for real pipelines. But it also means that we loose the 
features of profiling-pipeline, cachingpoint-pipeline and maybe the 
sitemap debugger inside virtual components.

So, as I said, more thinking is needed...

>> So the immediate - but looking hacky - solution that comes to mind is 
>> for virtual components to implement the regular component interface 
>> for the sake of Fortress compatibility, but refuse the corresponding 
>> methods (throw UnsupportedOperationException) and implement an 
>> additional "VirtualComponent" interface that provides a 
>> buildPipeline(Pipeline) method.
> Yuck!! there must be a better way of doing this, c'mon!

I agree with you, this is hacky. We may consider this as a quick'n'dirty 
preliminary implementation allowing us to learn how to design correctly 
this internal pipeline stuff.


>>> Wild idea: context:/ identifies the current context, context:// 
>>> identifies the root sitemap? Like in cocoon: protocol?
>> Great idea (again!). Currently, the "context:" protocol requires the 
>> double-slash and links to the root sitemap, so we can implement this 
>> additional behaviour with a single slash with no compatibility break. 
>> And the similarity with "cocoon:" makes it easy to understand.
> +1
>> This makes me think that "cocoon:" must also be be relative to the 
>> "current" sitemap, and not that handling the request.
> Uh? this is not the case already? if so, +1 for the change.

This is implicitely the case today, as a single sitemap fully builds the 
pipeline. But with virtual components, views and resource inheritance, 
pipeline assembly will be split over many sitemaps. Hence the need to 
define what is the base URI in that case.


> Ok, now the admin part: Sylvain, Unico, are you volunteering to 
> implement all this? ;-)

Sure! One more thing on my super-loaded schedule, but I think my 
knowledge of the current implementation can be of great help. And it's 
also a important step towards blocks.

> Berin, do you have a little time to help them on Fortress needs would 
> they emerge?

Yes, please. It would be interesting also that you somehow validate this 
way of doing things (flattening the evaluation tree and considering 
every statement as a component).


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message