Add some thoughts / notes to TODO
Tomas Doran (t0m) [Sun, 24 May 2009 17:22:18 +0000 (18:22 +0100)]
TODO

diff --git a/TODO b/TODO
index bea95e4..8685610 100644 (file)
--- a/TODO
+++ b/TODO
@@ -14,7 +14,7 @@ The goals:
 
 3/ Given generated controllers where I expose a bunch of methods from
    the actual model classes, there needs to be some way to control
-   which methods are dispatchable - "very public", if you like. 
+   which methods are dispatchable - "very public", if you like.
 
 4/ I'd like to be able to write down an "interface", consisting of a
    set of messages my app is willing to handle, and have the framework
@@ -22,10 +22,10 @@ The goals:
    aren't in that set.
 
 5/ I'd also like to be able to say in that interface definition what
-   types of object those methods expect as a payload. 
+   types of object those methods expect as a payload.
 
 6/ It'd be nice if exceptions from model methods were caught by the
-   framework and converted into messages representing the error - 
+   framework and converted into messages representing the error -
    i.e. to set an error status, and return the text of the exception.
 
 All these things should be based on configuration. So, we've got
@@ -34,9 +34,14 @@ are dispatchable, and which types are expected.
 
 Possible Implementation
 
-We can provide a number of controller base classes, for a number of
+We can provide a number of controller base roles, for a number of
 different message styles: YAML with type-tags, JSON bare hashes,
-etc. These should be selectable by configuration, as a default
+etc.
+
+We can also provide a number of controller base roles, for a number of
+policies for what model methods get reflected / are dispatchable etc..
+
+These should be selectable by configuration, the default
 controller class plus overrides for specific controllers.
 
 The calling convention to model methods should be the "payload". That
@@ -47,11 +52,17 @@ objects, like tagged YAML.
 The "interfaces" should be Roles, which don't provide any methods but
 which "need" methods to be implemented. We then use the "needed"
 methods as the set of dispatchable methods, given if we compile OK, we
-know that the model class has all the required methods. 
+know that the model class has all the required methods.
+*** Do we require that the model class in question has already composed
+the appropriate role, and just check that by introspection or do we just
+add it ourselves? Adding it ourselves involves making an anon subclass
+to avoid action at a distance, so the former if possibly preferable?
 
 Types are implemented as type signatures on role methods, and we copy
-them onto the actual methods on the model class at compile time. 
+them onto the actual methods on the model class at compile time.
+**** I'm thinking this happens at role composition time..
 
 Exception handling probably needs to be behaviour from the controller
 base class, so that it can be specific to the type of message
 serialization being used.
+