You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lenya.apache.org by gr...@apache.org on 2005/05/16 01:56:55 UTC

svn commit: r170282 [2/2] - in /lenya/docu/src/documentation/content/xdocs: ./ 1_2_x/components/editors/ 1_2_x/components/workflow/ 1_2_x/how-to/ 1_2_x/misc/ 1_4/reference/ community/

Modified: lenya/docu/src/documentation/content/xdocs/1_2_x/how-to/using_pictures.xml
URL: http://svn.apache.org/viewcvs/lenya/docu/src/documentation/content/xdocs/1_2_x/how-to/using_pictures.xml?rev=170282&r1=170281&r2=170282&view=diff
==============================================================================
--- lenya/docu/src/documentation/content/xdocs/1_2_x/how-to/using_pictures.xml (original)
+++ lenya/docu/src/documentation/content/xdocs/1_2_x/how-to/using_pictures.xml Sun May 15 16:56:54 2005
@@ -32,18 +32,18 @@
 
 <p>In a standard Lenya publication there are two possible places where pictures might be found:  </p>
 <ul>
-<li><p>  In the <tt>resources/shared/images</tt> folder of you publication. </p>
+<li><p>  In the <em>resources/shared/images</em> folder of you publication. </p>
 
 </li>
 <li><p>  In the content folder for a specific page. </p>
 </li>
 </ul>
-<p>As <tt>resources/shared</tt> suggests these are pictures that might be needed in any of the pages and that change seldom, such as the coporate logo or navigational elements for example. </p>
-<p>The pictures in the <tt>resources/shared/images</tt> folder cannot be uploaded by the content editor through the web browser but need to be put there by the administrator. They are referenced in the publication as {{ {$root}/images/name.ext}}, such as </p>
+<p>As <em>resources/shared</em> suggests these are pictures that might be needed in any of the pages and that change seldom, such as the coporate logo or navigational elements for example. </p>
+<p>The pictures in the <em>resources/shared/images</em> folder cannot be uploaded by the content editor through the web browser but need to be put there by the administrator. They are referenced in the publication as {{ {$root}/images/name.ext}}, such as </p>
 
-<pre>
+<source>
 &lt;img src="{$root}/images/project-logo.png"/&gt;
-</pre>
+</source>
 <p>In many cases the content editor of the site will never have to deal with it as these images are often only referenced from the XSLT template that he or she should also not (have to) touch at all. </p>
 <p>Pictures that are not global to the whole publication but belong to one page and therefore are subject to page editing are saved into the the folder that is named after the document id and holds the page as well. These pictures are called <em>Assets</em> in Lenya and can be uploaded by the editor. </p>
 
@@ -51,15 +51,15 @@
 
 <p>In order to allow upload assets, compile Lenya with the parameter <strong>enable.uploads=true</strong> wich is found in <strong>build.properties</strong>: </p>
 
-<pre>
+<source>
 # Enable multipart requests (for security reasons turned off by default.
 # Uncomment to enable)
 
 enable.uploads=true
-</pre>
+</source>
 <p>This option is commented by default wich means it is <em>false</em>. As a Lenya user you cannot change this option, please make sure you recompile and re-install lenya with this option turned on before you continue. </p>
 <p>If the option is off, we will be able to upload assets, but they will be discarded. The user does not receive a warning about that. </p>
-<p><strong>Note:</strong> If the option is off, you might expect the Asset upload to be disabled or to get a warning message similar to the page you see when Kupu is not installed and you try to use the <em>Edit with Kupu</em> menu option. None of this. In case the parameter is off, you can happily upload pictures. You will not get any error messages, but your pictures will be written to <tt>/dev/null</tt>. <strong>Note for the non-Unix people:</strong> <em>They will be silently discarded.</em> </p>
+<p><strong>Note:</strong> If the option is off, you might expect the Asset upload to be disabled or to get a warning message similar to the page you see when Kupu is not installed and you try to use the <em>Edit with Kupu</em> menu option. None of this. In case the parameter is off, you can happily upload pictures. You will not get any error messages, but your pictures will be written to <em>/dev/null</em>. <strong>Note for the non-Unix people:</strong> <em>They will be silently discarded.</em> </p>
 
 </section><section><title id="head-543727d3f7ff5362456e9f90f91b773a29989b28">Uploading pictures</title>
 
