Return-Path: Delivered-To: apmail-xml-cocoon-cvs-archive@xml.apache.org Received: (qmail 70578 invoked by uid 500); 1 Oct 2001 03:15:55 -0000 Mailing-List: contact cocoon-cvs-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: cocoon-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list cocoon-cvs@xml.apache.org Received: (qmail 70569 invoked by uid 500); 1 Oct 2001 03:15:55 -0000 Delivered-To: apmail-xml-cocoon2-cvs@apache.org Date: 1 Oct 2001 03:14:14 -0000 Message-ID: <20011001031414.56648.qmail@icarus.apache.org> From: vgritsenko@apache.org To: xml-cocoon2-cvs@apache.org Subject: cvs commit: xml-cocoon2/xdocs docs-book.xml site-book.xml sitemap.xml xsp.xml X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N vgritsenko 01/09/30 20:14:14 Modified: documentation/xdocs sitemap.xml webapp/stylesheets/documents root2html.xsl xdocs docs-book.xml site-book.xml sitemap.xml xsp.xml Log: Patches from Jeff Turner [jeff@socialchange.net.au] Revision Changes Path 1.2 +104 -89 xml-cocoon2/documentation/xdocs/sitemap.xml Index: sitemap.xml =================================================================== RCS file: /home/cvs/xml-cocoon2/documentation/xdocs/sitemap.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- sitemap.xml 2001/09/28 13:41:29 1.1 +++ sitemap.xml 2001/10/01 03:14:13 1.2 @@ -91,7 +91,7 @@ - + @@ -105,7 +105,7 @@ + ]]> @@ -118,9 +118,9 @@

The versioning schema will be "major.minor" where major will be increased - by one each time a new release breaks back compatibility, while minor + by one each time a new release breaks backwards compatibility, while minor is increased each time a change has been made that doesn't create - back incompatible problems. + backwards compatibility problems.

@@ -146,48 +146,46 @@
name
-
The name attribute gives the component a reference which can be used to point to them in the pipeline section.
+
Gives the component an identifying name by which it may be referenced in the pipeline section.
src
-
Specifies class representing this component.
+
Specifies the class implementing this component.

- All components will be configured with parameters specified from their child elements at component instantiation time. - The name of the parameters is dependant of the component. The following example shows how to specify a - <use-store> parameter to a component: -

+ All components are configured with parameters specified in their child elements at component instantiation time. + The following example shows how to specify a <use-request-parameter> parameter for an XSLT + transformation component:

- - true + src="org.apache.cocoon.transformation.TraxTransformer"> + + false
]]> -

- There is no given set of predefined parameters. + The name and meaning of the parameters are dependent on the component.

- A Generator generates XML content as SAX events and initialize the - pipeline processing. + A Generator generates XML content as SAX events and initializes the pipeline processing.

- - - + + + + ... @@ -202,15 +200,16 @@

- A Transformer transform SAX events in SAX events. + A Transformer transforms SAX events into other SAX events.

- true + src="org.apache.cocoon.transformation.TraxTransformer"> + false + false @@ -226,7 +225,7 @@

- A Serializers transform SAX events + A Serializer transforms SAX events in binary or char streams for final client consumption.

@@ -234,7 +233,7 @@ + src="org.apache.cocoon.serialization.HTMLSerializer"> -//W3C//DTD HTML 4.0 Transitional//EN http://www.w3.org/TR/REC-html40/loose.dtd true @@ -243,19 +242,19 @@ + src="org.apache.cocoon.serialization.XMLSerializer"> -//WAPFORUM//DTD WML 1.1//EN http://www.wapforum.org/DTD/wml_1.1.xml UTF-8 + src="org.apache.cocoon.serialization.SVGSerializer"> + src="org.apache.cocoon.serialization.SVGSerializer"> ]]> @@ -269,8 +268,11 @@

- A Selector evaluate a boolean expression. -

+ A Selector is used to implement basic + conditional logic (if-then-else or switch) inside the sitemap. + As can be seen in the Selector + interface, this functionality decomposes into the ability to evaluate a boolean + condition.

@@ -286,6 +288,11 @@ + + + + + ... @@ -297,13 +304,14 @@ of selector to use if none is specified in a pipeline.

-

- Because the sitemap will be translated and compiled into a java class at runtime a +

+ Because the sitemap will be translated and compiled into a Java class at runtime, a Selector can specify a class implementing CodeFactory - instead of Selector interface. - This class must be capable to return a java source code fragment that can be embedded into a method corresponding - to the Selectors evaluate method. + instead of the Selector interface. + This class must be capable of returning a Java source code fragment that can be embedded into a + method corresponding to the Selector's + evaluate method.

