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.
<snip/>
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.
<snip/>
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
