1 Controllers |
1 Controllers |
2 ----------- |
2 ----------- |
3 |
3 |
4 XXX the view controller, other controllers |
4 Overview |
|
5 ++++++++ |
|
6 |
|
7 Controllers are responsible for taking action upon user requests |
|
8 (loosely following the terminology of the MVC meta pattern). |
|
9 |
|
10 The following controllers are provided out-of-the box in CubicWeb. We |
|
11 list them by category. |
|
12 |
|
13 Browsing: |
|
14 |
|
15 * the View controller (web/views/basecontrollers.py) is associated |
|
16 with most browsing actions within a CubicWeb application: it always |
|
17 instantiates a `main template` and lets the ResultSet/Views dispatch |
|
18 system build up the whole content; it handles ObjectNotFound and |
|
19 NoSelectableObject errors that may bubble up to its entry point, in |
|
20 an end-user-friendly way (but other programming errors will slip |
|
21 through) |
|
22 |
|
23 * the JSon controller (web/views/basecontrollers.py) provides services |
|
24 for Ajax calls, typically using JSON as a serialization format for |
|
25 input, and sometimes using either JSON or XML for output; |
|
26 |
|
27 * the Login/Logout controllers (web/views/basecontrollers.py) make |
|
28 effective user login or logout requests |
|
29 |
|
30 Edition: |
|
31 |
|
32 * the Edit controller (web/views/editcontroller.py) handles CRUD |
|
33 operations in response to a form being submitted; it works in close |
|
34 association with the Forms, to which it delegates some of the work |
|
35 |
|
36 * the Form validator controller (web/views/basecontrollers.py) |
|
37 provides form validation from Ajax context, using the Edit |
|
38 controller, to implement the classic form handling loop (user edits, |
|
39 hits 'submit/apply', validation occurs server-side by way of the |
|
40 Form validator controller, and the UI is decorated with failure |
|
41 information, either global or per-field , until it is valid) |
|
42 |
|
43 Other: |
|
44 |
|
45 * the SendMail controller (web/views/basecontrollers.py) is reponsible |
|
46 for outgoing email notifications |
|
47 |
|
48 * the MailBugReport controller (web/views/basecontrollers.py) allows |
|
49 to quickly have a `repotbug` feature in one's application |
|
50 |
|
51 Registration |
|
52 ++++++++++++ |
|
53 |
|
54 All controllers (should) live in the 'controllers' namespace within |
|
55 the global registry. |
|
56 |
|
57 API |
|
58 +++ |
|
59 |
|
60 Most API details should be resolved by source code inspection, as the |
|
61 various controllers have differing goals. |
|
62 |
|
63 `web/controller.py` contains the top-level abstract Controller class and |
|
64 its (NotImplemented) entry point `publish(rset=None)` method. |
|
65 |
|
66 A handful of helpers are also provided there: |
|
67 |
|
68 * process_rql builds a result set from an rql query typically issued |
|
69 from the browser (and available through _cw.form['rql']) |
|
70 |
|
71 * validate_cache will force cache validation handling with respect to |
|
72 the HTTP Cache directives (that were typically originally issued |
|
73 from a previous server -> client response); concrete Controller |
|
74 implementations dealing with HTTP (thus, for instance, not the |
|
75 SendMail controller) may very well call this in their publication |
|
76 process. |
|
77 |
|
78 |
|
79 |