forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r291529 - /forrest/trunk/site-author/content/xdocs/docs_0_80/views-terminology.xml
Date Mon, 26 Sep 2005 03:34:35 GMT
Author: crossley
Date: Sun Sep 25 20:34:32 2005
New Revision: 291529

Remove foreign content.


Modified: forrest/trunk/site-author/content/xdocs/docs_0_80/views-terminology.xml
--- forrest/trunk/site-author/content/xdocs/docs_0_80/views-terminology.xml (original)
+++ forrest/trunk/site-author/content/xdocs/docs_0_80/views-terminology.xml Sun Sep 25 20:34:32
@@ -23,92 +23,23 @@
     <warning>This document is under development</warning>
+    <p>
+      This document will eventually define all of the terminology.
+      See various email to the forrest dev mailing list, especially
+      <a href="">Re: Defining Views
+      and see the draft document <code>site-author/content/xdocs/TR/2005/WD-forrest10.html</code>
+    </p>
     <section id="whatIsfv">
       <title>What *is* forrest:views (f:v)?</title>
-      <p> forrest:views is the codename for a forrest based implementation of 
+      <p> forrest:views is the codename for the Apache Forrest implementation of 
         the Core J2EE Pattern - <a 
-        href="site:v0.80//java-blueprints-pattern">Dispatcher View</a>. The 
-        following explanation is from [1] with their equivalent implementation 
-        in forrest:views. </p>
+        href="site:v0.80//java-blueprints-pattern">Dispatcher View</a>.
+      </p>
-    <section id="skinProblems">
-      <title>Problems which we have with old fashion skins (html)</title>
-      <p> The problem is a combination of the problems solved by the Front 
-        Controller and View Helper patterns in the presentation tier. There is 
-        no centralized component for managing access control, content retrieval 
-        or view management, and there is duplicate control code scattered 
-        throughout various views. Additionally, business logic and presentation 
-        formatting logic are intermingled within these views, making the system 
-        less flexible, less reusable, and generally less resilient to change. 
-        </p>
-      <p> In our case an old fashion skin are build by 4 different view helper 
-        (book2menu.xsl, document2html.xsl, site2xhtml.xsl and tab2menu.xsl). In 
-        this different files we have typically non modularized presentation 
-        formatting logic. Which makes it hard to reuse certain components in a 
-        flexible way. Some recent usecases wanted e.g. to generate a certain 
-        menu independent from our site.xml. Till now the menu is produced by 
-        book2menu.xsl, if you want to override it you need to create a new 
-        skin. </p>
-    </section>
-    <section id="Solution">
-      <title>Solution</title>
-      <p>Combine a controller and dispatcher with views and helpers to handle 
-        client requests and prepare a dynamic presentation as the response. 
-        Controllers do not delegate content retrieval to helpers, because these 
-        activities are deferred to the time of view processing. A dispatcher is 
-        responsible for view management and navigation and can be encapsulated 
-        either within a controller, a view, or a separate component. </p>
-      <p> Our basic prototype (codename: forrest:views) is implementing the 
-        following components to achieve above written. </p>
-      <section id="dispatcher">
-        <title>dispatcher - match="prepare.view.**"</title>
-        <p> The dispatcher is ATM within the internal.xmap of the internal.view 
-          plugin (i.v-p). The match="prepare.view.**" is responsible to 
-          dispatch the right view to process for the current request. </p>
-      </section>
-      <section id="view">
-        <title>view - default.fv </title>
-        <p> A view represents and displays information to the client. The 
-          information that is used in a display is retrieved from a model. 
-          Helpers (forrest:contracts, forrest:hooks and forrest:properties) 
-          support views by encapsulating and adapting a model for use in a 
-          display. </p>
-      </section>
-      <section id="helper">
-        <title>helper - forrest:contracts, forrest:hooks and 
-          forrest:properties</title>
-        <p> A helper is responsible for helping a view or controller complete 
-          its processing. Thus, helpers have numerous responsibilities, 
-          including gathering data required by the view (done by 
-          forrest:properties) and storing this intermediate model, in which 
-          case the helper is sometimes referred to as a value bean. 
-          Additionally, helpers may adapt this data model for use by the view 
-          (done by forrest:contracts). Helpers can service requests for data 
-          from the view by simply providing access to the raw data or by 
-          formatting the data as Web content. </p>
-      </section>
-      <section id="businessService">
-        <title>businessService - input plugins </title>
-        <p> The business service is a role that is fulfilled by the service the 
-          client is seeking to access. Typically, the business service is 
-          accessed via a business delegate. The business delegate's role is to 
-          provide control and protection for the business service (see 
-          "Business Delegate" on page 248). </p>
-      </section>
-    </section>
-    <!--
-      Copy n' paste template:
-      <section id="leather">
-        <title>leather-dev</title>
-        <p>
-        </p>
-      </section>
-    -->
     <section id="info">
       <title>Further information</title>
       <p> See the various How-to documents about views, starting with <a 
         href="site:v0.80//howto/view/install">installing views</a>. </p>
\ No newline at end of file

View raw message