Edgewall Software

Version 2 (modified by Christian Boos, 17 years ago) ( diff )

Update information about the branch, at r5087

VcRefactoring/Controller

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.

Work in progress

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)
  • reintroduced a Controller mixin, which takes care of instantiating a request_processor if the req.path_info matches

TODO

  • find a better name for the call_<action> methods for handling XHRs (the default XHR handler is named call_view which doesn't look good)

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

Note: See TracWiki for help on using the wiki.