forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gmcdon...@apache.org
Subject svn commit: r521680 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml
Date Fri, 23 Mar 2007 11:45:04 GMT
Author: gmcdonald
Date: Fri Mar 23 04:45:03 2007
New Revision: 521680

URL: http://svn.apache.org/viewvc?view=rev&rev=521680
Log:
Fix typos,update example structurer filename

Modified:
    forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml

Modified: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml?view=diff&rev=521680&r1=521679&r2=521680
==============================================================================
--- forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml
(original)
+++ forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml
Fri Mar 23 04:45:03 2007
@@ -49,12 +49,12 @@
         formats from different content through an advanced seperation of 
         concerns.</p>
       <p>The dispatcher is a filter that limits the data-model to a minimum by 
-        only requesting what the strucuter (e.g. common.fv) need. This leads to 
+        only requesting what the structurer (e.g. common-html.vt.xml) need. This leads to

         a different URL handling focus - away from document centric. A document 
-        can (but do not have to) be behind a certain URL. Like said a 
+        can (but does not have to) be behind a certain URL. Like said a 
         structurer can request any given data as input not only a document and 
         the forrest core contracts (like navigation). It may be the main 
-        enhancement in comparison to skins that this concept let you easily 
+        enhancement in comparison to skins that this concept lets you easily 
         extend the default data models provided by forrest.</p>
       <p>Since the dispatcher has implemented a fallback concept it makes 
         maintenance of custom themes which are based on forrest core ones very 
@@ -63,7 +63,7 @@
         observation that normally only a small percentage of core skin 
         contracts have been changed. At the same time the new plugin system 
         emerged. Plugins are a way of extending Forrest to satisfy 
-        site-specific needs. This includes to provide plugin specific 
+        site-specific needs. This includes to provide for plugin specific 
         contracts.</p>
       <section id="structurer">
         <title>Structurer - configuration for themes</title>
@@ -96,30 +96,30 @@
       (which offer configuration parameter in the structurer) and dynamic 
       contracts (which offer semi-static configuration and/or requesting the 
       content).  </p>
-      <p> The structurer is as well a configuration file for the dispatcher. 
-        The new think on the dispatcher is that one can include any content 
+      <p> The structurer is also a configuration file for the dispatcher. 
+        The new thinking on the dispatcher is that one can include any content 
         from any given business service by dispatching a request against it. In 
         "old fashion" skins and in v1 contracts we assumed a given data model. 
         In the dispatcher there is <strong>no</strong> given data model any 
-        more. All data has to be defined in the structurer that they can be 
+        more. All data has to be defined in the structurer so that they can be 
         dispatched. </p>
       </section>
       <section id="contracts">
         <title>Contracts - grouped functionality</title>
-        <p>The result of the leather-dev development were grouped functionality 
-          in named container. We gave those code snippets names (based on their 
-          functionality) and called them contracts. This naming enabled us to 
-          keep the contract separate from the position code itself. Further 
-          since major parts of the code of skins never have been documentended 
-          we started to add for each contract a description and an explanation 
+        <p>The result of the leather-dev development was grouped functionality 
+          in named containers. We gave those code snippets names (based on their 
+          functionality) and called them <strong>contracts</strong>. This naming
enabled us to 
+          keep the contract separate from the positioning of the code itself. Furthermore,

+          since major parts of the code of skins has never been documented, 
+          we started to add for each contract a description and an explanation on
           how to use this contract. The skinconf.xml gave an excellent 
           source for this documentation effort, since it described most 
           features of the pelt skin.</p>
           <p>Contracts are standalone, self explaining, configurable 
-            pieces of xsl templates created out of pure maintaining reasons.</p>
-          <p>Since this contracts are working from the input given in the <a 
+            pieces of xsl templates created purely for ease of maintenance.</p>
+          <p>Since these contracts are working from the input given in the <a 
             href="#structurer">structurer</a>, it works on different input 
-            sources. Further one can pass variables into the contracts that can 
+            sources. One can pass variables into the contracts that can 
             be used to apply presentation logic in the xsl (like sorting order, 
             ...).</p>
       </section>
@@ -146,15 +146,15 @@
         <title>leather-dev</title>
         <p> That led to the development of the "leather-dev" skin which 
           established a semantic container approach for div elements. 
-          Leather-dev evolved from the "pelt" skin and almost used the same 
+          Leather-dev evolved from the "pelt" skin and used almost the same 
           functionality (contracts). We had started to encapsulate functional 
           code into templates, but there have been still in 4 xsl files and without 
-          any documentation what they are doing and how to use them. The 
+          any documentation on what they are doing and how to use them. The 
           problems with leather-dev was pointed out in the mail "<a 
           href="http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=111049344517653" 
           >status on leather-dev?</a>". The main proplem was to limit users to 
-          only one html-skeleton was way too limiting regarding design. Since 
-          we had now grouped functionality in named container we were ready to 
+          only one html-skeleton which was way too limiting regarding design. Since 
+          we had now grouped functionality in named containers we were ready to 
           start the dispatcher (aka forrest:views).</p>
       </section>
     </section>



Mime
View raw message