cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] ComponentizedProcessor (was RE: Migrating TreeProcessor to Fortress)
Date Wed, 12 Nov 2003 14:59:20 GMT
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]

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

> Mmmh... more thinking is required here.
> <snip/>
>>> Side note: relative URIs
>>> ------------------------
>>> The various considerations about inheritance above leads to the 
>>> question of resolution of relative source URI (Carsten raised this 
>>> issue some time ago): what is the base URI that should be used by 
>>> the resolver?
>>> My opinion is that the base URI should be the one of the sitemap 
>>> _handling_ the request. This means that "jumping" to another sitemap 
>>> through virtual components or view inheritance should not affect the 
>>> base URI.
>>> However, there are many situations where we want to use a source 
>>> relative to the _current_ sitemap regardless on how it's called. For 
>>> this, I propose a new protocol similar to how "context:" behaves 
>>> with the root sitemap, but for non-root sitemaps. The "sitemap:" 
>>> protocol comes to mind, but I'm not sure this is a good name.
>> 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.


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


>>> Conclusion
>>> ----------
>>> This new approach seems to have very few drawbacks (hope I did not 
>>> miss something important), and will lead to a dramatic 
>>> simplification of the sitemap engine. The most noticeable one being 
>>> that the number of classes will be divided by 2.
>> Cool I am glad you say this. I was starting to think I was just 
>> shooting my mouth off. (Which off course I was but somehow turned out 
>> alright ;-)
> Sometimes, wild idea that others do not answer prove to have a great 
> future. An noticeable example is the flowscript: Ovidiu started to 
> hack some Lisp in a little corner of the scratchpad, and this led to a 
> major new feature!

True. The benefit of this community is that nobody is really attached 
to his/her code. We value challenges and wild thinking more than we 
value self pride.

I'm happy (but this feeling is shared by everyone around here) 
everytime I'm proven wrong and I can learn something, or improve my 
reasoning, my code or my behavior.

So, keep it up ;-)

> <snip/>
>> I agree with Carsten that we should develop it in 2.2 and see later if
>> we can port it to ECM so it's useable from 2.1 as well.
> Ok. A backport is always possible.

+1 for 2.2 as well!

>>> And I also think we should consider this approach when migrating 
>>> Woody to CocoonForms, since Woody uses the same mechanism than the 
>>> TreeProcessor to build a widget definition trees.
>>> Thanks again Unico for this brillant idea.
>> Actually, Sylvain, I wasn't trying to solve all the things you said 
>> this idea now solves. Nope, don't blame me ;-)
> Well, so just go on throwing wild ideas and let others analyze their 
> potential implications ;-)

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

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


View raw message