@@ -72,8 +72,8 @@
 
 </section><section><title id="head-e89353653618c83710b1579bc01c1fb69cd321b8">Linking pictures in a document</title>
 
-<p>In order to link a picture that you have uploaded as an asset, you need to insert a relative link to <tt>doc_id/filename.ext</tt>. If for example you are editing the page <tt>index</tt> and you uploaded a picture called <tt>building.png</tt>, you would need to link to <tt>index/building.png</tt>. </p>
+<p>In order to link a picture that you have uploaded as an asset, you need to insert a relative link to <em>doc_id/filename.ext</em>. If for example you are editing the page <em>index</em> and you uploaded a picture called <em>building.png</em>, you would need to link to <em>index/building.png</em>. </p>
 
-<p>This is also true for pages that are not directly under home, but anywhere in the hierarchy. If for example you need to link a picture called photo.jpg in <tt>/products/enduser/product_a/overview_a</tt> the link would still be <tt>overview_a/photo.jpg</tt>. </p>
+<p>This is also true for pages that are not directly under home, but anywhere in the hierarchy. If for example you need to link a picture called photo.jpg in <em>/products/enduser/product_a/overview_a</em> the link would still be <em>overview_a/photo.jpg</em>. </p>
 <p>This remains true in any editor. In Kupu for example you can type this link directly into to the appropriate field and hit the "Insert Image" button beneath. You should see the image appear immediatelly inside the page you are editing. </p></section></body>
 </document>

Modified: lenya/docu/src/documentation/content/xdocs/1_2_x/misc/reserved_names.xml
URL: http://svn.apache.org/viewcvs/lenya/docu/src/documentation/content/xdocs/1_2_x/misc/reserved_names.xml?rev=170282&r1=170281&r2=170282&view=diff
==============================================================================
--- lenya/docu/src/documentation/content/xdocs/1_2_x/misc/reserved_names.xml (original)
+++ lenya/docu/src/documentation/content/xdocs/1_2_x/misc/reserved_names.xml Sun May 15 16:56:54 2005
@@ -20,7 +20,6 @@
     <title>Reserved Names</title> 
   </header> 
   <body> 
-    <section>
 <p>List of Names that are reserved by Lenya for various subsystems </p>
 <ul>
 <li><p>  CSS Classes </p></li>
@@ -42,7 +41,6 @@
 <li><p>  org.apache.lenya.cms.info.target </p></li>
 </ul>
 <p>it seems that the convention is to use a proper class hierarchy for the session var name cookie variables should follow the same convention </p>    
-</section>
 </section>
   </body>
 </document>

Modified: lenya/docu/src/documentation/content/xdocs/1_2_x/misc/unittests.xml
URL: http://svn.apache.org/viewcvs/lenya/docu/src/documentation/content/xdocs/1_2_x/misc/unittests.xml?rev=170282&r1=170281&r2=170282&view=diff
==============================================================================
--- lenya/docu/src/documentation/content/xdocs/1_2_x/misc/unittests.xml (original)
+++ lenya/docu/src/documentation/content/xdocs/1_2_x/misc/unittests.xml Sun May 15 16:56:54 2005
@@ -37,23 +37,23 @@
 
 <section><title>Organization</title>
 <ul>
-<li><p>  Put your test classes in <tt>src/test</tt>. </p>
+<li><p>  Put your test classes in <em>src/test</em>. </p>
 </li>
-<li><p>  Add the ant task that executes your test to <tt>src/targets/test-build.xml</tt>. </p>
+<li><p>  Add the ant task that executes your test to <em>src/targets/test-build.xml</em>. </p>
 
 </li>
 </ul>
 
 </section><section><title id="head-655f58cfc0972b961e3661ac08aac2ff99ca1b48">The Test Publication</title>
 
