RequestProcessor class encapsulates all the logic for processing one specific request.
It was therefore natural to extend it with the response helpers and the dispatching logic that was previously attached to the proposed Controller class. As that class was a Component mixin, it was not convenient to keep Request related state at that level.
- automatic dispatching to specific methods of the
RequestProcessorsubclass, based on the
actionparameter. Those methods are named
do_<action>for a POST request,
render_<action>for a GET request and
call_<action>for an XML Http Request (also,
self.xhris set to
Truein the latter case).
default_content_typeproperties can be set at the
RequestProcessorsubclass level, so that only the data dictionary needs to be returned by a handler
- move the matching logic at the level of the
RequestProcessoritself (add a
RequestProcessor.matchclass method and a
url_patternclass property, see r5081)
- reintroduced a
Controllermixin, which takes care of instantiating a
- found a better name for the
call_<action>methods for handling XHRs:
- r5154 enables the action handler method to easily specify the request arguments they need to use, much like the original controller branch did
- experiment with presentation objects