Commit | Line | Data |
ff05b07e |
1 | TODO, or the plan for making this stuff work right. |
2 | |
3 | The goals: |
4 | |
5 | 1/ I want to be able to specify a Controller base class, like |
6 | Catalyst::Controller::MessageDriven. That's where my |
7 | message-handling actually lives, so I want to build controllers |
8 | based on that, or whichever other class. |
9 | |
10 | 2/ We need a calling convention for the model implementations - in the |
11 | absence of defined interfaces this should be simple unblessed data, |
12 | but if we do have an interface, we should be able to put proper |
13 | constraints on it. |
14 | |
15 | 3/ Given generated controllers where I expose a bunch of methods from |
16 | the actual model classes, there needs to be some way to control |
56f4c9af |
17 | which methods are dispatchable - "very public", if you like. |
ff05b07e |
18 | |
19 | 4/ I'd like to be able to write down an "interface", consisting of a |
20 | set of messages my app is willing to handle, and have the framework |
21 | (or the controller base class, probably) reject messages that |
22 | aren't in that set. |
23 | |
24 | 5/ I'd also like to be able to say in that interface definition what |
56f4c9af |
25 | types of object those methods expect as a payload. |
ff05b07e |
26 | |
27 | 6/ It'd be nice if exceptions from model methods were caught by the |
56f4c9af |
28 | framework and converted into messages representing the error - |
ff05b07e |
29 | i.e. to set an error status, and return the text of the exception. |
30 | |
31 | All these things should be based on configuration. So, we've got |
32 | something to say what classes expose methods, which of those methods |
33 | are dispatchable, and which types are expected. |
34 | |
35 | Possible Implementation |
36 | |
56f4c9af |
37 | We can provide a number of controller base roles, for a number of |
ff05b07e |
38 | different message styles: YAML with type-tags, JSON bare hashes, |
56f4c9af |
39 | etc. |
40 | |
41 | We can also provide a number of controller base roles, for a number of |
42 | policies for what model methods get reflected / are dispatchable etc.. |
43 | |
44 | These should be selectable by configuration, the default |
ff05b07e |
45 | controller class plus overrides for specific controllers. |
46 | |
47 | The calling convention to model methods should be the "payload". That |
48 | might be a bare hashref for simple messages, or a blessed object of |
49 | some app-specific type if the message format contains first-class |
50 | objects, like tagged YAML. |
51 | |
52 | The "interfaces" should be Roles, which don't provide any methods but |
53 | which "need" methods to be implemented. We then use the "needed" |
54 | methods as the set of dispatchable methods, given if we compile OK, we |
56f4c9af |
55 | know that the model class has all the required methods. |
56 | *** Do we require that the model class in question has already composed |
57 | the appropriate role, and just check that by introspection or do we just |
58 | add it ourselves? Adding it ourselves involves making an anon subclass |
59 | to avoid action at a distance, so the former if possibly preferable? |
ff05b07e |
60 | |
61 | Types are implemented as type signatures on role methods, and we copy |
56f4c9af |
62 | them onto the actual methods on the model class at compile time. |
63 | **** I'm thinking this happens at role composition time.. |
ff05b07e |
64 | |
65 | Exception handling probably needs to be behaviour from the controller |
66 | base class, so that it can be specific to the type of message |
67 | serialization being used. |
56f4c9af |
68 | |