@@ -313,14 +321,14 @@

- + + ... - + ... @@ -333,12 +341,13 @@

- Because the sitemap will be translated and compiled into a java class at runtime a + Because the sitemap will be translated and compiled into a Java class at runtime, a Matcher can specify a class implementing CodeFactory - instead of Matcher interface. - This class must be capable to return a java source code fragment that can be embedded into a method corresponding - to the Matchers match method. + instead of the Matcher interface. + This class must be capable of returning a Java source code fragment that can be embedded into + a method corresponding to the Matcher's + match method.

@@ -346,8 +355,9 @@

An Action is a sitemap component that manipulates runtime parameters based on request and application state. - Action's result is available in the sitemap as map of name/value pairs. - Detailed information on actions is here. + An Action's result is available in the sitemap as map of name/value pairs. + Detailed information on actions may be found in the Actions + section.

The <map:view> element defines different view of the site. Views are defined independent of pipelines and might - be used with any pipeline defined in the sitemap. More on views - read "Views". + be used with any pipeline defined in the sitemap. For more on views + read the Views section.

@@ -421,10 +431,10 @@ - +

The <map:action-set> element is used to arrange actions in - a groups (See "Actions" for details). + groups (See the Actions section for details).

@@ -449,11 +459,11 @@

Mount points allow sitemaps to be cascaded and site management workload to be parallelized. This creates a tree of sitemaps with - the main sitemap at the root and possibly several subsitemaps + the main sitemap at the root and possibly several sub-sitemaps as nodes and leaves.

-

The subsitemaps serve two important goals: scalability and - simplification of maintainance. The different subsitemaps are independent +

The sub-sitemaps serve two important goals: scalability and + simplification of maintenance. The different sub-sitemaps are independent and don't affect each other.

@@ -464,20 +474,20 @@ ]]>

- 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 + The src attribute is where the sub-sitemap 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. + modification date of the sub-sitemap file should be checked. 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). If in the example above "faq/cocoon" is requested, "faq/" is removed from - the URI and "cocoon" is passed to the subsitemap which is loaded + the URI and "cocoon" is passed to the sub-sitemap which is loaded from "faq/sitemap.xmap".

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 + from 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. @@ -491,7 +501,7 @@ If you break a sitemap all its sub-sitemaps are broken as well (because of the hierarchical arrangement).

