Allen,
I have no knowledge of all the roller internals, but some years of
servlet development on my back. If what I say does not make sense in
the roller context, please feel free to completely ignore me:
Am 24.05.2006 um 21:55 schrieb Allen Gilliland:
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.
I have had experiences with approaches like this and must say it is
*quite* some work to correctly wrap a HttpServletRequest and it is
easy to make mistakes.
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.
I think this can be split into 2 different problems:
a) how to do the mapping
b) what do servlets get when dispatching requests (WeblogRequest vs.
HttpServletRequest)
If you model the RequestMapper to just return uri references instead
of *Request objects, the details of how this is interacting with the
servlets is transparent to the Mapper code. Something like:
public interface RequestMapper {
String map(HttpServletRequest request);
}
So, map could return null if it does not want to change anything or a
path relative to some webapp base where the request should be routed
to. (If you need more info about the path, you can make that it's own
class as well).
Independant of that you can chose the best option of how to forward
such filtered requests to the roller servlets.
Cheers, Stefan
