Author: jpic
Date: Thu Feb 14 14:57:26 2008
New Revision: 7374
Log:
Details about I/O objects and the controller interface
Modified:
experimental/MvcTools/design/design.txt
Modified: experimental/MvcTools/design/design.txt
==============================================================================
--- experimental/MvcTools/design/design.txt [iso-8859-1] (original)
+++ experimental/MvcTools/design/design.txt [iso-8859-1] Thu Feb 14 14:57:26
2008
@@ -64,11 +64,21 @@
This object encapsulates the client-request, abstracting the request
protocol.
+It's important to separate the object's properties from the request variables
+in the class facade.
+This class implements Iterator, ArrayAccess and Countable for request-values,
+and public properties will be used for the object's variables.
+
ezcMvcOutput
------------
This object encapsulates the controller result, abstracting the response
protocol.
+
+It's important to separate the object's properties from the request variables
+in the class facade.
+This class implements Iterator, ArrayAccess and Countable for request-values,
+and public properties will be used for the object's variables.
ezcMvcRouter
------------
@@ -88,6 +98,18 @@
This interface has to be implemented by classes that handle rendering one
ezcMvcOutput object into one formated (part of the) response string.
+
+ezcMvcController
+----------------
+
+This interface should be implemented by user's controllers.
+Assuming that action-selection should be done within the controller itself :
+it should have one public method : run( $input, [ $output = null ] ).
+
+The controller should be able to use the passed output-object instead of
+creating a new one.
+Using an existing output-object might require that the output-object implement
+controller-level namespacing : this should not be supported.
Possible system conceptions
===========================
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
