guys, i could use a little help sorting out some ideas on how to
implement the url mapping code that will be used to provide the new url
structure. i've got a couple of options i'm weighing and i'd like some
opinions.
The Setup:
So, we are definitely going to need some kind of mechanism for taking
the new weblog urls (/<weblog>/*) and mapping them to actual servlets to
do the work. The normal functionality will all be implemented and
maintained in the Roller codebase, but I'd like to make the process easy
to extend/customize so that users can modify the url structure a bit on
their own and still have a chance to make everything work.
My basic approach so far is to define a simple RequestMappingFilter
which consults a list of RequestMapper objects which each have a chance
to take a stab at handling the request. The list of RequestMappers will
be easily configurable so that users can plug in their own
implementations. Typically if a RequestMapper is going to handle a
request then it would simply dispatch the request to the servlet it
thinks should handle the request. Example ...
request /<weblog>/feed/rss
enter RequestMappingFilter
-- consult CustomRequestMapperXXX (no action)
-- consult WeblogRequestMapper (dispatch to /flavor/<weblog>/rss)
enter FlavorServlet
** request handled
exit FlavorServlet
exit RequestMappingFilter
response sent
Something of that nature. There have been a few ways users have wanted
to extend this, the big example being to provide blogger style urls like
... <weblog>.mydomain.com/*
The Problem/Issue:
My big question right now is about how best to define the RequestMapper
interface and how it should interact with the RequestMappingFilter and
the actual servlets which handle the requests. The root of the problem
is that we currently have our own parsing scheme (via RollerRequest)
which inspects the incoming HttpServletRequest object in our servlets
and extracts info about the request from the url. However, if users
customize the url scheme and a url is not in the right format then the
request cannot be properly parsed and handled.
Using the RequestMapperFilter it will be easy to properly dispatch
requests to any servlet, but the problem then becomes that when the
servlet tries to parse the non-standard url then it will fail. So there
needs to be a way such that customized urls can easily be passed into
our existing servlets with our own url parsing scheme and still be
usable. I have a couple thoughts on how that could work ...
1. Expect users to override the HttpServletRequest object and pass that
to the rendering servlets. So a user would write 2 pieces of code, 1) a
custom RequestMapper and 2) a custom HttpServletRequestWrapper. In
their RequestMapper they would wrap the original request with their own
wrapper and pass that along when they dispatch the request. The idea
being that in their custom HttpServletRequestWrapper they would override
the right methods to make their request look like a standard Roller
request. This means overriding methods like getRequestURL(),
getPathInfo(), etc.
2. Modify our rendering servlets to expect a WeblogRequest object which
is basically just a parsed HttpServletRequest. Our servlets would then
rely on this WeblogRequest object rather than directly on the
HttpServletRequest object when handling the request. Users making
customizations would then be responsible for 1) defining their custom
RequestMapper and 2) properly constructing a WeblogRequest object. So
in their RequestMapper they would inspect the request and create a
WeblogRequest object which would then be passed on to the rendering
servlets.
So the deal is that users who want to make custom extensions to the
Roller url scheme would have do something in their RequestMapper which
translates their custom url structure into the standard Roller url
structure. That can happen by either overriding the HttpServletRequest
object that gets sent to the rendering servlets, or by overriding some
kind of custom parsed request object similar to RollerRequest.
My feeling so far is that option #1 is a little easier and lightweight
on us developers, but invites more room for error if someone doesn't
properly override all the correct servlet request methods. Option #2 is
more controlled, but it requires more changes to our rendering
methodology and would probably require users to write more code.
So did I explain the problem reasonably well? Anyone have any thoughts
or ideas? Opinions on which option sounds better?
-- Allen
