You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by ra...@apache.org on 2001/04/18 20:07:56 UTC
cvs commit: jakarta-turbine/docs/proposals unified-templating.html browser-bound-app-context.html
rafal 01/04/18 11:07:55
Modified: xdocs proposals.xml
xdocs/proposals browser-bound-app-context.xml
docs proposals.html
docs/proposals browser-bound-app-context.html
Added: xdocs/proposals unified-templating.xml
docs/proposals unified-templating.html
Log:
added unified templating and window contexts proposals
improved markup in proposals.xml a bit.
Revision Changes Path
1.4 +17 -17 jakarta-turbine/xdocs/proposals.xml
Index: proposals.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine/xdocs/proposals.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- proposals.xml 2001/04/16 05:56:51 1.3
+++ proposals.xml 2001/04/18 18:07:45 1.4
@@ -15,24 +15,24 @@
</p>
<ul>
-<li><a href="proposals/application-service.html"></a>Application Service</li>
+<li><a href="proposals/application-service.html">Application Service</a></li>
<li><a href="proposals/browser-bound-app-context.html">Browser Bound Application Context</a></li>
-<li><a href="proposals/bsf-service.html"></a>BSF Service</li>
-<li><a href="proposals/core-processing.html"></a>Core Processing</li>
-<li><a href="proposals/i18n.html"></a>i18n</li>
-<li><a href="proposals/naming-service.html"></a>Naming Service</li>
-<li><a href="proposals/package-cleanup.html"></a>Package Cleanup</li>
-<li><a href="proposals/peers.html"></a>Peer</li>
-<li><a href="proposals/policy-service.html"></a>Policy Service</li>
-<li><a href="proposals/pp.html"></a>PP and Related Classes</li>
-<li><a href="proposals/resources-service.html"></a>Resources Service</li>
-<li><a href="proposals/reusable-components.html"></a>Reusable Components</li>
-<li><a href="proposals/scheduler-service.html"></a>Scheduler Service</li>
-<li><a href="proposals/security-service.html"></a>Security Service</li>
-<li><a href="proposals/services-framework.html"></a>Services Framework</li>
-<li><a href="proposals/services-repository.html"></a>Services Repository</li>
-<li><a href="proposals/xslt-service.html"></a>XSLT Service</li>
-
+<li><a href="proposals/bsf-service.html">BSF Service</a></li>
+<li><a href="proposals/core-processing.html">Core Processing</a></li>
+<li><a href="proposals/i18n.html">i18n</a></li>
+<li><a href="proposals/naming-service.html">Naming Service</a></li>
+<li><a href="proposals/package-cleanup.html">Package Cleanup</a></li>
+<li><a href="proposals/peers.html">Peer</a></li>
+<li><a href="proposals/policy-service.html">Policy Service</a></li>
+<li><a href="proposals/pp.html">PP and Related Classes</a></li>
+<li><a href="proposals/resources-service.html">Resources Service</a></li>
+<li><a href="proposals/reusable-components.html">Reusable Components</a></li>
+<li><a href="proposals/scheduler-service.html">Scheduler Service</a></li>
+<li><a href="proposals/security-service.html">Security Service</a></li>
+<li><a href="proposals/services-framework.html">Services Framework</a></li>
+<li><a href="proposals/services-repository.html">Services Repository</a></li>
+<li><a href="proposals/xslt-service.html">XSLT Service</a></li>
+<li><a href="proposals/unified-templating.html">Unified Templating Service</a></li>
</ul>
</section>
1.2 +131 -18 jakarta-turbine/xdocs/proposals/browser-bound-app-context.xml
Index: browser-bound-app-context.xml
===================================================================
RCS file: /home/cvs/jakarta-turbine/xdocs/proposals/browser-bound-app-context.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- browser-bound-app-context.xml 2001/04/16 05:56:52 1.1
+++ browser-bound-app-context.xml 2001/04/18 18:07:49 1.2
@@ -11,25 +11,138 @@
<section name="Browser window bound application context">
+<p><b>The problem: multiple windows</b></p>
<p>
- <li>
- SessionContext interface similar to that of ServletSession
- </li>
-
- <li>
- getGlobalContext() and getLocalContext() methods in RunData
- </li>
-
- <li>
- objects stored in local context must be Cloneable (they
- will be cloned per every hit. A configurable number of local
- contexts will be kept, so that user may continue a sub-session
- from an alternate window)
- </li>
-
- <li>
- those will not interfere with normal usage of Servlet session
- </li>
+Suppose that you write an application that will have the ability to open
+multiple windows at once. These windows will contain views for different
+application modules. Sometimes, different windows will show the same module,
+but the data or it's presentation form will be different. It is obvious that
+each of the windows has an amount of state information associated with it. The
+HTTP protocol is by design stateless. Because statefullness is necessary for a
+multitude of applications, cookies mechanism was introduced. Usually, the
+cookies passed between the server and browser carry only an identifier of the
+session. The actual data is kept in the servers memory (or other storage device)
+Unfortunately cookies are not appropriate for managing state information
+associated with a single window. The primary way of overcoming this limitation
+is encoding information about the subset of data to be displayed and the
+presentation details (like sorting order) into the request URLs. This technique
+allows the user to maintain multiple simultaneous sessions with the same screen
+of the application in different browser windows, viewing different data sets or
+using different presentation settings. This technique might be unacceptable in
+two situations:
+</p>
+<ul>
+<li>the presentation settings should not be visible in the URL so that the user
+can not tamper with them. </li>
+<li> the amount of state information is large and/or the generated page contains
+large number of links. This would lead to generating large amounts of markup,
+decreasing application responsiveness and consuming resources.</li>
+</ul>
+
+<p><b>The solution: server side window context</b></p>
+<p>
+A technique similar to that applied to global session data. Window specific
+information can be stored on the server, and an token allowing to uniquely
+identify this information can be added to all URLs generated on the page.
+This way on the next request originating from a given browser window, the
+application has access to the state information associated with this window.
+</p>
+
+<p><b>The problem: "Open in new window"</b></p>
+<p>
+If opening of windows in a multi-windowed application is utterly under control
+of the application (the window is created using JavaScript, with context
+identifier token removed from the URL, to inform the application that it needs
+to create a new context) window contexts will work fine. In reality users will
+often create new windows using "open in new window" command, or by dragging
+URLs between windows. In each of the situations mentioned above, multiple
+windows displaying the same URL (and thus, by definition the same collection
+of cookies will appear. These windows are indistinguishable to the application,
+but it is undesirable that these windows share the window context. That would
+mean that changes to the state information performed in one window would affect
+all future requests to the other windows in the group.
+</p>
+
+<p><b>The solution: session context tree</b></p>
+<p>
+To effectively detect opening of windows, the token identifying a session
+context must be different for every request. Please recall the example of a few
+windows opened "open in new window" command. All of them share the URL, and the
+context identifying token contained in it. This means that they can access the
+state information that was valid during the previous request. The data subset
+displayed and the presentation settings used in all of the windows is the same.
+But because there are multiple windows now, the session context must split. New
+contexts must be created, inheriting the contents of the parent (previous)
+context, an tokens identifying these newly generated context must be included
+in all URLs generated on the associated pages.
+</p>
+
+
+<p><b>The problem: the "back" button</b></p>
+<p>
+While reading the previous paragraph, you may have an impression that it is
+possible to perform educated guesses about context branching points and store
+only as many contexts as there are windows simultaneously open. But when you
+consider the situation when user uses "back" and "forward" buttons to navigate
+the application, you'll find out that ALL of the contexts must be remembered
+by the server. The state information associated with each request may be used
+multiple times in the future. An LRU garbage collection scheme could be
+performed on the context objects (only a fixed number of most recently accessed
+context would be remembered) to conserve server's memory. Unfortunately, this
+could easily lead to undesirable application operation. Imagine an application
+with two windows open. An user performs an operation in the window A, then
+switches to window B an performs so many operations in it that the context of
+the window A is discarded. Then, performing an operation in the window A may
+yield unexpected results because the state information was lost.
+</p>
+
+<p><b>Explicit vs Implicit cloning.</b></p>
+
+<p>
+All of the the session contexts have to be replicated per every hit to the
+application. Memory consumption seems like an important factor to consider
+here. I had an idea of reducing it a bit, by requiring the programmer to
+explicitly copy the data from the previous context to the current context
+that are important. This is makes using session contexts tedious, but
+avoids cloning unused data over and over, when the user moves from one
+screen to another (which will obviously need different state information).
+This has the following downside - when the user uses a link to go back
+to a screen that he visited earlier, the state information will be lost,
+because the other screen didn't clone it (because it had no idea about them).
+The presentation details will be reset to normal. On the other hand, if
+the user pressed the "back" button multiple times to go back to that screen,
+the presentation details would be remembered (the URLs contain valid
+context identifier tokens). The conclusion is, that cloning all of the
+stuff contained in the context gives a better user experience. Memory is
+cheap these days, right? Oh, don't worry that those context have to stay
+in memory forever. They should be bound to a global (cookie style) session
+and discarded when the global session times out.
+</p>
+
+<p><b>A sketch of implementation</b></p>
+
+<p>
+<ul>
+ <li>
+ SessionContext interface similar to that of ServletSession
+ </li>
+ <li>
+ getGlobalContext() and getLocalContext() methods in RunData
+ </li>
+ <li>
+ a wrapper object containing a global context and multiple
+ local context keyed by id, to be stored in the HTTP session
+ </li>
+ <li>
+ context id tokens automatically picked up (after ParameterParser
+ runs) and the context extracted/cloned/created as needed using
+ the wrapper object from the session, and appropriate contexts
+ made available through RunData
+ </li>
+ <li>
+ context id added to the url by the DynamicURI et al
+ </li>
+</ul>
</p>
</section>
1.1 jakarta-turbine/xdocs/proposals/unified-templating.xml
Index: unified-templating.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Unified Templating Service Proposal</title>
<author email="rafal@apache.org">Rafal Krzewski</author>
</properties>
<body>
<section name="Unified Templating Service">
<p>
There are multiple templating services that provide similar functionality, but
have different API. This is due to different types of "Context" objects. All
these types main"Map" semantics (question: is there any other important
functionality in the Contexts?). We could define a single service interface
that all of the templating services (WebMacro, Velocity, FreeMarker and JSP at
the moment) would implement. Its methods would use Map type to represent a
Context or another interface extending or similar to map. The service would
include the following methods:
</p>
<pre>
public interface TemplatingService
extends Service
{
public boolean templateExists( String name );
public Map createContext( RunData data );
public Map createContext( );
public Strinq merqeTemplate( String name, Map context );
}
</pre>
<p>
Definition of this common interface would allow creation of new base Modules
(Screen, Navigation, Layout and Page) that would take advantage of the
templating abstraction provided by the Service. This would make the modules
(esp. Screens) contained in the application independent of the particular
templating mechanism.
</p>
<p>
I don't know enough about FreeMarker to tell if it can fit into this model.
If not, I would even suggest dropping the support for it, as it's user base
seems nonexistent.
</p>
<p>
There is one important special case to consider. JSP service is unable to return
the results of template merging as a String - they are written to the Response
stream directly. To encompass this case in our framework, we could declare that
the return value of merge template in this case is a null. The Modules would be
subject to the same semantics: a null returned from build() method would mean that
data was written to the response directly, and the caller should act accordingly.
(an example of such case is the interaction of the Layout and the RawScreen).
</p>
<p>
The special semantics of JSP templating lead in turn to a special Page and Layout
module behavior. While the "normal" Layout module executes the Screen module
and merges its template before merging it's own template ("prefix" rendering),
the JSP Layout needs to wrap Screen rendering in a context tool so that it is
executed in the appropriate place in the Layout's markup. ("infix" rendering).
The same patterns apply to Page-Layout interaction. We have the option to define
JSPPage and JSPLayout Modules, or define InfixPage, InfixLayout and the
LayoutRenderer and ScreenRenderer context tools, that will be used with those
templating services that write the merging results directly to the Response
stream. Note that during the normal Layout processing, the Navigations are
subject to "infix" rendering, and the current TemplateNavigation class is a
prototype of *Renderer.
</p>
<p>
The unified interface and the Infix* Modules will make adding support for other
templating engines easy. This will also make porting applications easier -
templates in one templating language can be created, then supporting Turbine
modules are created. Later the templates can be converted to another language,
and the only change to support that on the code side of things is switching a
property in TR.props
</p>
<p>
The template lookup functionality that is currently contained in
TemplateService, probably should be contained in the service I'm describing here,
probably in an abstract base class.
</p>
<p>
Another class that would be affected by the changes mentioned here is the
TempateInfo class. Right now it uses a HashTable to store it's data.
Now, thanks to defining the common Context type (or using the Map type
in its place), it's possible to turn the runtime typed HashTable entries into
compile time typed instance variables.
</p>
<p>
The amount of work needed to port an existing application should not be very large.
The applications following the Pull MVC design model would not be affected at all.
The traditional Push applications would require changes in the Screen and Navigation
classes regarding the names of the Context type and the parent type of the
Screen/Navigation in question. These changes can be effectively introduced using an
automated tool.
</p>
<p>
The Page and Layout classes would require more in-depth modifications, but a typical
application would contain single customized Page and Layout classes, if any.
</p>
</section>
</body>
</document>
1.10 +17 -17 jakarta-turbine/docs/proposals.html
Index: proposals.html
===================================================================
RCS file: /home/cvs/jakarta-turbine/docs/proposals.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- proposals.html 2001/04/18 13:57:30 1.9
+++ proposals.html 2001/04/18 18:07:52 1.10
@@ -146,24 +146,24 @@
These are the proposals that are up on the table:
</p>
<ul>
-<li><a href="proposals/application-service.html" />Application Service</li>
+<li><a href="proposals/application-service.html">Application Service</a></li>
<li><a href="proposals/browser-bound-app-context.html">Browser Bound Application Context</a></li>
-<li><a href="proposals/bsf-service.html" />BSF Service</li>
-<li><a href="proposals/core-processing.html" />Core Processing</li>
-<li><a href="proposals/i18n.html" />i18n</li>
-<li><a href="proposals/naming-service.html" />Naming Service</li>
-<li><a href="proposals/package-cleanup.html" />Package Cleanup</li>
-<li><a href="proposals/peers.html" />Peer</li>
-<li><a href="proposals/policy-service.html" />Policy Service</li>
-<li><a href="proposals/pp.html" />PP and Related Classes</li>
-<li><a href="proposals/resources-service.html" />Resources Service</li>
-<li><a href="proposals/reusable-components.html" />Reusable Components</li>
-<li><a href="proposals/scheduler-service.html" />Scheduler Service</li>
-<li><a href="proposals/security-service.html" />Security Service</li>
-<li><a href="proposals/services-framework.html" />Services Framework</li>
-<li><a href="proposals/services-repository.html" />Services Repository</li>
-<li><a href="proposals/xslt-service.html" />XSLT Service</li>
-
+<li><a href="proposals/bsf-service.html">BSF Service</a></li>
+<li><a href="proposals/core-processing.html">Core Processing</a></li>
+<li><a href="proposals/i18n.html">i18n</a></li>
+<li><a href="proposals/naming-service.html">Naming Service</a></li>
+<li><a href="proposals/package-cleanup.html">Package Cleanup</a></li>
+<li><a href="proposals/peers.html">Peer</a></li>
+<li><a href="proposals/policy-service.html">Policy Service</a></li>
+<li><a href="proposals/pp.html">PP and Related Classes</a></li>
+<li><a href="proposals/resources-service.html">Resources Service</a></li>
+<li><a href="proposals/reusable-components.html">Reusable Components</a></li>
+<li><a href="proposals/scheduler-service.html">Scheduler Service</a></li>
+<li><a href="proposals/security-service.html">Security Service</a></li>
+<li><a href="proposals/services-framework.html">Services Framework</a></li>
+<li><a href="proposals/services-repository.html">Services Repository</a></li>
+<li><a href="proposals/xslt-service.html">XSLT Service</a></li>
+<li><a href="proposals/unified-templating.html">Unified Templating Service</a></li>
</ul>
</blockquote>
</td></tr>
1.3 +123 -19 jakarta-turbine/docs/proposals/browser-bound-app-context.html
Index: browser-bound-app-context.html
===================================================================
RCS file: /home/cvs/jakarta-turbine/docs/proposals/browser-bound-app-context.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- browser-bound-app-context.html 2001/04/18 13:58:29 1.2
+++ browser-bound-app-context.html 2001/04/18 18:07:54 1.3
@@ -142,25 +142,129 @@
</td></tr>
<tr><td>
<blockquote>
- <p>
- <li>
- SessionContext interface similar to that of ServletSession
- </li>
-
- <li>
- getGlobalContext() and getLocalContext() methods in RunData
- </li>
-
- <li>
- objects stored in local context must be Cloneable (they
- will be cloned per every hit. A configurable number of local
- contexts will be kept, so that user may continue a sub-session
- from an alternate window)
- </li>
-
- <li>
- those will not interfere with normal usage of Servlet session
- </li>
+ <p><b>The problem: multiple windows</b></p>
+ <p>
+Suppose that you write an application that will have the ability to open
+multiple windows at once. These windows will contain views for different
+application modules. Sometimes, different windows will show the same module,
+but the data or it's presentation form will be different. It is obvious that
+each of the windows has an amount of state information associated with it. The
+HTTP protocol is by design stateless. Because statefullness is necessary for a
+multitude of applications, cookies mechanism was introduced. Usually, the
+cookies passed between the server and browser carry only an identifier of the
+session. The actual data is kept in the servers memory (or other storage device)
+Unfortunately cookies are not appropriate for managing state information
+associated with a single window. The primary way of overcoming this limitation
+is encoding information about the subset of data to be displayed and the
+presentation details (like sorting order) into the request URLs. This technique
+allows the user to maintain multiple simultaneous sessions with the same screen
+of the application in different browser windows, viewing different data sets or
+using different presentation settings. This technique might be unacceptable in
+two situations:
+</p>
+ <ul>
+<li>the presentation settings should not be visible in the URL so that the user
+can not tamper with them. </li>
+<li> the amount of state information is large and/or the generated page contains
+large number of links. This would lead to generating large amounts of markup,
+decreasing application responsiveness and consuming resources.</li>
+</ul>
+ <p><b>The solution: server side window context</b></p>
+ <p>
+A technique similar to that applied to global session data. Window specific
+information can be stored on the server, and an token allowing to uniquely
+identify this information can be added to all URLs generated on the page.
+This way on the next request originating from a given browser window, the
+application has access to the state information associated with this window.
+</p>
+ <p><b>The problem: "Open in new window"</b></p>
+ <p>
+If opening of windows in a multi-windowed application is utterly under control
+of the application (the window is created using JavaScript, with context
+identifier token removed from the URL, to inform the application that it needs
+to create a new context) window contexts will work fine. In reality users will
+often create new windows using "open in new window" command, or by dragging
+URLs between windows. In each of the situations mentioned above, multiple
+windows displaying the same URL (and thus, by definition the same collection
+of cookies will appear. These windows are indistinguishable to the application,
+but it is undesirable that these windows share the window context. That would
+mean that changes to the state information performed in one window would affect
+all future requests to the other windows in the group.
+</p>
+ <p><b>The solution: session context tree</b></p>
+ <p>
+To effectively detect opening of windows, the token identifying a session
+context must be different for every request. Please recall the example of a few
+windows opened "open in new window" command. All of them share the URL, and the
+context identifying token contained in it. This means that they can access the
+state information that was valid during the previous request. The data subset
+displayed and the presentation settings used in all of the windows is the same.
+But because there are multiple windows now, the session context must split. New
+contexts must be created, inheriting the contents of the parent (previous)
+context, an tokens identifying these newly generated context must be included
+in all URLs generated on the associated pages.
+</p>
+ <p><b>The problem: the "back" button</b></p>
+ <p>
+While reading the previous paragraph, you may have an impression that it is
+possible to perform educated guesses about context branching points and store
+only as many contexts as there are windows simultaneously open. But when you
+consider the situation when user uses "back" and "forward" buttons to navigate
+the application, you'll find out that ALL of the contexts must be remembered
+by the server. The state information associated with each request may be used
+multiple times in the future. An LRU garbage collection scheme could be
+performed on the context objects (only a fixed number of most recently accessed
+context would be remembered) to conserve server's memory. Unfortunately, this
+could easily lead to undesirable application operation. Imagine an application
+with two windows open. An user performs an operation in the window A, then
+switches to window B an performs so many operations in it that the context of
+the window A is discarded. Then, performing an operation in the window A may
+yield unexpected results because the state information was lost.
+</p>
+ <p><b>Explicit vs Implicit cloning.</b></p>
+ <p>
+All of the the session contexts have to be replicated per every hit to the
+application. Memory consumption seems like an important factor to consider
+here. I had an idea of reducing it a bit, by requiring the programmer to
+explicitly copy the data from the previous context to the current context
+that are important. This is makes using session contexts tedious, but
+avoids cloning unused data over and over, when the user moves from one
+screen to another (which will obviously need different state information).
+This has the following downside - when the user uses a link to go back
+to a screen that he visited earlier, the state information will be lost,
+because the other screen didn't clone it (because it had no idea about them).
+The presentation details will be reset to normal. On the other hand, if
+the user pressed the "back" button multiple times to go back to that screen,
+the presentation details would be remembered (the URLs contain valid
+context identifier tokens). The conclusion is, that cloning all of the
+stuff contained in the context gives a better user experience. Memory is
+cheap these days, right? Oh, don't worry that those context have to stay
+in memory forever. They should be bound to a global (cookie style) session
+and discarded when the global session times out.
+</p>
+ <p><b>A sketch of implementation</b></p>
+ <p>
+<ul>
+ <li>
+ SessionContext interface similar to that of ServletSession
+ </li>
+ <li>
+ getGlobalContext() and getLocalContext() methods in RunData
+ </li>
+ <li>
+ a wrapper object containing a global context and multiple
+ local context keyed by id, to be stored in the HTTP session
+ </li>
+ <li>
+ context id tokens automatically picked up (after ParameterParser
+ runs) and the context extracted/cloned/created as needed using
+ the wrapper object from the session, and appropriate contexts
+ made available through RunData
+ </li>
+ <li>
+ context id added to the url by the DynamicURI et al
+ </li>
+</ul>
</p>
</blockquote>
</td></tr>
1.1 jakarta-turbine/docs/proposals/unified-templating.html
Index: unified-templating.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Rafal Krzewski">
<meta name="email" value="rafal@apache.org">
<title>Turbine - Unified Templating Service Proposal</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/turbine/"><img src="../images/logo.gif" alt="Turbine" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>Essentials</strong></p>
<ul>
<li> <a href="../index.html">Overview</a>
</li>
<li> <a href="../features.html">Features</a>
</li>
<li> <a href="../fsd.html">Specification</a>
</li>
<li> <a href="../project-map.html">Project map</a>
</li>
<li> <a href="../install.html">Installation</a>
</li>
<li> <a href="../getting-started.html">Getting Started</a>
</li>
<li> <a href="../changes.html">Changes</a>
</li>
<li> <a href="../other-docs.html">Other Documentation</a>
</li>
</ul>
<p><strong>Models</strong></p>
<ul>
<li> <a href="../pullmodel.html">Pull MVC Model</a>
</li>
<li> <a href="../model2+1.html">Model 2+1</a>
</li>
<li> <a href="../j2ee-integration.html">J2EE Integration</a>
</li>
</ul>
<p><strong>Get Involved</strong></p>
<ul>
<li> <a href="../turbine-documentation-project.html">Turbine Documentation</a>
</li>
<li> <a href="../code-standards.html">Coding Spec</a>
</li>
<li> <a href="../contributors.html">Contributors</a>
</li>
<li> <a href="../branches.html">CVS Branches</a>
</li>
<li> <a href="http://jakarta.apache.org/site/cvsindex.html">CVS Repos</a>
</li>
<li> <a href="../faq.html">FAQ</a>
</li>
<li> <a href="../license.html">License</a>
</li>
<li> <a href="http://jakarta.apache.org/site/mail.html">Mailing Lists</a>
</li>
<li> <a href="../powered.html">Powered by Turbine</a>
</li>
<li> <a href="../todo.html">Todo</a>
</li>
<li> <a href="../active-developers.html">Active Developers</a>
</li>
<li> <a href="../proposals.html">Proposals</a>
</li>
</ul>
<p><strong>Documentation</strong></p>
<ul>
<li> <a href="../action-event.html">Action Events</a>
</li>
<li> <a href="../services.html">Services</a>
</li>
<li> <a href="../security.html">Turbine and Security</a>
</li>
<li> <a href="../python.html">Turbine and Python</a>
</li>
<li> <a href="../jsp-configuration.html">Turbine and JSP</a>
</li>
<li> <a href="../velocity-site.html">Velocity Site</a>
</li>
<li> <a href="../context-howto.html">Velocity Context</a>
</li>
<li> <a href="../webmacro-site.html">Webmacro Site</a>
</li>
</ul>
<p><strong>Database</strong></p>
<ul>
<li> <a href="../peers.html">Peers</a>
</li>
<li> <a href="../advpeers.html">Advanced Peers</a>
</li>
<li> <a href="../advcriteria.html">Advanced Criteria</a>
</li>
<li> <a href="../torque.html">Torque</a>
</li>
<li> <a href="../turbine-schema.html">Core Schema</a>
</li>
<li> <a href="../db-adapters.html">DB Adapters</a>
</li>
<li> <a href="../postgres-howto.html">Postgres Howto</a>
</li>
<li> <a href="../oracle-howto.html">Oracle 8i Howto</a>
</li>
<li> <a href="../sybase-howto.html">Sybase Howto</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Unified Templating Service"><strong>Unified Templating Service</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
There are multiple templating services that provide similar functionality, but
have different API. This is due to different types of "Context" objects. All
these types main"Map" semantics (question: is there any other important
functionality in the Contexts?). We could define a single service interface
that all of the templating services (WebMacro, Velocity, FreeMarker and JSP at
the moment) would implement. Its methods would use Map type to represent a
Context or another interface extending or similar to map. The service would
include the following methods:
</p>
<pre>
public interface TemplatingService
extends Service
{
public boolean templateExists( String name );
public Map createContext( RunData data );
public Map createContext( );
public Strinq merqeTemplate( String name, Map context );
}
</pre>
<p>
Definition of this common interface would allow creation of new base Modules
(Screen, Navigation, Layout and Page) that would take advantage of the
templating abstraction provided by the Service. This would make the modules
(esp. Screens) contained in the application independent of the particular
templating mechanism.
</p>
<p>
I don't know enough about FreeMarker to tell if it can fit into this model.
If not, I would even suggest dropping the support for it, as it's user base
seems nonexistent.
</p>
<p>
There is one important special case to consider. JSP service is unable to return
the results of template merging as a String - they are written to the Response
stream directly. To encompass this case in our framework, we could declare that
the return value of merge template in this case is a null. The Modules would be
subject to the same semantics: a null returned from build() method would mean that
data was written to the response directly, and the caller should act accordingly.
(an example of such case is the interaction of the Layout and the RawScreen).
</p>
<p>
The special semantics of JSP templating lead in turn to a special Page and Layout
module behavior. While the "normal" Layout module executes the Screen module
and merges its template before merging it's own template ("prefix" rendering),
the JSP Layout needs to wrap Screen rendering in a context tool so that it is
executed in the appropriate place in the Layout's markup. ("infix" rendering).
The same patterns apply to Page-Layout interaction. We have the option to define
JSPPage and JSPLayout Modules, or define InfixPage, InfixLayout and the
LayoutRenderer and ScreenRenderer context tools, that will be used with those
templating services that write the merging results directly to the Response
stream. Note that during the normal Layout processing, the Navigations are
subject to "infix" rendering, and the current TemplateNavigation class is a
prototype of *Renderer.
</p>
<p>
The unified interface and the Infix* Modules will make adding support for other
templating engines easy. This will also make porting applications easier -
templates in one templating language can be created, then supporting Turbine
modules are created. Later the templates can be converted to another language,
and the only change to support that on the code side of things is switching a
property in TR.props
</p>
<p>
The template lookup functionality that is currently contained in
TemplateService, probably should be contained in the service I'm describing here,
probably in an abstract base class.
</p>
<p>
Another class that would be affected by the changes mentioned here is the
TempateInfo class. Right now it uses a HashTable to store it's data.
Now, thanks to defining the common Context type (or using the Map type
in its place), it's possible to turn the runtime typed HashTable entries into
compile time typed instance variables.
</p>
<p>
The amount of work needed to port an existing application should not be very large.
The applications following the Pull MVC design model would not be affected at all.
The traditional Push applications would require changes in the Screen and Navigation
classes regarding the names of the Context type and the parent type of the
Screen/Navigation in question. These changes can be effectively introduced using an
automated tool.
</p>
<p>
The Page and Layout classes would require more in-depth modifications, but a typical
application would contain single customized Page and Layout classes, if any.
</p>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org