Jon Stevens wrote:
>
> on 4/6/01 12:35 AM, "Christoph Reck" <[EMAIL PROTECTED]> wrote:
>
> > See the sequence diagram depicting this at:
> > ftp://ftp.dfd.dlr.de/put/reck/VTL_MVC_seq_diagr.gif
>
> Yea. Yet another framework. Why are you re-inventing Turbine?
>
> -jon
I've not implemented a framework, just a simple design pattern.
I've taken some turbine ideas, simplified it a lot, and put
together a *very* simple way of doing it.
It is a simplistic but effective approach. It does not intend
to offer all that turbine allows (pluggable view engine, peers,
schedulers, action and screen java classes, etc). It profits
from the simplicity and completeness of VTL as a configuration
and control language, with some context tools to spice it up
(and assist the controller to create the pull model dynamically and
assist the view templates, e.g. I've extracted parts of turbines
DynamicURI and ParameterParser).
It is as simple as this:
init.vm loaded at servlet intialization, puts together
a (configurable) base context. For each request
this is chained to the next context layer, which
is discarded post-request.
request.vm does the application and action decoding, add some
application&request dependant stuff to the context
(the required common pre-processing of the app).
response.vm loads (parses) the response context generating
controller (if required by the app and not yet
done in the request.vm). Then renders the view
(or view/*) template as apropiate (decided in request.vm or
response.vm).
layout.vm puts it into a standard html-package and skin.
The used layout template can be changed to be another
one within request.vm or response.vm).
These all communicate via context variables.
In my new/current application I use the same sequence, but have the
request.vm template do the preprocessing and then the apropiate view
template is loaded immediately instead of the response.vm. Additionaly
I have other (controller) servlets which remotely use the TemplateServlet
to render their view using the common init/view/layout pattern.
This TemplateServlet is simple, configurable, embeddable, etc. It will
suffice for many users that do not need many features of turbine. And
its ready to use together with the velocity release.
Note that many frameworks are being designed elseware trying to be
simpler than JSP et.al.. Well, I've not designed a framework, just a
simple controller-controller (approx 300 lines of code) to make up
a very (re-)usable design pattern.
Jon, youre pushing many people to turbine. Yes they should look at
it, maybe they will need it becuase of some key features it provides.
But I'm providing a simple velocity usage form, wich will suffice for
>70% of people leaving JSP!
Think of it this way:
Apache-Jakarta -> for apache users
Tomcat -> for servlet users
Velocity -> for template users with simple MVC apps (view weighted)
Turbine -> for sophisticated MVC/DB/etc. apps
Jetspeed -> one such app
... -> users of Jetspeed
Struts -> another framework...
Avalon -> etc.
Slide -> ???
... -> other utils: Ant, Log, Regexp, Commons, etc.
(Geir, I will be contributing to the commons when I get some time to
sort the contracts of the code fragments out).
Apache-XML
crimson -> for simple XML apps
xerces -> for sophisticated XML apps
... -> usages of xerces (like cocoon)
Other non-Apache open-sources:
JDOM
Sourceforge
...
...
Isn't this a nice collaborating world?
:) Christoph
P.S. Turbine components are very interlinked with the turbine mechanics
itself, therefore they are difficult to reuse outside of turbine. I've
seen similar comments on the turbine list. So there are two solutions:
1. use turbine as a whole
2. re-negineer turbine 2.0 (far after a release) - similar to the way
velocity and torque can be used externally of turbine.
So currently #1 is the way to go for turbine functionality...
