You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by gm...@apache.org on 2007/03/23 12:45:04 UTC
svn commit: r521680 -
/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml
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&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>
Re: svn commit: r521680 -
/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/documentation/content/xdocs/index.xml
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2007-03-23 at 11:45 +0000, gmcdonald@apache.org wrote:
> 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
...
> - 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.
Actually the structurer is still common.fv! You changed it to a panel
definition.
I will change this since IMO it is misleading.
Thanks for the update.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java & XML consulting, training and solutions