-<p>Most tests will need a publication in the install (servlet container) directory. To provide a predictable test publication, the clean <tt>default</tt> publication from the build directory is copied to the <tt>test</tt> publication in the installation directory. </p>
-<p>In the test buildfile, the test publication is setup by the <tt>test.pub.prepare</tt> target. The directory {{${install.dir}/lenya/pubs/test}} is deleted (so that the files created by former tests are removed), and the default publication is copied to this directory. Add this target to the <tt>depends</tt> attribute of your test target if you need the test publication. </p>
+<p>Most tests will need a publication in the install (servlet container) directory. To provide a predictable test publication, the clean <em>default</em> publication from the build directory is copied to the <em>test</em> publication in the installation directory. </p>
+<p>In the test buildfile, the test publication is setup by the <em>test.pub.prepare</em> target. The directory {{${install.dir}/lenya/pubs/test}} is deleted (so that the files created by former tests are removed), and the default publication is copied to this directory. Add this target to the <em>depends</em> attribute of your test target if you need the test publication. </p>
 
 </section><section><title id="head-65a89586ffaf2c23e63e3cf91ac1e6e40cd84cc6">The PublicationHelper</title>
 
-<p>To simplify the acces to a publication you can use the class <tt>org.apache.lenya.cms.PublicationHelper</tt>. It provides the following methods: </p>
+<p>To simplify the acces to a publication you can use the class <em>org.apache.lenya.cms.PublicationHelper</em>. It provides the following methods: </p>
 
-<pre>
+<source>
     /**
      * Initializes the object with the first parameters from the command
      * line arguments &lt;code&gt;args&lt;/code&gt;. The remainder of the array is returned.
@@ -68,12 +68,12 @@
      * @return A publication object.
      */
     public static Publication getPublication();
-</pre>
+</source>
 
-<p>The <tt>extractPublicationArguments(String[])</tt> method extracts the first two strings from the <tt>args</tt> parameter. The first one is the servlet context path, the second is the publication ID. </p>
-<p>To make use of the PublicationHelper, you have to call the <tt>extractPublicationArguments(String[])</tt> method in the <tt>main(String())</tt> method of your <tt>TestCase</tt> class. This initializes the PublicationHelper: </p>
+<p>The <em>extractPublicationArguments(String[])</em> method extracts the first two strings from the <em>args</em> parameter. The first one is the servlet context path, the second is the publication ID. </p>
+<p>To make use of the PublicationHelper, you have to call the <em>extractPublicationArguments(String[])</em> method in the <em>main(String())</em> method of your <em>TestCase</em> class. This initializes the PublicationHelper: </p>
 
-<pre>
+<source>
     public static void main(String[] args) {
 
         // extract the arguments needed for setting up the publication
@@ -82,12 +82,12 @@
 
         ...
     }
-</pre>
+</source>
 
 </section><section><title id="head-8878fcb8bad4bee373aa2a9f486fa1b5ac58586c">A TestCase Skeleton</title>
 
 
-<pre>
+<source>
 public class MyTest extends TestCase {
 
     // static fields to store test parameters
@@ -135,14 +135,14 @@
         return configFile;
     }
 }
-</pre>
+</source>
 
 </section><section><title id="head-d0a01800d3a5e8cc04a8fca0bdb4fd67dec4db20">Debugging a Test</title>
 
-<p>For debugging, it might be desired to run the test from an API. In this case, the <tt>main(String[])</tt> method is never executed. </p>
-<p>To provide the parameters, you can hardcode them as fallback in the !<a  class="nonexistent" href="/lenya/TestCase">?</a>TestCase.setup() method that is called before the test is invoked: </p>
+<p>For debugging, it might be desired to run the test from an API. In this case, the <em>main(String[])</em> method is never executed. </p>
+<p>To provide the parameters, you can hardcode them as fallback in the TestCase.setup() method that is called before the test is invoked: </p>
 
-<pre>
+<source>
     /** @see junit.framework.TestCase#setUp() */
     protected void setUp() throws Exception {
         if (getConfigFile() == null) {
@@ -154,11 +154,11 @@
             setConfigFile("config/something.xconf");
         }
     }
-</pre>
+</source>
 
 </section><section><title id="head-d8c100285806e70cf61740be84709676e34fd9c4">The Test Buildfile</title>
 
-<p>The test buildfile is located at <tt>src/targets/test-build.xml</tt>. It contains the following common targets: </p>
+<p>The test buildfile is located at <em>src/targets/test-build.xml</em>. It contains the following common targets: </p>
 <ul>
 <li><p>  <strong>test</strong> - Runs all tests. </p>
 </li>
