Hi all,
<READ THIS FIRST>
Sorry for the cross posting, but I think that this is important to bring up
the issue across a few lists. If you would like to discuss this, please
subscribe to and only respond to the Turbine mailing list. You can subscribe
by sending email to [EMAIL PROTECTED]
</READ THIS FIRST>
This document is to explain a different type of philosophy for working with
Context based MVC tools like WebMacro (WM) and Velocity (V) than I think
that the Turbine community is used to. The requirement for this philosophy
has come up recently during Scarab 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...
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.
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.
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. In order to do so, you can't simply change the Next/Back
links you need to also change the Java code. This is bad because at least
for CollabNet, our clients will require us to provide that ability.
So, beginning with Scarab, I am 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.
Instead of the developer telling the designer what Context names to use for
each and every screen, there is instead a "global" set of objects available
for the template designer to pick and choose from. 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 stuffs these 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.
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.
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.
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.
I'm going to start working on a framework that will make it easy to create a
container framework for these objects that will allow them to easily deal
with the multithreading issues as well as the caching issues involved with
these objects. I suspect that I will be able to rely on Turbine's Services
model as well as Turbine's Global cache model for the basis of most of this
code.
Comments are appreciated.
thanks,
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