- However you can create independent subsitemaps, which meet the following goals: + However you can create independent sub-sitemaps, which meet the following goals:

  1. Simplify site construction
  2. @@ -508,7 +518,7 @@ any error in that sitemap does not kill any other sitemap.

    - Here is an example of a main sitemap. You will notice that it is using a selector that + Here is an example of a main sitemap. You will notice that it is using a selector that matches on host name of the request, but any matcher or selector would work at this point. Both sub-sitemaps are mounted at the root level.

    @@ -552,28 +562,32 @@ -

    The reloading of the subsitemaps can be configured by two attributes.

    +

    The reloading of the sub-sitemaps can be configured by two attributes, + "check-reload" and "reload-method".

    - - -]]> - -

    - The "check-reload" attribute specifies if the sitemap is reloaded, this means regenerated, if - it changes. If it set to "no", the sitemap is only generated on the first request for this - sitemap. - If it is set to "yes" (the default), the reload-method determines who the sitemap is regenerated - if it had changed. If it set to "asynchron" (the default), the next request for the changed - sitemap, regenerates the sitemap in the background and the request is served with the old - one. All subsequent requests are served with the old sitemap until the regeneration in the - background has finished. If the reload-method is set to "synchron", the sitemap is first - regenerated and then the request is responded. + + + +]]> + +

    + The "check-reload" attribute specifies whether the sitemap should be reloaded (regenerated) if + it's source XML (sitemap.xmap) is modified. If "check-reload" is set to "no", the sitemap is + only generated on the first request for this sitemap. If "check-reload" is set to "yes" (the + default), the "reload-method" attribute determines how the sitemap is + regenerated if it had changed. +

    +

    + If "reload-method" is set to "asynchron" (the default), then the next request for the changed + sitemap causes it to be regenerated in the background, and the request is served with the old + one. All subsequent requests are served with the old sitemap until the regeneration in the + background has finished. If the reload-method is set to "synchron", the sitemap is first + regenerated and then the request is processed.

    -
    - + + @@ -582,7 +596,7 @@

    This interfaces identifies classes that produce XML data, sending SAX events to the configured XMLConsumer.
    - It's beyond the scope of this interface to specify a way in which the XML + It is beyond the scope of this interface to specify a way in which the XML data production is started.

    @@ -638,7 +652,7 @@

    - All sitemap components producing xml must implement this interface: + All sitemap components producing XML must implement this interface:

    @@ -808,15 +822,16 @@

    - Interface a class has to implement that produces java source code - representing logic for class methods. The - returned source code will be directly integrated into a method of the - generated sitemap code. - This CodeFactory's generate method will be called during + The CodeFactory interface must be implemented by classes that produce Java source + code representing logic for class methods. The returned source code will be directly integrated + into a method of the generated sitemap code. + The CodeFactory's generate method will be called during sitemap code generation. - A CodeFactory is capable to return the java source code of the evaluate method of a + A CodeFactory implementation is capable to return the Java source code of the + evaluate method of a Selector or Matcher - object. It gets the value of the test attribute from the sitemap. + object. It gets passed the value of the "test" attribute of <map:when test=".."> + sections from the sitemap.

    1.10 +10 -0 xml-cocoon2/webapp/stylesheets/documents/root2html.xsl Index: root2html.xsl =================================================================== RCS file: /home/cvs/xml-cocoon2/webapp/stylesheets/documents/root2html.xsl,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- root2html.xsl 2001/07/28 21:52:27 1.9 +++ root2html.xsl 2001/10/01 03:14:13 1.10 @@ -74,6 +74,16 @@ + +

    + +
    + + +

    + +
    + 1.31 +9 -9 xml-cocoon2/xdocs/docs-book.xml Index: docs-book.xml =================================================================== RCS file: /home/cvs/xml-cocoon2/xdocs/docs-book.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- docs-book.xml 2001/09/26 12:48:57 1.30 +++ docs-book.xml 2001/10/01 03:14:13 1.31 @@ -80,13 +80,13 @@ - - - - - - - + + + + + + + @@ -95,8 +95,8 @@ - - + + 1.33 +8 -8 xml-cocoon2/xdocs/site-book.xml Index: site-book.xml =================================================================== RCS file: /home/cvs/xml-cocoon2/xdocs/site-book.xml,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- site-book.xml 2001/09/26 12:48:58 1.32 +++ site-book.xml 2001/10/01 03:14:13 1.33 @@ -81,13 +81,13 @@ - - - - - - - + + + + + + + @@ -98,7 +98,7 @@ - + 1.8 +104 -89 xml-cocoon2/xdocs/sitemap.xml Index: sitemap.xml =================================================================== RCS file: /home/cvs/xml-cocoon2/xdocs/sitemap.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- sitemap.xml 2001/09/26 12:48:58 1.7 +++ sitemap.xml 2001/10/01 03:14:13 1.8 @@ -91,7 +91,7 @@ - + @@ -105,7 +105,7 @@ + ]]> @@ -118,9 +118,9 @@

    The versioning schema will be "major.minor" where major will be increased - by one each time a new release breaks back compatibility, while minor + by one each time a new release breaks backwards compatibility, while minor is increased each time a change has been made that doesn't create - back incompatible problems. + backwards compatibility problems.

    @@ -146,48 +146,46 @@
    name
    -
    The name attribute gives the component a reference which can be used to point to them in the pipeline section.
    +
    Gives the component an identifying name by which it may be referenced in the pipeline section.
    src
    -
    Specifies class representing this component.
    +
    Specifies the class implementing this component.

    - All components will be configured with parameters specified from their child elements at component instantiation time. - The name of the parameters is dependant of the component. The following example shows how to specify a - <use-store> parameter to a component: -

    + All components are configured with parameters specified in their child elements at component instantiation time. + The following example shows how to specify a <use-request-parameter> parameter for an XSLT + transformation component:

    - - true + src="org.apache.cocoon.transformation.TraxTransformer"> + + false
    ]]> -

    - There is no given set of predefined parameters. + The name and meaning of the parameters are dependent on the component.

    - A Generator generates XML content as SAX events and initialize the - pipeline processing. + A Generator generates XML content as SAX events and initializes the pipeline processing.

    - - - + + + + ... @@ -202,15 +200,16 @@

    - A Transformer transform SAX events in SAX events. + A Transformer transforms SAX events into other SAX events.

    - true + src="org.apache.cocoon.transformation.TraxTransformer"> + false + false @@ -226,7 +225,7 @@

    - A Serializers transform SAX events + A Serializer transforms SAX events in binary or char streams for final client consumption.

    @@ -234,7 +233,7 @@ + src="org.apache.cocoon.serialization.HTMLSerializer"> -//W3C//DTD HTML 4.0 Transitional//EN http://www.w3.org/TR/REC-html40/loose.dtd true @@ -243,19 +242,19 @@ + src="org.apache.cocoon.serialization.XMLSerializer"> -//WAPFORUM//DTD WML 1.1//EN http://www.wapforum.org/DTD/wml_1.1.xml UTF-8 + src="org.apache.cocoon.serialization.SVGSerializer"> + src="org.apache.cocoon.serialization.SVGSerializer"> ]]> @@ -269,8 +268,11 @@

    - A Selector evaluate a boolean expression. -

    + A Selector is used to implement basic + conditional logic (if-then-else or switch) inside the sitemap. + As can be seen in the Selector + interface, this functionality decomposes into the ability to evaluate a boolean + condition.

    @@ -286,6 +288,11 @@ + + + + + ... @@ -297,13 +304,14 @@ of selector to use if none is specified in a pipeline.

    -

    - Because the sitemap will be translated and compiled into a java class at runtime a +

    + Because the sitemap will be translated and compiled into a Java class at runtime, a Selector can specify a class implementing CodeFactory - instead of Selector interface. - This class must be capable to return a java source code fragment that can be embedded into a method corresponding - to the Selectors evaluate method. + instead of the Selector interface. + This class must be capable of returning a Java source code fragment that can be embedded into a + method corresponding to the Selector's + evaluate method.

    @@ -313,14 +321,14 @@

    - + + ... - + ... @@ -333,12 +341,13 @@

    - Because the sitemap will be translated and compiled into a java class at runtime a + Because the sitemap will be translated and compiled into a Java class at runtime, a Matcher can specify a class implementing CodeFactory - instead of Matcher interface. - This class must be capable to return a java source code fragment that can be embedded into a method corresponding - to the Matchers match method. + instead of the Matcher interface. + This class must be capable of returning a Java source code fragment that can be embedded into + a method corresponding to the Matcher's + match method.

    @@ -346,8 +355,9 @@

    An Action is a sitemap component that manipulates runtime parameters based on request and application state. - Action's result is available in the sitemap as map of name/value pairs. - Detailed information on actions is here. + An Action's result is available in the sitemap as map of name/value pairs. + Detailed information on actions may be found in the Actions + section.

    The <map:view> element defines different view of the site. Views are defined independent of pipelines and might - be used with any pipeline defined in the sitemap. More on views - read "Views". + be used with any pipeline defined in the sitemap. For more on views + read the Views section.

    @@ -421,10 +431,10 @@
    - +

    The <map:action-set> element is used to arrange actions in - a groups (See "Actions" for details). + groups (See the Actions section for details).

    @@ -449,11 +459,11 @@

    Mount points allow sitemaps to be cascaded and site management workload to be parallelized. This creates a tree of sitemaps with - the main sitemap at the root and possibly several subsitemaps + the main sitemap at the root and possibly several sub-sitemaps as nodes and leaves.

    -

    The subsitemaps serve two important goals: scalability and - simplification of maintainance. The different subsitemaps are independent +

    The sub-sitemaps serve two important goals: scalability and + simplification of maintenance. The different sub-sitemaps are independent and don't affect each other.

    @@ -464,20 +474,20 @@ ]]>

    - 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 + The src attribute is where the sub-sitemap 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. + modification date of the sub-sitemap file should be checked. 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). If in the example above "faq/cocoon" is requested, "faq/" is removed from - the URI and "cocoon" is passed to the subsitemap which is loaded + the URI and "cocoon" is passed to the sub-sitemap which is loaded from "faq/sitemap.xmap".

    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 + from 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. @@ -491,7 +501,7 @@ If you break a sitemap all its sub-sitemaps are broken as well (because of the hierarchical arrangement).

    - However you can create independent subsitemaps, which meet the following goals: + However you can create independent sub-sitemaps, which meet the following goals:

    1. Simplify site construction
    2. @@ -508,7 +518,7 @@ any error in that sitemap does not kill any other sitemap.

      - Here is an example of a main sitemap. You will notice that it is using a selector that + Here is an example of a main sitemap. You will notice that it is using a selector that matches on host name of the request, but any matcher or selector would work at this point. Both sub-sitemaps are mounted at the root level.

      @@ -552,28 +562,32 @@ -

      The reloading of the subsitemaps can be configured by two attributes.

      +

      The reloading of the sub-sitemaps can be configured by two attributes, + "check-reload" and "reload-method".

      - - -]]> - -

      - The "check-reload" attribute specifies if the sitemap is reloaded, this means regenerated, if - it changes. If it set to "no", the sitemap is only generated on the first request for this - sitemap. - If it is set to "yes" (the default), the reload-method determines who the sitemap is regenerated - if it had changed. If it set to "asynchron" (the default), the next request for the changed - sitemap, regenerates the sitemap in the background and the request is served with the old - one. All subsequent requests are served with the old sitemap until the regeneration in the - background has finished. If the reload-method is set to "synchron", the sitemap is first - regenerated and then the request is responded. + + + +]]> + +

      + The "check-reload" attribute specifies whether the sitemap should be reloaded (regenerated) if + it's source XML (sitemap.xmap) is modified. If "check-reload" is set to "no", the sitemap is + only generated on the first request for this sitemap. If "check-reload" is set to "yes" (the + default), the "reload-method" attribute determines how the sitemap is + regenerated if it had changed. +

      +

      + If "reload-method" is set to "asynchron" (the default), then the next request for the changed + sitemap causes it to be regenerated in the background, and the request is served with the old + one. All subsequent requests are served with the old sitemap until the regeneration in the + background has finished. If the reload-method is set to "synchron", the sitemap is first + regenerated and then the request is processed.

      -
      - + + @@ -582,7 +596,7 @@

      This interfaces identifies classes that produce XML data, sending SAX events to the configured XMLConsumer.
      - It's beyond the scope of this interface to specify a way in which the XML + It is beyond the scope of this interface to specify a way in which the XML data production is started.

      @@ -638,7 +652,7 @@

      - All sitemap components producing xml must implement this interface: + All sitemap components producing XML must implement this interface:

      @@ -808,15 +822,16 @@

      - Interface a class has to implement that produces java source code - representing logic for class methods. The - returned source code will be directly integrated into a method of the - generated sitemap code. - This CodeFactory's generate method will be called during + The CodeFactory interface must be implemented by classes that produce Java source + code representing logic for class methods. The returned source code will be directly integrated + into a method of the generated sitemap code. + The CodeFactory's generate method will be called during sitemap code generation. - A CodeFactory is capable to return the java source code of the evaluate method of a + A CodeFactory implementation is capable to return the Java source code of the + evaluate method of a Selector or Matcher - object. It gets the value of the test attribute from the sitemap. + object. It gets passed the value of the "test" attribute of <map:when test=".."> + sections from the sitemap.

      1.5 +29 -14 xml-cocoon2/xdocs/xsp.xml Index: xsp.xml =================================================================== RCS file: /home/cvs/xml-cocoon2/xdocs/xsp.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- xsp.xml 2001/09/26 12:48:58 1.4 +++ xsp.xml 2001/10/01 03:14:13 1.5 @@ -10,19 +10,34 @@ - -

      As I find that there is enough information about XSP available (only - not together), I give you a list of pointers in the sequence you should read - them.

      -
        -
      1. Get @doctitle@ up and running. Surf - to [webhost]/cocoon/slides/slides?section=4 and following. This - gives you a first insight in the XSP ground idea.
      2. -
      3. Read the XSP Logicsheets page. This tells you how to use and make - your own XSP logicsheets and XSP pages.
      4. -
      5. If you're still hungry for more, read the XSP Internals page. This - describes how XSP's are handled internally by @docname@.
      6. -
      -
      + +

      As I find that there is enough information about XSP available (only + not together), I give you a list of pointers in the sequence you should read + them.

      +
        +
      1. Get @doctitle@ up and running. Surf + to [webhost]/cocoon/slides/slides?section=4 and following. This + gives you a first insight in the XSP ground idea.
      2. +
      3. Read the XSP Logicsheets page. This tells you how to use and make + your own XSP logicsheets and XSP pages.
      4. +
      5. If you're still hungry for more, read the XSP Internals page. This + describes how XSP's are handled internally by @docname@.
      6. +
      +
      + +
        +
      • XSP Logicsheets concepts page helps you get started.
      • +
      • XSP Internals page gives deeper explanation of XSP technology.
      • +
      • XSP Guide page is a tutorial to using and creating @docname@ XSP logicsheets.
      • +
      + +
        +
      • Sessions Logicsheet
      • +
      • Request Logicsheet
      • +
      • ESQL Logicsheet
      • +
      • Forms Logicsheet
      • +
      +
      +
      ---------------------------------------------------------------------- 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