cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: Migrating TreeProcessor to Fortress
Date Mon, 10 Nov 2003 20:27:03 GMT

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
> Sent: maandag 10 november 2003 18:30
> To: dev@cocoon.apache.org
> Subject: Re: Migrating TreeProcessor to Fortress
> 
> 
> Unico Hommes wrote:
> 
> >>Sorry, but I'm a bit lost here. Aren't we mixing processing 
> nodes and 
> >>sitemap components alltogether?
> >>    
> >>
> >
> >Yes, we can host them in the same container. Can't think of a reason 
> >not to. In order to make this more secure so that for 
> instance a Matcher can't get hold of a CallNode we could make 
> these two categories available from different ServiceManagers 
> that's all.
> >  
> >
> 
> Ok. So the "configuration expansion" is about expanding the 
> contents of 
> treeprocessor-builtins.xml and not that of <map:components>.
> 

Not really. The <nodes> section of the treeprocessor-builtins.xml
defines what are the builder classes of the different sitemap nodes.
It's for configuring a RoleManager for sitemap node builders. In
Fortress this type of information will be declared in the avalon meta
tags.

A sitemap in my proposition is a container configuration, just like
cocoon.xconf is a container configuration for global components:
declaring what components the container should deploy and how these
components are to be configured. The sitemap defines the components and
their configurations:

<map:sitemap>
  <map:components />
  <map:pipelines>
    <map:pipeline>
      <map:match pattern="...">
        ...
      </map:match>
    </map:pipeline>
  </map:pipelines>
</map:sitemap>

Which, for the purpose of Fortress can be translated into:

<pipeline id="p1">
  <match ref-id="p1-m1" />
</pipeline>

<match id="p1-m1" pattern="..." />

Here we have a 'pipeline' component - the implementation class could be
o.a.c.components.treeprocessor.language.PipelineNode - with one
configuration element: <match ref-id="p1-m1" /> which tells the
PipelineNode that it has one child that can be looked up from the
ServiceManager under the key
"org.apache.cocoon.components.treeprocessor.sitemap.MatchNode/p1-m1".
This MatchNode in turn has its own configuration: an attribute 'pattern'
with value "..." etc.

With this flattening out of the sitemap tree into a more traditional
container configuration the NodeBuilders are no longer necessary.

> Now, next step: how do you solve the problem of statements 
> that produce 
> different kinds of nodes, such as <map:call> ?
> 

* o.a.c.c.treeprocessor.sitemap.CallFunctionNode.java:

/**
 * @avalon.component
 * @avalon.service      type="ProcessingNode"
 * @x-avalon.info       name="call-function"
 * @x-avalon.lifecycle  type="singleton"
 */
public class CallFunctionNode implements ProcessingNode {
  public boolean invoke() {
     ...
  }
}

* o.a.c.c.treeprocessor.sitemap.CallResourceNode.java:

/**
 * @avalon.component
 * @avalon.service      type="ProcessingNode"
 * @x-avalon.info       name="call-resource"
 * @x-avalon.lifecycle  type="singleton"
 */
public class CallResourceNode implements ProcessingNode {
  public boolean invoke() {
     ...
  }
}

* sitemap.xmap:

<sitemap>
  <map:pipeline>
    <map:match pattern="...">
      <map:call function="..." />
    </map:match>
    <map:match pattern="...">
      <map:call resource="..." />
    </map:match>
  </map:pipeline>
</sitemap>

             sitemap2config.xsl
sitemap.xmap ------------------> sitemap-container.xconf

* sitemap-container.xconf:

<fortress>

 <pipeline id="p1">
  <match id-ref="p1-m1" />
  <match id-ref="p1-m2" />
 </pipeline>

 <match id="p1-m1">
  <call id-ref="p1-m1-c1" />
 </match>

 <match id="p1-m2">
  <call id-ref="p1-m2-c1" />
 </match>

 <call-function id="p1-m1-c1" function="..." />

 <call-resource id="p1-m2-c1" resource="..." />

</fortress>


Note that I've modeled the translation from sitemap to component
assembly using an XSL transformation. This task could well be handled by
a custom interpreter sitting between the two configuration views if that
would prove desirable.


Unico


> 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