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 13:34:47 GMT
Unico Hommes wrote:


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

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.

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.

Mmmh... more thinking is required here.


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

>>Performance considerations
>>When writing the TreeProcessor, great care was taken to pre-analyse everything that
is possible to achieve maximum runtime speed. I currently found only two performance degradation
points with this new approach:
>>- it's not possible to choose the ProcessingNode implementation depending on the class
of a component as, e.g. in MatchNodeBuilder. The cost is finally just an "instanceof" check
to choose the right behaviour.
>Are you talking about Matcher/PrepareableMatcher pair?


>Not sure why polimorphism should break here?

It would not break: what I'm saying is that in the TreeProcessor, the 
actual ProcessingNode implementation class depends on the runtime class 
of the matcher. With the new approach, this would mean that we can 
lookup the matcher within the flattening transformation to produce a 
different ProcessingNode declaration (i.e. <prepared-match> instead of 
<match>). But since the matcher declaration is built in the same 
transformation process, we cannot know the matcher class.

That's why we cannot have different ProcessingNode implementations for a 
single kind of sitemap statement depending on the runtime class of the 
underlying component. But that's not really a problem, as the runtime 
cost will be negligible.


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


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

>>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 ;-)


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

View raw message