cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Overview of Treebuilder/Sitemap Builder?
Date Fri, 24 Oct 2003 16:41:16 GMT
Sylvain Wallez wrote:

> 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


Mime
View raw message