Stefan Eissing wrote:
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.
This echoes Dave's thoughts as well as my own. I don't think it's
exactly hard, but it's certainly proned to errors if you don't know what
you're doing and it would be very hard to debug.
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)
yes, that is a good way to break it down.
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).
I considered that option and it's definitely a valid approach. The main
reason why I didn't move forward with it is that it seems somewhat
desirable to let a RequestMapper handle the response as well. That way
you can force certain return codes when there is a mapping error, rather
than being at the mercy of the RequestMappingFilter.
It's definitely a cleaner approach, which is what I like about it.
Independant of that you can chose the best option of how to forward such
filtered requests to the roller servlets.
Cheers, Stefan
