cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Overview of Treebuilder/Sitemap Builder?
Date Sun, 26 Oct 2003 13:06:35 GMT
Berin Loritsch wrote:

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


Yeah, but then how do we define all the NodeBuilders associated to a 
particular language and ensure their definition does not mix with those 
of another language. By a concatened hint such as 
ProcessingNodeBuilder.ROLE + "/" + language + "/" + type, i.e. 
"....ProcessingNodeBuilder/sitemap/generate" ?

>> -------------------------------------
>>
>> 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>
>
> Roles, selectors and <map:components>
>
> 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.


So you mean that the creator of the container (here the TreeBuilder) can 
access metadata that are otherwise not accessible?

>> ----------------------------
>>
>> <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>
>
> Building the processing tree
>
> 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


http://wiki.cocoondev.org/Wiki.jsp?page=InterpretedSitemapInternals 
(sorry Nicola Ken, I overwrote your initial intro)

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



Mime
View raw message