So I decided to consider another approach, based on an evaluation tree (hence TreeProcessor), each node in the tree corresponding to a xxxmap instruction (sitemap or flowmap).
I think this is still a valid thing.
An additional motivation for me was that it would require me to heavily use the Avalon concepts and therefore increase my knowledge in this area. This was mostly written at home, and my wife deserves many thanks, because this thing took my brain day and night for more than 2 months ;-)
She is a saint :)
So the TreeProcessor configuration contains the definition of TreeBuilder implementations for various "languages", the sitemap being the only one we have today. The whole configuration document is actually a ComponentSelector for TreeBuilder implementations. The SitemapLanguage class is the implementation of TreeBuilder for the sitemap language. A TreeBuilder builds a processing node tree based on a file (e.g. sitemap.xmap) that is read in an Avalon configuration (this was chosen for its ease of use compared to raw DOM).
Works for me.
<fortress-migration>
Obviously, this initial selector can be removed and the sitemap language be the only one available, as we now have the flowscript and it's very unlikely that we will redesign a new pipeline language in the near (or even distant) future.
</fortress-migration>
Well, even if we remove the dependency on the selector, we can still have more than one available. We will just lookup the builder based on a concatenated string like this:
TreeBuilder builder = (TreeBuilder)m_manager.lookup(TreeBuilder.ROLE
+ "/sitemap");Or whatever language we want. Really, we don't need the selector at all anymore. It is really only provided for back compatibility. BTW, the default component is without any "/" + hint appended to the role.
Roles, selectors and <map:components> -------------------------------------
The <map:components> section of a sitemap is used to configure a ComponentManager (child of either the parent sitemap's manager or the main manager), and the <roles> section of the TreeProcessor configuration defines a RoleSelector that is used by this manager. For the sitemap, it defines the shorthands that will map <map:generators>, <map:selectors>, etc, to a special "ComponentsSelector" (yeah, the name could be better).
This ComponentsSelector handles the <map:components> syntax ("src" and not "class", etc), and holds the "default" attribute, view labels and mime types for each hint (these are not know by the components themselves).
<fortress-migration>
AFAIU, Fortress allows defaults for a collection of components implementing the same role, but I don't know how we can handle the additional "label" and "mime-type", which are not handled by the component itself.
Can we imagine a "fake" selector that route calls to select() to the manager and handle these additional information on its own?
</fortress-migration>
There are ways. Building a container definition with all the associated components would help. The fact that we would be working within a container provides us access to the meta data in a better way. We'll have to put a little brain power to this.
Building the processing tree ----------------------------
<fortress-migration>
An optimisation that is done and may be relevant to migration to Fortress is that ThreadSafe components are looked up as part of the tree building and never looked up again later (see e.g. MatchNode). AFAIU, lifestyle interface no more exist with Fortress, so this optimisation may be difficult to do, if not impossible.
</fortress-migration>
Fortress support "singleton" components wich are the new way of declaring the ThreadSafe component. BTW, If no lifestyle is declared for a component, Fortress still falls back to interpreting the marker interfaces for compatibility's sake.
Phew... I finally explained the whole thing in depth. I'm no more the only one to know ;-)
I'll also put this into the wiki.
:) And did a really good job too. A WIKI would be really good. Is it there yet? Is it there yet? ;P
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin