Sylvain Wallez wrote:
Sure I will. It would clearly be a bad thing to trash the time and effort Bering has put there. I may not have the required time to do it by myself, but I'm ready to answer questions. So maybe with the combined support of Berin and me we can turn this into a deeper knowledge of the sitemap engine for the whole group.
Berin, what's the major wall you hit in the TreeProcessor? AFAIU, Recomposable is a problem, but also something we can easily remove from the code with some light refactoring.
What are the other difficult points?
Thanks for continuing the discussion, Berin.
The TreeProcessor has a bunch of psuedo-components that are managed differently than the regular container. If these were all "threadsafe" components, there would be less of an issue here.
We should either make them regular components, and provide "configuration" snippets, or make them beans and provide the full configuration. THe problem areas might be where we need to access a component. For those, we might need to use a "Component Proxy" that gets the type of component we are looking for from a typed interface like this:
SitemapComponentProxy {
Generator getGenerator(String type);
Transformer getTransformer(String type);
Serializer getSerializer(String type);
Reader getReader(String type);
Action getAction(String type);//NOTE: sets can simply be a
//special action type with the same interface.
}
Anyhoo, the basic solution is to either build a tree/graph of pure components or a tree/graph of pure beans. Either solution will work. We need to get rid of the need for the LifecycleHelper type class. I would lean more toward the bean approach for assembling the actual pipelines. It might make things a bit simpler, even to make custom hard-coded sitemaps.
Processing nodes are organized in a tree and need to have some features devoted to components such as accessing the CM/SM or needing to perform some cleanup and thus being disposable.
This led to the current architecture since I considered that components could only be have a flat organisation. Now maybe I was wrong, and would like to know how we can build a clean tree of components (we're likely to need this in Woody as well).
I'll be out of office tomorrow and it's currently late here (11:30pm), but I will continue this thread as soon as time permits.
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
