> -----Original Message-----
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: maandag 10 november 2003 18:30
> To: [EMAIL PROTECTED]
> 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
