VcRefactoring/Controller

Note: this was an experimental branch, now retired.

Following-up on the ​refactoring started by Peter Dimov, there's an opportunity to revive the TracDev/Proposals/ControllerApi effort.

The 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.

Currently done:

• automatic dispatching to specific methods of the RequestProcessor subclass, based on the action parameter. 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.xhr is set to True in the latter case).
• default_template, default_content_type properties can be set at the RequestProcessor subclass level, so that only the data dictionary needs to be returned by a handler
• default_stylesheets, default_javascripts properties can be set at the RequestProcessor subclass level, for 'text/css' stylesheets and 'text/javascript' scripts that will always be associated to the responses.
• move the matching logic at the level of the RequestProcessor itself (add a RequestProcessor.match class method and a url_pattern class property, see r5081)
• reintroduced a Controller mixin, which takes care of instantiating a request_processor if the req.path_info matches
• found a better name for the call_<action> methods for handling XHRs: xhr_<action> (r5154)
• r5154 enables the action handler method to easily specify the request arguments they need to use, much like the original controller branch did

TODO

• experiment with presentation objects

---

See also: VcRefactoring, source:sandbox/vc-refactoring@3836