[catagits/CatalystX-DynamicComponent.git] / TODO

TODO, or the plan for making this stuff work right.

The goals:

1/ I want to be able to specify a Controller base class, like
   Catalyst::Controller::MessageDriven. That's where my
   message-handling actually lives, so I want to build controllers
   based on that, or whichever other class.

2/ We need a calling convention for the model implementations - in the
   absence of defined interfaces this should be simple unblessed data,
   but if we do have an interface, we should be able to put proper
   constraints on it.

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. 

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
   (or the controller base class, probably) reject messages that
   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. 

6/ It'd be nice if exceptions from model methods were caught by the
   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
something to say what classes expose methods, which of those methods
are dispatchable, and which types are expected.

Possible Implementation

We can provide a number of controller base classes, for a number of
different message styles: YAML with type-tags, JSON bare hashes,
etc. These should be selectable by configuration, as a default
controller class plus overrides for specific controllers.

The calling convention to model methods should be the "payload". That
might be a bare hashref for simple messages, or a blessed object of
some app-specific type if the message format contains first-class
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. 

Types are implemented as type signatures on role methods, and we copy
them onto the actual methods on the model class at compile 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.
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
	17	which methods are dispatchable - "very public", if you like.
	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
	25	types of object those methods expect as a payload.
	26
	27	6/ It'd be nice if exceptions from model methods were caught by the
	28	framework and converted into messages representing the error -
	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
	37	We can provide a number of controller base classes, for a number of
	38	different message styles: YAML with type-tags, JSON bare hashes,
	39	etc. These should be selectable by configuration, as a default
	40	controller class plus overrides for specific controllers.
	41
	42	The calling convention to model methods should be the "payload". That
	43	might be a bare hashref for simple messages, or a blessed object of
	44	some app-specific type if the message format contains first-class
	45	objects, like tagged YAML.
	46
	47	The "interfaces" should be Roles, which don't provide any methods but
	48	which "need" methods to be implemented. We then use the "needed"
	49	methods as the set of dispatchable methods, given if we compile OK, we
	50	know that the model class has all the required methods.
	51
	52	Types are implemented as type signatures on role methods, and we copy
	53	them onto the actual methods on the model class at compile time.
	54
	55	Exception handling probably needs to be behaviour from the controller
	56	base class, so that it can be specific to the type of message
	57	serialization being used.