David M Johnson wrote:
On May 11, 2006, at 6:37 PM, Allen Gilliland wrote:
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.
Maybe this is a stupid question, but if we can't use an web/MVC
framework to route our virtual URLs and we don't need form field
processing, what is the value-add of using an web/MVC framework for the
page/feed rendering?
Nope, that's not stupid at all, in fact I think that is exactly the
right question to ask.
This discussion initially began from Sean's proposal to use SpringMVC as
the implementation for the new url structure. The reality is that we do
*not* need to use any framework to achieve an implementation of the new
url structure. There is nothing preventing us from using some kind of
custom url mapping filter (like url rewrite) along with our current
velocity servlets just as we do now.
That being said, I think the idea of reorganizing and refactoring some
of the weblog rendering code is probably a good idea at this time. I am
already going to have to make some noticeable hacks to that process as
part of the new urls implementation so it makes sense to evaluate how
best to do that. There are really only 2 *non-required* things that I
would like to achieve while doing the new urls implementation ...
1. Allow for view independence in the rendering process. This basically
means supporting a templating system other than Velocity. Note that I
am not saying that Roller should provide any alternative templating
implementations (like new themes, macros,etc), but the option to easily
allow a Roller admin to use an alternative makes a whole lot of sense.
The key scenerio being that if someone is deciding to start a new Roller
based blog site from Roller 3.x code base then they get a Velocity
templating implementation for free *or* they could decide they want to
use FreeMarker or something else and have the ability to plug that in.
I don't think it is too much work to make this happen and it's a feature
that probably few (or none?) other blog systems provide.
2. I would like to unify some related parts of the rendering process and
make them more cohesive. Namely, I would like to abandon the use of
filters for caching and instead build that functionality into the
rendering servlets themselves.
There is no reason why we can't do this with the code we have today and
I think it makes more sense because the current implementation spreads
out pieces that really belong together. It's much easier to view the
PageServlet and see exactly how it deals with 304 responses, cached
content, and rendering, all in one place. At the end of the day I think
that caching is part of the rendering process and should be more closely
coupled with the rendering servlets.
The additional problem of the way we do caching filters right now is
that it is hard (and hacky) to properly handle cases where there are
exceptions/errors in the rendering process. We have a hacked way of
setting a request attribute (DisplayException) with the exception and
hoping that any downstream filters do the right thing, and i think we
can do better than that.
So that is *why* i am investigating these frameworks. Mainly to see if
they would useful in providing the view independence and/or url mapping.
To be totally honest, at the current moment I am leaning towards not
using a framework for this stuff and instead sticking with pure Servlets
and a little bit of custom code.
-- Allen
- Dave
