Author: vgritsenko
Date: Fri Apr  1 08:46:58 2005
New Revision: 159707

URL: http://svn.apache.org/viewcvs?view=rev&rev=159707
Log:
fix bug #26107. rearrange left menu a bit.

Modified:
    cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/book.xml
    cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/introduction.xml
    cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/overview.xml
    
cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/userdocs/xsp/logicsheet.xml

Modified: cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/book.xml
URL: 
http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/book.xml?view=diff&r1=159706&r2=159707
==============================================================================
--- cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/book.xml (original)
+++ cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/book.xml Fri Apr  1 
08:46:58 2005
@@ -24,7 +24,7 @@
 
   <menu label="About">
     <menu-item label="Index" href="index.html"/>
-    <menu-item label="Features" href="features.html"/>    
+    <menu-item label="Features" href="features.html"/>
     <external label="News" href="http://cocoon.apache.org/news/"/>
     <menu-item label="License" href="license.html"/>
     <external label="Download" href="http://cocoon.apache.org/mirror.cgi"/>
@@ -32,11 +32,11 @@
 
   <menu label="Documentation">
     <menu-item label="Introduction" href="introduction.html"/>
-    <menu-item label="Tracks" href="tracks/index.html"/>
-    <menu-item label="Installing" href="installing/index.html"/>
     <menu-item label="Overview" href="overview.html"/>
+    <menu-item label="Installing" href="installing/index.html"/>
     <menu-item label="User Guide" href="userdocs/index.html"/>
     <menu-item label="Dev Guide" href="developing/index.html"/>
+    <menu-item label="Tracks" href="tracks/index.html"/>
     <menu-item label="Tutorials" href="tutorial/index.html"/>
     <menu-item label="FAQs" href="faq/index.html"/>
     <menu-item label="How-Tos" href="howto/index.html"/>

Modified: 
cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/introduction.xml
URL: 
http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/introduction.xml?view=diff&r1=159706&r2=159707
==============================================================================
--- cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/introduction.xml 
(original)
+++ cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/introduction.xml 
Fri Apr  1 08:46:58 2005
@@ -17,9 +17,9 @@
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" 
"document-v10.dtd">
 
 <document>
-
   <header>
-    <title>Introducing Cocoon</title>
+    <title>Introducing Apache Cocoon</title>
+    <version>$Id$</version>
     <authors>
       <person name="Stefano Mazzocchi" email="[EMAIL PROTECTED]"/>
     </authors>
@@ -240,7 +240,7 @@
 </p>
 
 <p>
-So, you could be wondering, why did we spend so much effort to 
+So, you could be wondering, why did we spend so much effort to
 write an XML publishing framework? This document was written exactly
 to clear your doubts on this, so let's keep going.
 </p>
@@ -300,7 +300,7 @@
 <p>
 This was the point where Stefano was more or less two years ago for
 java.apache.org: I could use XML and define my own semantics with
-<![CDATA[<sidebar>]]>, <![CDATA[<news>]]>, <![CDATA[<status>]]> 
+<![CDATA[<sidebar>]]>, <![CDATA[<news>]]>, <![CDATA[<status>]]>
 and all that and I'm sure people would have
 found those XML documents much easier to write (since the XML syntax is
 very similar to the HTML one and very user friendly)... but I would have

Modified: cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/overview.xml
URL: 
http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/overview.xml?view=diff&r1=159706&r2=159707
==============================================================================
--- cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/overview.xml 
(original)
+++ cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/overview.xml Fri 
Apr  1 08:46:58 2005
@@ -17,30 +17,31 @@
 <?xml-stylesheet type="text/css" href="css/document.css"?>
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" 
"document-v10.dtd">
 
-<document> 
-  <header> 
-        <title>Overview of Apache Cocoon</title>
-        <version>0.2</version> 
-        <type>Overview document</type> 
-        <authors><person name="Tom Klaasen" email="[EMAIL PROTECTED]"/> 
-        </authors> 
-  </header> 
-  <body> 
-        <s1 title="What is Apache Cocoon"> 
+<document>
+  <header>
+    <title>Overview of Apache Cocoon</title>
+    <version>$Id$</version> 
+    <type>Overview document</type>
+    <authors><person name="Tom Klaasen" email="[EMAIL PROTECTED]"/>
+    </authors>
+  </header>
+
+  <body>
+        <s1 title="What is Apache Cocoon">
                <p>Cocoon is an XML publishing framework. It allows you to 