@@ -176,10 +176,10 @@
 
 </section><section><title id="head-73e85ec07ad251e822d4a03aaf2f9a03b6473ec8">Adding the Test to the Buildfile</title>
 
-<p>To add your test to the buildfile, you create a target called <tt>test.&lt;name&gt;</tt>. </p>
-<p>If you use assertions (Java assertions, not the JUnit ones) in your test, it is important to enable them using the <tt>-ea</tt> or <tt>-enableassertions</tt> argument. </p>
+<p>To add your test to the buildfile, you create a target called <em>test.&lt;name&gt;</em>. </p>
+<p>If you use assertions (Java assertions, not the JUnit ones) in your test, it is important to enable them using the <em>-ea</em> or <em>-enableassertions</em> argument. </p>
 
-<pre>
+<source>
   &lt;target name="test.my" depends="test.pub.prepare"&gt;
     &lt;!-- My Test --&gt;
     &lt;java fork="yes" classname="org.apache.lenya.cms.mypackage.MyTest"&gt;
@@ -201,26 +201,26 @@
       &lt;/classpath&gt;
     &lt;/java&gt;
   &lt;/target&gt;
-</pre>
-<p>Finally, you have to add the test to the <tt>tests.junit</tt> target: </p>
+</source>
+<p>Finally, you have to add the test to the <em>tests.junit</em> target: </p>
 
-<pre>
+<source>
 
 &lt;target name="tests.junit" depends="init, tests.prepare, ..., test.my"&gt;
-</pre>
+</source>
 <p>Now you can run the tests: </p>
 
-<pre>
+<source>
 $LENYA_HOME &gt; build test
-</pre>
+</source>
 <p>If you want to call your test independently, you have to call the preparation targets before: </p>
 
-<pre>
+<source>
 $LENYA_HOME &gt; build init
 $LENYA_HOME &gt; build tests.prepare
 $LENYA_HOME &gt; build test.my
 
-</pre></section>    
+</source></section>    
   </body>
 </document>
 

Modified: lenya/docu/src/documentation/content/xdocs/1_4/reference/lenya-sitemaps.xml
URL: http://svn.apache.org/viewcvs/lenya/docu/src/documentation/content/xdocs/1_4/reference/lenya-sitemaps.xml?rev=170282&r1=170281&r2=170282&view=diff
==============================================================================
--- lenya/docu/src/documentation/content/xdocs/1_4/reference/lenya-sitemaps.xml (original)
+++ lenya/docu/src/documentation/content/xdocs/1_4/reference/lenya-sitemaps.xml Sun May 15 16:56:54 2005
@@ -207,14 +207,14 @@
 
 <p>When reading the sitemaps in Lenya 1.4 you probably came across the lenya-scheme, often also referred to as the lenya protocol. For example, in the doctypes.xmap, you will find this section: </p>
 
-<pre>
+<source>
       &lt;!-- parametrized doctype matcher --&gt;
       &lt;!-- pattern="{rendertype}/{area}/{doctype}/{document-path}" --&gt;
       &lt;map:match pattern="*/*/*/**.xml"&gt;
         &lt;map:generate src="lenya:/{4}.xml"/&gt;
         &lt;map:transform src="fallback://xslt/{3}2xhtml.xsl"&gt;
 
-</pre>
+</source>
 <p>The lenya: scheme just needs the document path to locate the source document, i.e. lenya:/concepts/index_en.xml. All other elements of the actual storage location of the document (publication id and area) will be read from the page envelope and interpreted in the LenyaSourceFactory. </p>
 <p>In other words: The lenya: scheme hides the storage implementation details from the sitemap. </p>
 

Modified: lenya/docu/src/documentation/content/xdocs/community/translations.xml
URL: http://svn.apache.org/viewcvs/lenya/docu/src/documentation/content/xdocs/community/translations.xml?rev=170282&r1=170281&r2=170282&view=diff
==============================================================================
--- lenya/docu/src/documentation/content/xdocs/community/translations.xml (original)
+++ lenya/docu/src/documentation/content/xdocs/community/translations.xml Sun May 15 16:56:54 2005
@@ -36,19 +36,19 @@
 <p>The latter one is a publication specific translation file which gets merged with the global one. The publication specific translations will override the global ones. 
  
 
