Hello everybody, note that i have a deadline for this (March) so i'll be doing a PoC until then for sure - in case the proposal in refused. Some more (messy) ressources on cornershop.devangels.net, click "browse source", "trunk", "resources". The additionnal ressources include a discussion with laurentj, creator of Jelix, which is the most interresting.
Cheers, James. -- James Pic GPG Key : 13185F50x8 / AEE2 CC15 8FF8 339C 23AC 5A91 491B 1638 1318 5F58 Downloadable on http://jamespic.com/pubkey.asc
eZ Component: MvcTools, Requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:Author: James Pic
:Revision: $Revision$
:Date: $Date$
Introduction
============
Description
-----------
As of 2008, PHP6 is released and ezComponents provide PersistentObject and
Template. These components are efficient when used in the Model and the View
layers of an MVC application.
Users can develop their own implementation of the MVC layer separation or use
MvcTools.
Controllers made with MvcTools are very portable : they feature their
own Input and Output abstraction.
Using ConsoleTools and the MvcTools, it's possible for controllers to be run
from Console or through an HTTP request, but should not be limited to those
I/O protocols.
Note that this is extremely interresting for workflow controllers : more
interfaces for more actors.
Current Implementation
======================
The template component is an excellent tool for making the View layer.
The PersistentObject component is an excellent tool for making the Model layer.
The PersistentObjectDatabaseSchemaTiein generators should be able to generate
CRUD controllers, this is not implemented *as of now* but i'm working on that
with the
aggrement of Derick.
Requirements
============
- an MVC pattern viable with TDD/BDD,
- controllers with I/O abstraction,
- fully-featured MVC tools.
Design goals
============
The MVC pattern should be quiet simple but fully-featured unleashing the power
of PHP in making modern applications.
Routers
One router per-protocol, transforming the user-request into an abstract
request object. (ezcUrl is optionnal)
Request
The request object provides methods for the controller to check :
- user input arguments,
- user input data,
- user input cookie.
Controllers
Controllers have a static method returning their ezcConsoleInput with all
options, and a method to process the abstract request and return the
abstract output object.
OutputObjects
OutputObject is an interface that should be implemented by output object
classes, for example : a table, a dialog, a templateWrapper ...
Output
One Output-per-protocol. The Ouput should hold any number of OutputObjects,
taking care of their processing, rendering and sending response. The Output
should be selected by the router : the router should choose an asynchronous
Output object for classic HTTP requests and a live Output object for CLI
requests.
Special Considerations
======================
MvcTools should not supply deployment tools, another component should handle
this.
Diagrams
========
Example implementation
----------------------
First stage : router
>>>>>>>>>>>>>>>>>>>>
- The router generates a Request object abstracting the HTTP request or the CLI
command line.
- The router generates an Output object, depending on the request protocol.
- The router must select the controller object to use :
- If the current Request object against the requested controller's options
allows the controller to be run : return the controller.
- If the current Request cannot run the controller : return the controllerthat
will accept the provided Request - the controller that allows interfacing with
the requested controller (help-text/form ...).
Second stage : controller
>>>>>>>>>>>>>>>>>>>>>>>>>
ezComponents provide many tools to implement in a controller process.
The controller should process the Request object and generate an Output object,
with optionnal abstracted Output elements (datatable, input form, template).
It can write in the user's cookie (ie. ~/.cookie or HTTP COOKIE).
Each Output object should accept other Output objects as Output element :
allowing to use several sub-controllers per request.
In the case of the HTTP Output, it would allow pluging-in a "dynamic menu"
controller, the main Output should decide where to put it in it's view (new
variable $dynamicMenu in it's template for example).
Third stage : output
>>>>>>>>>>>>>>>>>>>>
Each Output class is independant and can render itself and is renderable as
another Output's "plug-in".
Example development diagram
---------------------------
Models, their tests, their CRUD controller and their tests are generated by
PersistentObjectDatabaseSchemaTiein, there should not be much work.
Develop controller's tests using the provided testRequestGenerator class
allowing to craft requests, and the testOutputAsserter. Making it confortable
to cover 100% of the code of the controller.
Optionnaly develop additionnal Output objects.
Developp a router implementation. Might be hard to test *as-is* but trivial
with a cool routing system implementing ezcUrl.
The development should be done in the Zazen posture, *by* monkeys *for*
code-monkeys.
..
Local Variables:
mode: rst
fill-column: 79
End:
vim: et syn=rst tw=79
pgpxGtn1aYtx5.pgp
Description: PGP signature
-- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
