| <?xml version="1.0"?> |
| <!-- |
| /* |
| * Copyright 2001-2004 The Apache Software Foundation. |
| * |
| * Licensed under the Apache License, Version 2.0 (the "License"); |
| * you may not use this file except in compliance with the License. |
| * You may obtain a copy of the License at |
| * |
| * http://www.apache.org/licenses/LICENSE-2.0 |
| * |
| * Unless required by applicable law or agreed to in writing, software |
| * distributed under the License is distributed on an "AS IS" BASIS, |
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| * See the License for the specific language governing permissions and |
| * limitations under the License. |
| */ |
| --> |
| |
| <document> |
| |
| <properties> |
| <title>Pull vs. Push</title> |
| </properties> |
| |
| <body> |
| |
| <section name="Pull vs. Push"> |
| |
| <p>By: <a href="mailto:jon@latchkey.com">Jon S. Stevens</a> |
| <br/> |
| $Date$ |
| </p> |
| |
| <p> |
| This document is to explain a different type of philosophy for working with |
| Context based MVC tools like WebMacro (WM) and <a |
| href="http://jakarta.apache.org/velocity/">Velocity</a> (V) than I think that |
| the Turbine community is used to. The requirement for this philosophy has come |
| up recently during <a href="http://scarab.tigris.org/">Scarab</a> |
| development and I would like to share and document it with you all. Many thanks |
| to Brian B for being patient with me and trying to explain exactly what he wants |
| to see. So, let me start off by giving a little bit of history and then moving |
| on from there... |
| </p> |
| |
| <p> |
| The current encouragement that Turbine gives to developers is to do a mapping |
| between one Screen (Java) and one Template (WM or V). The way it works is that |
| you build up a Context object that is essentially a Hashtable that contains all |
| of the data that is required to render a particular template. Within the |
| template, you refer to that data in order to format it for display. I will refer |
| to this as the "Push MVC Model." This IMHO is a perfectly acceptable, easy to |
| understand and implement approach. |
| </p> |
| |
| <p> |
| We have solved the problem of being able to display the data on a template |
| without requiring the engineer to make modifications to the Java code. In other |
| words, you can modify the look and feel of the overall website without the |
| requirement of having a Java engineer present to make the changes. This is |
| a very good step forward. |
| </p> |
| |
| <p> |
| However, it has a shortcoming in that it makes it more difficult to allow the |
| template designer (ie: a non programmer) the ability to move information on a |
| template from one template to another template because it would require the |
| logic in the Java code to be modified as well. For example, say you have a set |
| of "wizard" type screens and you want to change the order of execution of those |
| screens or even the order of the fields on those screens. In order to do so, you |
| can't simply change the Next/Back links you need to also change the Java code. |
| </p> |
| |
| <p> |
| Another example of this is if you have a form on a page and you want to be |
| able to split that form across several steps across several pages. In the |
| current model, you would have to potentially write/modify several Java classes. |
| In reality, this should be something that is easily modifiable by just a single |
| template engineer who doesn't necessarily even know Java. |
| </p> |
| |
| <p> |
| There are several considerations that one must take into consideration regarding |
| the design of a system to provide this level of abstraction. For example, when |
| someone submits the form and there is an error. Proper UI would suggest that you |
| should re-display the page with the previous form data filled in as well as an |
| error message that details the problems. You also need to consider the ability |
| to display the same form that may be pre-populated with information from the |
| database instead of as an error from the user. |
| </p> |
| |
| <p> |
| So, beginning with Scarab, we are going to try another model which I will |
| describe as the "Pull MVC Model". What this entails is the ability to create an |
| object that is able to "pull" the required information out at execution time |
| within the template. Thus, it becomes the job of the template designer to |
| understand the API of objects available to him/her to take advantage of. |
| </p> |
| |
| <p> |
| Instead of the developer telling the designer what Context names to use for each |
| and every screen, there is instead a set of a few objects available for the |
| template designer to pick and choose from. These objects will provide methods to |
| access the underlying information either from the database or from the |
| previously submitted form information. |
| </p> |
| |
| <p> |
| Gone are the days where one would have a Java class that would be responsible |
| for building the context up for the template. Instead, there would be a single |
| base class that places the few objects into the context for every request and |
| there is a documented API that the template designer can refer to in order to |
| access the information that he/she needs to get at. Of course this information |
| is only retrieved when requested and can also be managed in a cache for reuse. |
| </p> |
| |
| <p> |
| By moving to a "Pull" model, it becomes possible to more easily achieve complete |
| independence from the Java engineers in order to not only change the look and |
| feel (UI) of the site but also the information architecture (IA) layout and flow |
| of the site. |
| </p> |
| |
| <p> |
| While this puts more requirements on the Java engineer to make sure that the |
| template designer has a well defined API, it will save the Java engineer many |
| hours further down the road when the client requests IA changes because now the |
| responsibility is on the template designer to make the changes. Therefore the |
| increased initial developer time is justified in order to realize the long term |
| goals of the project. |
| </p> |
| |
| <p> |
| I hope that this makes sense to everyone. I'm sure that some of you are probably |
| saying "well, duh!." However, this is really not the model that has been |
| encouraged so far within Turbine nor within other products such as XMLC (which |
| actually operates *only* on the Push model), so I believe that it is somewhat |
| uncharted territory for some people. The only products that I can think of right |
| now that encourage this is JSP taglibs and Tea, however, I still feel as though |
| they have missed the boat on this in one way or another. |
| </p> |
| |
| <p> |
| Comments are appreciated. Please post them to the Turbine |
| <a href="http://jakarta.apache.org/site/mail.html">mailing list</a>. |
| </p> |
| |
| </section> |
| |
| </body> |
| </document> |