define XML
                  documents and transformations to be applied on it, to 
eventually generate a
-                 presentation format of your choice (HTML, PDF, SVG, ...).</p> 
+                 presentation format of your choice (HTML, PDF, SVG, ...).</p>
                <p>Cocoon also gives you the possibility to apply logic to your 
XML files
-                 (so that the XML pipeline can be dynamic).</p> 
+                 (so that the XML pipeline can be dynamic).</p>
 
     <p>The <link href="userdocs/index.html">User documentation</link>
      and especially <link href="userdocs/concepts/index.html">Concepts</link>
      will help to understand Cocoon.
     </p>
-   </s1> 
+   </s1>
 
    <anchor id="samples"/>
-   <s1 title="Examples and demonstration applications"> 
+   <s1 title="Examples and demonstration applications">
     <p>
      There are a whole suite of sample applications to demonstrate the power
      of Cocoon. These samples are available from the "welcome" page after
@@ -63,49 +64,49 @@
      <code>src/webapp/samples/</code> and by consulting each sitemap to see
      the processing steps that are defined.
     </p>
-   </s1> 
+   </s1>
 
-   <s1 title="Overview of XML document processing"> 
+   <s1 title="Overview of XML document processing">
     <p>This section gives a general overview of how an XML document is
      handled by Cocoon. See also the document
      <link href="userdocs/concepts/index.html">Understanding Cocoon</link> for 
explanation of
      the separation of content, style, logic and management functions.
-    </p> 
+    </p>
 
-               <s2 title="Pipeline"> 
+               <s2 title="Pipeline">
                  <p>Cocoon relies on the pipeline model: an XML document is 
pushed
                         through a pipeline, that exists in several 
transformation steps of your
                         document. Every pipeline begins with a generator, 
continues with zero or more
                         transformers, and ends with a serializer. This can be 
compared to the
                         "servlet-chaining" concept of a servlet engine. We'll 
explain the components of
-                        the pipeline now in more detail.</p> 
-                 <s3 title="Generator"> 
+                        the pipeline now in more detail.</p>
+                 <s3 title="Generator">
                         <p>The Generator is the starting point for the 
pipeline. It is
-                               responsible for delivering SAX events down the 
pipeline.</p> 
+                               responsible for delivering SAX events down the 
pipeline.</p>
                         <p>The simplest Generator is the FileGenerator: it 
takes a local XML
-                               document, parses it, and sends the SAX events 
down the pipeline. </p> 
+                               document, parses it, and sends the SAX events 
down the pipeline. </p>
                         <p>The Generator is constructed to be independent of 
the concept
                                "file". If you are able to generate SAX events 
from another source, you can use
-                               that without having to go via a temporary 
file.</p> 
-                 </s3> 
-                 <s3 title="Transformer"> 
+                               that without having to go via a temporary 
file.</p>
+                 </s3>
+                 <s3 title="Transformer">
                         <p>A Transformer can be compared to an XSL: it gets an 
XML document
-                               (or SAX events), and generates another XML 
document (or SAX events).</p> 
+                               (or SAX events), and generates another XML 
document (or SAX events).</p>
                         <p>The simplest Transformer is the XalanTransformer: 
it applies an
-                               XSL to the SAX events it receives.</p> 
-                 </s3> 
-                 <s3 title="Serializer"> 
+                               XSL to the SAX events it receives.</p>
+                 </s3>
+                 <s3 title="Serializer">
                         <p>A Serializer is responsible for transforming SAX 
events to a
                                presentation format. For actors looking at the 
back of the pipeline, it looks
                                like a static file is delivered. So a browser 
can receive HTML, and will not be
                                able to tell the difference with a static file 
on the filesystem of the server.
-                               </p> 
+                               </p>
                         <p>We have Serializers for generating HTML, XML, PDF, 
VRML, WAP, and
-                               of course you can create your own.</p> 
+                               of course you can create your own.</p>
                         <p>The simplest Serializer is the XMLSerializer: it 