- An example name for a dictionary file is <tt>cmsui_de.xml</tt> or <tt>cmsui_fr.xml</tt> where <tt>_de</tt> and <tt>_fr</tt> are the official locale extensions. If you want to contribute a translation, make a copy of <tt>cmsui.xml</tt> , add your locale extension to the file name, and translate the text as shown below </p>
+ An example name for a dictionary file is <em>cmsui_de.xml</em> or <em>cmsui_fr.xml</em> where <em>_de</em> and <em>_fr</em> are the official locale extensions. If you want to contribute a translation, make a copy of <em>cmsui.xml</em> , add your locale extension to the file name, and translate the text as shown below </p>
 
 <p>Change </p>
 
-<pre>
+<source>
 &lt;message key="lenya.news.main.title"&gt;Maintain News&lt;/message&gt;
-</pre>
+</source>
 <p>to </p>
 
-<pre>
+<source>
 &lt;message key="lenya.news.main.title"&gt;News verwalten&lt;/message&gt;
 
-</pre>
+</source>
 <p>When you are done, submit a bug report to Bugzilla and attach your new dictionary file. That way, it gets noticed and can be added to Lenya. </p>
 
 </section><section><title id="head-3dccef277d6eba19c1ecd022ab2023c746c4de85">Message Key Naming Conventions</title>
@@ -67,13 +67,13 @@
 </section><section><title id="head-a95e9b852ff1f985e7b7c2c1cabaa430129dcc04">Global Message Keys</title>
 
 
-<pre>
+<source>
 &lt;message key="lenya.common.delete.label"&gt;Delete&lt;/message&gt;
 &lt;message key="lenya.common.delete.hint"&gt;Delete object&lt;/message&gt;
 
 &lt;message key="lenya.common.delete.label"&gt;Cancel&lt;/message&gt;
 &lt;message key="lenya.common.delete.hint"&gt;Cancel current action.&lt;/message&gt;
-</pre>
+</source>
 
 <p> 
  In the above examples the context is lenya.common which indicates the global context. </p>
@@ -81,10 +81,10 @@
 </section><section><title id="head-72f923ab0c18f9c75ebdec73ae50097813e5c0fe">Context Specific Message Keys</title>
 
 
-<pre>
+<source>
 &lt;message key="lenya.news.main.title"&gt;Maintain News&lt;/message&gt;
 &lt;message key="lenya.news.delete.hint"&gt;Delete all selected news items.&lt;/message&gt;
-</pre>
+</source>
 
 <p> 
  It is up to the message author how long(detailed) the context prefix is. </p>

Modified: lenya/docu/src/documentation/content/xdocs/index.xml
URL: http://svn.apache.org/viewcvs/lenya/docu/src/documentation/content/xdocs/index.xml?rev=170282&r1=170281&r2=170282&view=diff
==============================================================================
--- lenya/docu/src/documentation/content/xdocs/index.xml (original)
+++ lenya/docu/src/documentation/content/xdocs/index.xml Sun May 15 16:56:54 2005
@@ -35,12 +35,11 @@
       <ul>
         <li>Two Lenya presentations at <a href="ext:apachecon">ApacheCon Europe 2005</a> (Stuttgart, Germany
 18-22 July 2005)</li>
+        <li>New <a href="site:how-to">Lenya How-To's</a> posted (May 15, 2005) </li>
         <li>Lenya 1.2.3 released (May 1, 2005) </li>
         <li>New <a href="site:tutorial">Lenya tutorials</a> posted (April 24, 2005) </li>
         <li>Lenya 1.2.2 released (February 28, 2005) </li>
         <li>Lenya 1.2.1 released (December 29, 2004) </li>
-        <li>Apache Lenya becomes a top-level Apache project. (September 22, 2004)</li>
-        <li>Lenya 1.2 released (June 27, 2004) </li>
       </ul>
     </section>
 		



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@lenya.apache.org
For additional commands, e-mail: commits-help@lenya.apache.org