First,
If the TilesRequestProcessor were to be integrated into RequestProcessor,
and made to play nice when not using Tiles, that would at least remove one
obstacle when trying to extend the request processor. Since Tiles seems to
be a core struts component now, would that make since? Or should Tiles
still considered an extension?
Otherwise, if the TilesRequestProcessor was kept as a seperate class, and
you follow the composing model David spoke of, would it be desireable for
TilesRequestProcessor to implement this new interface, and then have a
RequestProcessor member? Or does it stay a subclass of the coreRP?
in tilesRP:
public processXXX() {
coreRP.processXXX();
}
public init() {
coreRP.init();
}
Second,
<snip>What is a RequestProcessor</snip>
public interface ActionServletRequestProcessor {//might one day want
ServletRP, ComposableRP or other including non Http processing?
void init(ActionServlet servlet,
ModuleConfig moduleConfig);
void process(HttpServletRequest request,
HttpServletResponse response);
void destroy();
}
Wouldn't that be it? Or am I missing something. It seems that if you are
going to the trouble of making this an interface, the only things you should
really care about is that you have lifecycle methods, and that you can
process a request and presumable provide a response. Everything else with
creating Actions, etc may not be desireable in all cases.
Maybe from there you create:
ActionFormRP
ActionRP
ActionMappingRP //or ActionConfigRP
ForwardConfigRP
I am with David that this starts to get very complicated. Maybe instead, a
RPHelper class could be created that has a bunch of static methods to handle
all the default processing rules. so:
public class RequestProcessor implements ActionServletRequestProcessor {
public void process(HttpServletRequest request, HttpServletResponse
response) {
request = RequestHandler.processMultipart(request);
...
RequestHandler.processLocale(request, response);
...
ActionMapping mapping = RequestHandler.processMapping(request, response,
path);
...
}
...
}
Thanks.
Gary Ashley
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