receives the SAX
-                               events from up the pipeline, and returns a 
"human-readable" XML file.</p> 
-                 </s3> 
-               </s2> 
-        </s1> 
+                               events from up the pipeline, and returns a 
"human-readable" XML file.</p>
+                 </s3>
+               </s2>
+        </s1>
   </body>
 </document>

Modified: 
cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/userdocs/xsp/logicsheet.xml
URL: 
http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/userdocs/xsp/logicsheet.xml?view=diff&r1=159706&r2=159707
==============================================================================
--- 
cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/userdocs/xsp/logicsheet.xml
 (original)
+++ 
cocoon/whiteboard/doc-repos/old-2.2-documentation/xdocs/userdocs/xsp/logicsheet.xml
 Fri Apr  1 08:46:58 2005
@@ -17,27 +17,29 @@
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" 
"document-v10.dtd">
 
 <document>
- <header>
-  <title>XSP Logicsheet Guide</title>
-  <authors>
-   <person name="Christopher Painter-Wakefield" email="[EMAIL PROTECTED]"/>
-  </authors>
- </header>
+  <header>
+    <title>XSP Logicsheet Guide</title>
+    <version>$Id$</version>
+    <authors>
+      <person name="Christopher Painter-Wakefield" email="[EMAIL PROTECTED]"/>
+      <person name="Vadim Gritsenko" email="[EMAIL PROTECTED]"/>
+    </authors>
+  </header>
 
- <body>
+  <body>
 
 <s1 title="Introduction">
   <p>This document is intended as an introduction and brief tutorial to using 
and
   creating Apache Cocoon XSP logicsheets. It is assumed that the reader has a 
working
   knowledge of XML and XSLT, and has worked through at least the basic XSP 
examples
-  supplied with Cocoon.  Although this is not intended as a tutorial for XSP 
+  supplied with Cocoon.  Although this is not intended as a tutorial for XSP
   specifically, much of the material may be helpful in gaining a fuller 
understanding
   of XSP.</p>
 </s1>
 
-<s1 title="Taglibs and logicsheets">
+<s1 title="Taglibs and Logicsheets">
   <p>There is some confusion over the terms "taglib" and "logicsheet".  Many 
people
-  will use these terms interchangeably.  The term "taglib" comes from JSP, 
which 
+  will use these terms interchangeably.  The term "taglib" comes from JSP, 
which
   inspired XSP.  An XSP logicsheet is a "tag library" in the sense that it 
defines
   a set of custom XML tags which can be used within an XSP program to insert 
whole
   blocks of code into the file.  Cocoon comes with several pre-defined 
"taglibs",
@@ -59,7 +61,7 @@
   working (if trivial) example of XSP using a custom logicsheet.</p>
 
 <s2 title="Simple HTML Example">
