cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cziege...@apache.org
Subject cvs commit: xml-cocoon/xdocs sitemap.xml
Date Fri, 23 Mar 2001 13:51:05 GMT
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>&lt;map:filters&gt;</code>
specifies the type 
  -      of filter to use if none is specified in a pipeline.
  +      The <code>default</code> attribute on <code>&lt;map:transformers&gt;</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>&lt;map:choosers&gt;</code>
specifies the type 
  -      of chooser to use if none is specified in a pipeline.
  +      The <code>default</code> attribute on <code>&lt;map:selectors&gt;</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


Mime
View raw message