Don Brown wrote:
Allen Gilliland wrote:
i believe that Spring appears to be the more ideal solution for the
Content Delivery component because it is a bit less intrusive, very
lightweight, would require minimal code modifications to integrate,
and it's whole claim to fame is basically it's model and view
independence. i think this is the right combination of features for
use in the Content Delivery component.
If you do go this way, please feed back any specific enhancements Struts
Action 2 could make to be "less intrusive", more "lightweight", and
better "model and view independence". I haven't used Spring MVC
personally, but I'm eager to incorporate any improvements they have.
Don,
I'm still doing some prototyping for both Spring and WebWork
implementations of what I want to do and I certainly wouldn't mind a
little guidance on the WebWork side if you have the time. I think the
best thing would be for me to describe the problem a little bit and hear
how you might solve it in WebWork.
Right now Roller uses about 6 different Servlets to serve up all of the
user generated weblog content and currently we are using pure Velocity
via the VelocityServlet. Basically the process is ...
1. request comes in
2. validate request and parse out some data we want
3. load up velocity context based on the needs of the request
4. lookup template used to render the view
5. render template output to response
6. return response
All of that happens in each of these servlets and is tailored towards
the specific type of content being served up for the request.
*The Problem*
I would like to do just enough work to get some view independence in the
process described above so that instead of assuming Velocity for
everything we can provide an option to use various view technologies.
In this case we are only concerned with templating technologies like
Velocity, FreeMarker, etc, so we would never use jsps for example.
The additional task is that our new url structure is very virtualized
and will require some kind of Filter that can inspect incoming requests,
figure out if they are a virtual url, and dispatch them if needed. So
far, none of the canned url mapping tools from any framework appears to
provide enough flexibility to do what we need, so I am currently
assuming that part will have to be custom.
It's also important to note that our real goal here is simplicity,
control, and speed. The content we are rendering is entirely dynamic,
so we need to be flexible. We aren't doing anything fancy here either,
no form processing, chaining, etc, basically just lookup the data,
render it, return it. This part of Roller represents about 95% of the
applications usage, so we want it to be as simple and streamlined as
possible yet allow us enough control to hack it however is needed for
optimization.
*The Spring Approach*
I call Spring "lightweight" because 1) it has minimal dependencies in
the form of jars, configs, etc and 2) because the code it uses is not
very intrusive. By intrusive I mean it doesn't try and do things for
you or ask you to tailor much of your code in the Spring pattern, and it
doesn't make many assumptions about how you should (or want to) use the
framework.
So, in Spring our VelocityServlets would become Spring Controllers and
those controllers can function exactly as they do now, except that they
would use a generic Map instead of a VelocityContext object for loading
the model. Then instead of doing steps 4 & 5 in the Controller they
will dispatch to a View object instead.
This requires fairly minimal effort because we simply rename a few
things to turn the servlets into Controllers, and the effort to use a
Map instead of a VelocityContext is a good thing no matter what
framework we choose. We also have simple and flexible view independence
because we can simply have the controllers return any variation of View
that we want.
I don't know the full details of how the url mapping will get flushed
out. So far it still looks like we'll need some kind of custom filter
to at least to the first part of the mapping and get requests forwarded
to the appropriate servlet destination.
*The WebWork Approach*
Maybe you could offer an overview of how you might do it?
-- Allen
Thanks,
Don