-  <p>All of the examples in this section will produce HTML output 
+  <p>All of the examples in this section will produce HTML output
   essentially equivalent to this:</p>
 
 <source><![CDATA[
@@ -74,26 +76,20 @@
   <p>I did say these would be simple examples, didn't I?</p>
 
 <s2 title="Simple XML/XSL Example">
-  <p>Here's a simple XML file:</p>
-  
-<source>
-greeting.xml
-<![CDATA[
-<?xml version="1.0"?>
+  <p>Here's a simple greeting.xml file:</p>
 
+<source><![CDATA[
+<?xml version="1.0"?>
 <greeting>Hello, world!</greeting>
 ]]></source>
 
-  <p>...and here's the XSL stylesheet that will transform it into an HTML file
+  <p>...and here's the greeting.xsl stylesheet that will transform it into an 
HTML file
   similar to the one we started this section with:</p>
 
-
-<source>
-greeting.xsl
-<![CDATA[
+<source><![CDATA[
 <?xml version="1.0"?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="1.0">
-
+<xsl:stylesheet version="1.0"
+                xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
 <xsl:template match="/">
   <html>
     <body>
@@ -103,11 +99,10 @@
     </body>
   </html>
 </xsl:template>
-
 </xsl:stylesheet>
 ]]></source>
 
-  <p>So far, nothing exciting.  The input XML has a single element, 
&lt;greeting>,
+  <p>So far, nothing exciting.  The input XML has a single element, 
&lt;greeting&gt;,
   whose text contents gets spit out in HTML.  The contents of our particular 
XML
   file's greeting is, predictably, "Hello, World!"  The point of showing you 
this
   is that, as we elaborate our example by adding Java code through XSP, and 
later
@@ -119,13 +114,11 @@
 <s2 title="Simple XSP Example">
   <p>Next, we continue in our trivial vein by using trivial Java code to make 
an
   XSP program, whose output will mimic that of our XML file above.  The output
-  of this file is transformed to HTML by the same XSL stylesheet as above:</p>
+  of this file, greeting2.xml, is transformed to HTML by the same XSL 
stylesheet
+  as above:</p>
 
-<source>
-greeting2.xml
-<![CDATA[
+<source><![CDATA[
 <?xml version="1.0"?>
-
 <xsp:page xmlns:xsp="http://apache.org/xsp";>
 
   <xsp:logic>
@@ -144,35 +137,31 @@
 <s2 title="Simple XSP Logicsheet Example">
 
   <p>Now we are ready to present our final trivial example, using a custom
-  logicsheet.  There are two files shown below.  The first is an XSP file
-  that uses a custom logicsheet, logicsheet.greeting.xsl, which is the second
-  file shown below.</p>
-  
-<source>
-greeting3.xml
-<![CDATA[
-<?xml version="1.0"?>
+  logicsheet.  There are two files shown below.  The first is an XSP file,
+  greeting3.xml.</p>
 
-<xsp:page
-  xmlns:xsp="http://apache.org/xsp";
-  xmlns:greeting="http://duke.edu/tutorial/greeting";>
+<source><![CDATA[
+<?xml version="1.0"?>
+<?xml-logicsheet href="logicsheet.greeting.xsl"?>
 
+<xsp:page xmlns:xsp="http://apache.org/xsp";
+          xmlns:greeting="http://duke.edu/tutorial/greeting";>
   <greeting>
     <greeting:hello-world/>
   </greeting>
-
 </xsp:page>
 ]]></source>
 
-<source>
-logicsheet.greeting.xsl
-<![CDATA[
+  <p>It uses a custom logicsheet, logicsheet.greeting.xsl, which is the file
+  shown below.</p>
+
+<source><![CDATA[
 <?xml version="1.0"?>
-<xsl:stylesheet
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
-  xmlns:xsp="http://apache.org/xsp";
-  xmlns:greeting="http://duke.edu/tutorial/greeting";
-  version="1.0">
+
+<xsl:stylesheet version="1.0"
+                xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
+                xmlns:xsp="http://apache.org/xsp";
+                xmlns:greeting="http://duke.edu/tutorial/greeting";>
 
 <xsl:template match="xsp:page">
  <xsl:copy>
@@ -203,17 +192,22 @@
 
   <p>There are several things to note about these two files.  First, note
   that we inform the XSP processor that it should apply our custom logicsheet
-  using the processing instruction</p>
+  using the processing instruction:</p>
   <source><![CDATA[<?xml-logicsheet 
href="logicsheet.greeting.xsl"?>]]></source>
 
   <p>There are other ways to associate a logicsheet with an XSP file, which 
we'll
-  discuss later.  Next, note that our logicsheet defines a new namespace, 
+  discuss later.  Next, note that our logicsheet defines a new namespace,
   <strong>greeting:</strong>, which must be declared in both files using the 
same URI:</p>
   
<source><![CDATA[xmlns:greeting="http://duke.edu/tutorial/greeting";]]></source>
 
-  <p>Note that the URI is completely arbitrary.  I've chosen to construct my
-  namespace URI's by using my institution's web address (http://duke.edu/)
-  followed by the project name (tutorial) and namespace name (greeting).  
+  <note>
+    Namespaces of all used logicsheets <strong>must</strong> be declared on the
+    root element, <code>xsp:page</code>.
+  </note>
+
+  <p>Note that the logicsheet URI is completely arbitrary.  I've chosen to 
construct
+  my namespace URI's by using my institution's web address (http://duke.edu/)
+  followed by the project name (tutorial) and namespace name (greeting).
   You may use any scheme you wish for your namespace URI's; however, the URI
   declared in the logicsheet <strong>must</strong> match the URI declared in 
the
   XSP which uses the logicsheet.</p>
@@ -223,16 +217,14 @@
   not just to any XML file, but specifically to an XSP file, and the end 
result of
   its transformation is another XSP file.  If you were to apply the logicsheet 
in
   this example to the XML file in this example as just a stylesheet (with no 
XSP
-  processing), you would end up with something like the following (compare to 
our 
+  processing), you would end up with something like the following (compare to 
our
   earlier XSP example):</p>
 
 <source><![CDATA[
 <?xml version="1.0"?>
 
-<xsp:page 
-  xmlns:greeting="http://duke.edu/tutorial/greeting"; 
-  xmlns:xsp="http://apache.org/xsp";>
-
+<xsp:page xmlns:xsp="http://apache.org/xsp";
+          xmlns:greeting="http://duke.edu/tutorial/greeting";>
   <greeting>
     <xsp:logic>
       // this could be arbitrarily complex Java code, JDBC queries, etc.
@@ -253,14 +245,14 @@
   right after xml header and before &lt;xsp:page&gt; tag:</p>
 <source><![CDATA[
 <?xml version="1.0"?>
-
-<?xml-logicsheet href="logicsheet.greeting.xsl"?>]]>
-</source>
+<?xml-logicsheet href="logicsheet.greeting.xsl"?>
+]]></source>
 
   <p>There is another way to apply a logicsheet, which doesn't require a
   processing instruction for each file that uses the logicsheet.  The
   second way is to declare logicsheet in the cocoon.xconf file.
   These declarations take the form</p>
+
 <source><![CDATA[
 <builtin-logicsheet>
   <parameter name="prefix" value="&lt;logicsheet's prefix&gt;"/>
@@ -271,6 +263,7 @@
 
   <p>Cocoon's pre-defined logicsheets are already declared in this file.  For
   instance, the declaration of the XSP request taglib is the following:</p>
+
 <source><![CDATA[
 <builtin-logicsheet>
   <parameter name="prefix" value="xsp-request"/>
@@ -280,29 +273,29 @@
 </builtin-logicsheet>
 ]]></source>
 
-  <p>This line associates the 
<strong>http://apache.org/xsp/request/2.0</strong> 
-  namespace with the logicsheet named in the URL. This URL points to a file 
-  that is stored in the cocoon.jar. To use the request taglib, you must 
+  <p>This line associates the 
<strong>http://apache.org/xsp/request/2.0</strong>
+  namespace with the logicsheet named in the URL. This URL points to a file
+  that is stored in the cocoon.jar. To use the request taglib, you must
   declare the request namespace in your XSP file:</p>
+
 <source><![CDATA[
 ...
-<xsp:page
-  xmlns:xsp="http://apache.org/xsp";
-  xmlns:xsp-request="http://apache.org/xsp/request/2.0";
->
+<xsp:page xmlns:xsp="http://apache.org/xsp";
+          xmlns:xsp-request="http://apache.org/xsp/request/2.0";>
 ...
 ]]></source>
 
-  <note>You should <strong>not</strong> try to apply the xsp-request 
+  <note>You should <strong>not</strong> try to apply the xsp-request
   taglib using the &lt;?xml-logicsheet?&gt; processing instruction,
   as this will result in the logicsheet being applied twice.</note>
 
   <p>You can add your own logicsheets to the cocoon.xconf file using the same
-  syntax. The only trick is constructing an appropriate URL. If we wanted to 
-  declare our <strong>greeting:</strong> namespace and logicsheet from the 
-  Hello, World! example above, and if the logicsheet were stored (on a UNIX 
-  filesystem) in the location /cocoon/logicsheets/logicsheet.greeting.xsl, 
+  syntax. The only trick is constructing an appropriate URL. If we wanted to
+  declare our <strong>greeting:</strong> namespace and logicsheet from the
+  Hello, World! example above, and if the logicsheet were stored (on a UNIX
+  filesystem) in the location /cocoon/logicsheets/logicsheet.greeting.xsl,
   we'd add this line to cocoon.xconf:</p>
+
 <source><![CDATA[
 <builtin-logicsheet>
   <parameter name="prefix" value="greeting"/>
@@ -312,12 +305,18 @@
 </builtin-logicsheet>
 ]]></source>
 
-  <p>There are some very important differences between using the 
&lt;?xml-logicsheet?> 
-  processing instruction vs. the cocoon.properties entry to apply a logicsheet.
-  Using cocoon.properties, any time the logicsheet changes, it is necessary to 
-  restart Cocoon.  If you instead use the processing instruction, Cocoon will 
detect
-  modifications to your logicsheet, and recompile your XSP programs 
accordingly.
-  Also, if you need to explicitly control the order in which your logicsheets 
are
+  <p>In addition to using 'file:' protocol, logicsheet URL can use 'resource:'
+  protocol to load logicsheets from the class loader, or 'context:' protocol to
+  specify URL relative to the web application context directory.</p>
+
+  <p>There are some very important differences between using the 'resource:'
+  protocol vs. the 'file:' protocol to apply a logicsheet.  Using 'resource:',
+  any time the logicsheet changes, it is necessary to restart Cocoon.  If you
+  instead use the 'file:' (or 'context:', and you are not deploying Cocoon as a
+  single war file), Cocoon will detect modifications to your logicsheet, and
+  recompile your XSP programs accordingly.</p>
+
+  <p>If you happen to need to explicitly control the order in which your 
logicsheets are
   applied, you need to use the processing instruction.  Logicsheets will be 
applied
   in the order in which they appear in processing instructions in your source 
file.</p>
 
@@ -329,14 +328,14 @@
 <s1 title="Logicsheet Development Tips">
   <s2 title="Development Practices">
   <p>Developing Logicsheets can be a frustrating mental exercise, as it 
requires you
-  to understand and keep in mind the complex coordination of several different 
+  to understand and keep in mind the complex coordination of several different
   technologies: XML, XSLT, XSP, and Java.  A bad assumption in any of these 
areas
   can lead to an hour of debugging.  Following a few simple practices can 
reduce the
   frustration and make logicsheet programming less difficult:</p>
   <dl>
     <dt>Small Increments</dt>
     <dd>As with any software development, it is much easier to debug a small 
amount
-    of code than a large amount of code.  XSP is no different, except that the 
+    of code than a large amount of code.  XSP is no different, except that the
     complexity of a large amount of code is multiplied by the number of 
different
     technologies.  So, write a tiny bit of code and get it working, or start 
with a
     simple piece of code that is already working.  Make small changes, and get 
each
@@ -361,11 +360,11 @@
     tree) and borrow from it liberally.  Reading this code is also a good way 
to
     gain insight into logicsheet design.</dd>
   </dl>
-  </s2> 
+  </s2>
 
   <s2 title="Standard Templates">
     <p>As we discussed earlier, a logicsheet is just an XSLT stylesheet which 
transforms
-    one XSP source file into another.  Since we are always expecting to act on 
an XSP 
+    one XSP source file into another.  Since we are always expecting to act on 
an XSP
     source file, and there is the possibility that other logicsheets may also 
be acting
     on the same file (either before or after our logicsheet), there are a few 
templates
     which are more or less required in any logicsheet.  The templates below 
were all
@@ -385,6 +384,7 @@
     variables at the class level, you will need to have a way to add elements 
to the
     &lt;xsp:page> element that is at the root of the source file.  Here is a 
template
     to let you do that (from esql.xsl):</p>
+
 <source><![CDATA[
 <xsl:template match="xsp:page">
   <xsp:page>
@@ -398,7 +398,7 @@
   </xsp:page>
 </xsl:template>
 ]]></source>
- 
+
     <p>Frequently, you may also need to declare variables or perform 
initialization
     that needs to occur before any of the code in your custom tags.  You 
could, of
     course, require that the users of your logicsheet use one particular tag 
before
@@ -412,6 +412,7 @@
     which don't themselves begin with 'xsp:'".  Since the &lt;xsp:page> 
element always
     has a single element which isn't in the xsp: namespace, this will be 
matched once
     and only once.</p>
+
 <source><![CDATA[
 <xsl:template match="xsp:page/*[not(starts-with(name(.), 'xsp:'))]">
  <xsl:copy>
@@ -421,7 +422,7 @@
   </xsp:logic>
   <xsl:apply-templates/>
  </xsl:copy>
-</xsl:template> 
+</xsl:template>
 ]]></source>
 
   </s2>
@@ -436,7 +437,6 @@
     even if it doesn't directly reference any of the tags in the second 
logicsheet.</p>
   </s2>
 </s1>
-
 
 </body>
 


Reply via email to