Changes between Version 2 and Version 3 of TracDev/Proposals/ControllerApi
- Timestamp:
- Jun 22, 2006, 7:52:25 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/Proposals/ControllerApi
v2 v3 4 4 == Status Quo == 5 5 6 The current web layer in Trac is quite low-level. It builds directly on the component architecture, and requires a “controller” to implement the `IRequestHandler` 6 The current web layer in Trac is quite low-level. It builds directly on the component architecture, and requires a “controller” to implement the `IRequestHandler` interface and expose two methods: `match_request(req)` and `process_request(req)`. The former method is called by the request dispatcher to determine which controller should handle a particular request. The latter is then called on the controller that was chosen. 7 7 8 8 The following example defines a (heavily simplified) controller based on that API: … … 70 70 == Proposal: Controller Class == 71 71 72 This proposal extracts these common patterns from the individual controllers, and introduces a base class called `Controller` that allows for more convenient handling of requests. That class extends `Component` and implements the `IRequestHandler` 72 This proposal extracts these common patterns from the individual controllers, and introduces a base class called `Controller` that allows for more convenient handling of requests. That class extends `Component` and implements the `IRequestHandler` interface, so that a concrete controller can still directly extend other extension points, such as `INavigationContributor`. 73 73 74 74 When a controller is derived from the {{{Controller}}} base class, it should not need to implement `match_request()` or `process_request()`. Instead: … … 104 104 In addition, request parameters that the controller method declares as keyword arguments are automatically extracted from the request and passed as parameters (although always as string, so that sometimes the parameter value will still need to be casted). 105 105 106 One difference to the current code in Trac is that both `GET` and `POST` 106 One difference to the current code in Trac is that both `GET` and `POST` requests are handled by the same method. This will make it easier to implement user-friendly validation where a `POST` request with validity errors results in the form being redisplayed. 107 107 108 108 === Conventions and Convenience Features === … … 139 139 The code can be checked out from the [source:sandbox/controller] branch of the SubversionRepository. 140 140 141 Note that the branch currently requires Python 2.4 due to the use of decorators, but will be backported to 2.3 before/if it gets merged. 142 141 143 ---- 142 144 See also: [wiki:TracDev/Proposals], TracDev
