You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cz...@apache.org on 2001/03/23 14:51:05 UTC
cvs commit: xml-cocoon/xdocs sitemap.xml
cziegeler 01/03/23 05:51:05
Modified: xdocs Tag: xml-cocoon2 sitemap.xml
Log:
Renamed filters to transformers, Choosers to Selectors and added mount mail threads
Revision Changes Path
No revision
No revision
1.1.2.7 +270 -51 xml-cocoon/xdocs/Attic/sitemap.xml
Index: sitemap.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/Attic/sitemap.xml,v
retrieving revision 1.1.2.6
retrieving revision 1.1.2.7
diff -u -r1.1.2.6 -r1.1.2.7
--- sitemap.xml 2001/01/04 22:39:35 1.1.2.6
+++ sitemap.xml 2001/03/23 13:51:04 1.1.2.7
@@ -126,9 +126,9 @@
<![CDATA[
<map:components">
<map:generators/>
- <map:filters/>
+ <map:transformers/>
<map:serializers/>
- <map:choosers/>
+ <map:selectors/>
<map:matchers/>
</map:components">
]]>
@@ -169,9 +169,9 @@
<source>
<![CDATA[
<map:components>
- <map:filter type="xslt" src="class:///org.apache.cocoon.filter.XSLTFilter">
- <compile-stylesheets value="true"/> <!-- This is a parameter to the filter component -->
- </map:filter>
+ <map:transformer type="xslt" src="class:///org.apache.cocoon.transformation.XSLTTransformer">
+ <compile-stylesheets value="true"/> <!-- This is a parameter to the transformer component -->
+ </map:transformer>
</map:components>
]]>
</source>
@@ -214,26 +214,26 @@
</s3>
- <s3 title="Filters">
+ <s3 title="Transformers">
<p>
- A <link href="#interface-filter"><code>Filter</code></link> transform SAX events in SAX events.
+ A <link href="#interface-transformer"><code>Transformer</code></link> transform SAX events in SAX events.
</p>
<source>
<![CDATA[
- <map:filters default="xslt">
- <map:filter type="xslt" src="class:///org.apache.cocoon.filter.XSLTFilter">
+ <map:transformers default="xslt">
+ <map:transformer type="xslt" src="class:///org.apache.cocoon.transformation.XSLTTransformer">
<compile-stylesheets value="true"/>
- </map:filter>
- <map:filter type="xinclude" src="class:///org.apache.cocoon.filter.XIncludeFilter"/>
- </map:filters>
+ </map:transformer>
+ <map:transformer type="xinclude" src="class:///org.apache.cocoon.transformation.XIncludeTransformer"/>
+ </map:transformers>
]]>
</source>
<p>
- The <code>default</code> attribute on <code><map:filters></code> specifies the type
- of filter to use if none is specified in a pipeline.
+ The <code>default</code> attribute on <code><map:transformers></code> specifies the type
+ of transformer to use if none is specified in a pipeline.
</p>
</s3>
@@ -280,39 +280,39 @@
</p>
</s3>
- <s3 title="Choosers">
+ <s3 title="Selectors">
<p>
- A <link href="#interface-chooser"><code>Chooser</code></link> evaluate a boolean expression.
+ A <link href="#interface-selector"><code>Selector</code></link> evaluate a boolean expression.
</p>
<source>
<![CDATA[
- <map:choosers default="browser">
- <map:chooser type="load" src="class:///org.apache.cocoon.chooser.MachineLoadChooser">
+ <map:selectors default="browser">
+ <map:selector type="load" src="class:///org.apache.cocoon.selection.MachineLoadSelector">
...
- </map:chooser>
+ </map:selector>
- <map:chooser type="user" src="class:///org.apache.cocoon.chooser.AuthenticationChooser">
+ <map:selector type="user" src="class:///org.apache.cocoon.selection.AuthenticationSelector">
...
- </map:chooser>
+ </map:selector>
- <map:chooser type="browser" factory="class:///org.apache.cocoon.matcher.BrowserChooserFactory">
+ <map:selector type="browser" factory="class:///org.apache.cocoon.selection.BrowserSelectorFactory">
...
- </map:chooser>
- </map:choosers>
+ </map:selection>
+ </map:selection>
]]>
</source>
<p>
- The <code>default</code> attribute on <code><map:choosers></code> specifies the type
- of chooser to use if none is specified in a pipeline.
+ The <code>default</code> attribute on <code><map:selectors></code> specifies the type
+ of selector to use if none is specified in a pipeline.
</p>
<p>
Because the sitemap will be translated and compiled into a java class at runtime a
- <link href="#interface-chooser"><code>Chooser</code></link> can specify a attribute <code>factory</code>
- instead of a <code>src</code>. This <link href="#interface-chooser-factory"><code>ChooserFactory</code></link>
+ <link href="#interface-selector"><code>Selector</code></link> can specify a attribute <code>factory</code>
+ instead of a <code>src</code>. This <link href="#interface-code-factory"><code>CodeFactory</code></link>
class must be capable to return a java source code fragment that can be embedded into a method corresponding
- to the <link href="#interface-chooser"><code>Chooser</code></link>s evaluate method.
+ to the <link href="#interface-selector"><code>Selector</code></link>s evaluate method.
</p>
</s3>
@@ -371,9 +371,9 @@
<![CDATA[
<map:resources>
<map:resource name="Access refused">
- <map:generator src="./error-pages/restricted.xml"/>
- <map:filter src="./stylesheets/general-browser.xsl"/>
- <map:serializer status-code="401"/>
+ <map:generate src="./error-pages/restricted.xml"/>
+ <map:transform src="./stylesheets/general-browser.xsl"/>
+ <map:serialize status-code="401"/>
</map:resource>
</map:resources>
]]>
@@ -414,9 +414,9 @@
<source>
<![CDATA[
<map:components>
- <map:filter type="xslt" src="class:///org.apache.cocoon.filter.XSLTFilter">
- <compile-stylesheets value="true"/> <!-- This is a parameter to the filter component -->
- </map:filter>
+ <map:transformer type="xslt" src="class:///org.apache.cocoon.transformation.XSLTTransformer">
+ <compile-stylesheets value="true"/> <!-- This is a parameter to the transformer component -->
+ </map:transformer>
</map:components>
]]>
</source>
@@ -460,6 +460,221 @@
</s3>
</s2>
</s1>
+
+ <s1 title="Pipelines">
+ <s2 title="Mounting sitemaps">
+ <p>
+ The following is taken from a mail thread in the cocoon developer mailing list between
+ Giacomo Pati and Colin Britton:
+ </p>
+<source>
+<![CDATA[
+Giacomo Pati wrote:
+> Colin Britton wrote:
+> >
+> > > > Can a map:mount be inside a map:select like this...
+> > <snip/>
+> > > From the sitemap.xsl logicsheet there is no limitation on where a
+> > > map:mount should be and thus are free to place it where you want.
+> > <snip/>
+> > > Well, haven't thought about replacing the root URI with different
+> > > sitemaps but I'd like you to test it and report your experience on this
+> > > list :)
+> >
+> > So here goes. The aim of my tests was to see how the sitemap mount function
+> > could be used to simplfy the creation and management of cocoon2 based sites
+> > and applications. We have a good size server (quad processor PIII server
+> > with plenty of ram and HD) and wish to deploy multiple clents work and
+> > multiple applications on the same box. Now we could (and will) setup
+> > multiple http servers and therefore multiple servlet environments and
+> > multiple Cocoon applications. But this creates a lot of admin and
+> multiple
+> > versions of items and all the heartache that comes with it.
+> >
+> > I wanted to see if we could solve the following problems within the
+> cocoon
+> > environment.
+> >
+> > 1) Simplify site construction
+> > 2) Reduce risk of "bad' sitemap entries killing whole site
+> > 3) Ease deployment of pre-built applications
+> > 4) Keep sitemap files an understandable and manageable size
+> >
+> > The short answer is that the sitemap and in particular the mount function
+> > does a good job of meeting my goals.
+>
+> What we allways thought of it should be but never were able to test it
+> so far :)
+>
+> > My test was such.
+> >
+> > I build a main sitemap, for C2 to load This sitemap is the minimum it
+> > needs.
+> > A matcher and a selector. These two components allow me to select and
+> > direct
+> > to mount two other site maps.
+> >
+> > These sub-sitemaps load the componants they need (which includes
+> > generators
+> > and transformers etc...) and have the map elements for that
+> > site/application.
+>
+> Take into account that sitemap components (generators, transformers,
+> etc.) in a sitemap are accessible by a sub-sitemap by their names. This
+> is due to the fact that each sitemap has its own SitemapComponentManager
+> and they are arranged in the same hierarchical structure as the sitemaps
+> are and thus knows which are their parent SitemapComponentManager and
+> can ask it for a SitemapComponent it doesn't know about.
+>
+> > The benefit is that each sitemap is completely independant of each other
+> > and
+> > any error in that sitemap does not kill any other sitemap. This seems to
+> > work pretty well. I ran this up and deliberatly broke a sitemap and the
+> > other one still ran.
+>
+> But usually you use the same SitemapComponents over and over again in
+> your sub-sitemaps. And because you have a contract between the parent
+> and sub sitemaps (the uri-prefix) you can deliver common
+> SitemapComponents from the parent sitemap to your sub-sitemaps as well.
+>
+> Also note that if you break a sitemap all its sub-sitemaps are broken as
+> well (because of the hierarchical arragement).
+>
+> > The benefit is I can build a seperate app or site on another machine,
+> > test
+> > it offline and deploy it on the main server with minimal risk and
+> > distruption. A huge win.
+>
+> This is why sub sitemaps were introduced: scalability.
+>
+> SIDENOTE: This is why there is an EntityResolver argument in the
+> signature of the SitemapModelComponent interface. When a subsitemap is
+> mounted the sitemap engine reports the uri-prefix and the context (src)
+> to the calling Environment (changeContext method) so that
+> SitemapComponent (i.e. URIMatcher) requesting a URI don't see the prefix
+> and if for example a generator needs to resolve an src resource the
+> EntityResolver (implemented by the calling Environment) is responsible
+> to resolve that to the changed context the subsitep is in.
+>
+> > Here is my main sitemap. You will notice that I am using a selector that
+> > matches on host name of the request, but any matcher or selector would
+> > work
+> > at this point. I am mounting both sub-sitemaps at the root level.
+> >
+> > <?xml version="1.0"?>
+> > <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
+> > <!-- =========================== Components
+> > ================================ -->
+> > <map:components>
+> > <map:matchers default="wildcard">
+> > <map:matcher name="wildcard"
+> > factory="org.apache.cocoon.matching.WildcardURIMatcherFactory"/>
+> > </map:matchers>
+> >
+> > <map:selectors default="host">
+> > <map:selector name="host"
+> > factory="org.apache.cocoon.selection.HostSelectorFactory">
+> > <host name="fee" value=www.foo.com/>
+> > </map:selector>
+> > </map:selectors>
+> >
+> > </map:components>
+> > <!-- =========================== Pipelines
+> > ================================= -->
+> > <map:pipelines>
+> > <map:pipeline>
+> >
+> > <map:select type="host">
+> > <map:when test="fee">
+> > <map:mount uri-prefix="" src="fee.xmap"/>
+> > </map:when>
+> > <map:otherwise>
+> > <map:mount uri-prefix="" src="foo.xmap"/>
+> > </map:otherwise>
+> > </map:select>
+> >
+> > </map:pipeline>
+> > </map:pipelines>
+> > </map:sitemap>
+> > <!-- end of file -->
+>
+> This is cool. Mounting different sitemaps on to the root URI :)
+>
+> > So this is a cool way to build out a cocoon2 app/site.
+> >
+]]>
+ </source>
+ <p>
+ The following is taken from a mail thread in the cocoon developer mailing list between
+ Giacomo Pati and Carsten Ziegeler:
+ </p>
+ <source>
+<![CDATA[
+Giacomo Pati wrote:
+> Carsten Ziegeler wrote:
+> > I am currently playing a little bit with mounting subsitemaps.
+> > After a while I got it working now, but I am still wondering
+> > what the exact purpose of the attributes uri-prefix and src is.
+> >
+> > I used the following mount-example from the sitemap draft:
+> >
+> > <map:match pattern="dist/*">
+> > <map:mount uri-prefix="dist/" src="dist/{1}"/>
+> > </map:match>
+> >
+> > This generates the following source:
+> >
+> > return sitemapManager.invoke (environment,
+> > substitute(listOfLists, "dist/"),
+> > substitute(listOfLists, "dist/{1}"), true);
+>
+> The uri-prefix is the part that should be removed from the request URI.
+> The engine will correctly check for a trailing slash (which you may
+> write, of course)
+>
+> The src attribute is where the subsitemap is located. If it ends in a
+> slash "sitemap.xmap" is appended to find the sitemap otherwise the src
+> value is used. A check-reload attribute can be used to determine if the
+> modification date of the subsitemap file should be checked. A mount
+> element I use looks like:
+>
+> <map:mount uri-prefix="sub" src="sub/" check-reload="yes"/>
+> or
+> <map:mount uri-prefix="sub/" src="sub/subsitemap.xmap"
+> check-reload="no"/>
+>
+> > The third argument ("substitute(listOfLists, "dist/{1}")") is the
+> > source argument for the sitemap handler to load the new sitemap.
+> > So if I try to load the resource "dist/hello" the sitemap
+> > "dist/hello/sitemap.xmap" is tried to loaded. When I try to load
+> > "dist/welcome" the sitemap "dist/welcome/sitemap.xmap" is tried
+> > to loaded. And so on.
+> >
+> > So I assume from this, that the "src" attribute indicates the location of
+> > the subsitemap.
+> > This would lead to:
+> >
+> > <map:match pattern="dist/*">
+> > <map:mount uri-prefix="dist/" src
+> > ="dist/subsitemap.xmap"/>
+> > </map:match>
+> >
+> > The "uri-prefix" seems to be the part which has to be removed from the
+> > uri,
+> > this means sending the request "dist/welcome" will remove "dist/" from
+> > the
+> > uri and only "welcome" is passed to the subsitemap.
+> > So I could use
+> > <map:match pattern="hallo">
+> > <map:generate src="test.xml"/>
+> > <map:serialize type="xml"/>
+> > </map:match>
+> > in the "dist/subsitemap.xmap" to match the request.
+]]>
+ </source>
+
+ </s2>
+ </s1>
<s1 title="Interface specifications">
<anchor id="interface-XMLProducer"/>
@@ -541,15 +756,15 @@
</source>
</s2>
- <anchor id="interface-filter"/>
- <s2 title="Filter">
+ <anchor id="interface-transformer"/>
+ <s2 title="Transformer">
<p>
- A <code>Filter</code> must implement at least the following interface:
+ A <code>Transformer</code> must implement at least the following interface:
</p>
<source>
<![CDATA[
- public interface Filter extends XMLProducer, XMLConsumer, SitemapComponent {
+ public interface Transformer extends XMLProducer, XMLConsumer, SitemapModelComponent {
}
]]>
</source>
@@ -575,41 +790,45 @@
</source>
</s2>
- <anchor id="interface-chooser"/>
- <s2 title="Chooser">
+ <anchor id="interface-selector"/>
+ <s2 title="Selector">
<p>
- A <code>Chooser</code> gets a expression to evaluate and signals the evaluation with a
+ A <code>Selector</code> gets a expression to evaluate and signals the evaluation with a
boolean value.
</p>
<source>
<![CDATA[
- public interface Chooser implements Component {
- public boolean evaluate(...);
+ public interface Selector implements Component {
+ boolean select (String expression, Map objectModel);
}
]]>
</source>
</s2>
- <anchor id="interface-chooser-factory"/>
- <s2 title="ChooserFactory">
+ <anchor id="interface-code-factory"/>
+ <s2 title="CodeFactory">
<p>
- A <code>ChooserFactory</code> is capable to return the java source code of the evaluate method of a
- <link href="#interface-chooser"><code>Chooser</code></link> object. It gets the value of the test
+ A <code>CodeFactory</code> is capable to return the java source code of the evaluate method of a
+ <link href="#interface-selector"><code>Selector</code></link> object. It gets the value of the test
attribute from the sitemap.
</p>
<source>
<![CDATA[
- public interface ChooserFactory {
- public String generateCode(String test);
+ public interface CodeFactory {
+ String generateParameterSource (NodeList conf);
+
+ String generateClassSource (String prefix, String test, NodeList conf);
+
+ String generateMethodSource (NodeList conf);
}
]]>
</source>
</s2>
<anchor id="interface-matcher"/>
- <s2 title="Chooser">
+ <s2 title="Matcher">
<p>
A <code>Matcher</code> gets the <code>OutputStream</code> where the XML should
be serialized with the following interface:
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org