[Phrame-devel] Please read: MVC input sought

[Tony B. <to...@to...>]

Folks,

I had the pleasure to pour through the Phrame code in painstaking detail 
trying to see how refactoring it might proceed.  As I spent more and 
more time I found things in Phrame that simply didn't make sense to me. 
  In the end, I took some of my wants and needs along with the good 
ideas from Phrame and did a ground-up MVC implementation.  I hope this 
doesn't appear to be a slap in the face to anyone on this list and that 
a keen eye is given to my implementation for the differences.  I look at 
what I have as a combination the good things in Phrame with a number of 
  changes to reduce the payload and complexity.

Ok, now for the notable differences:

1) config files has some basic configuration:
- $configData[_DIRS][_MVC_BASE]: This is the location of the MVC codebase
- $configData[_DIRS][_VIEWS]: Directory where views can be found
- $configData[_DIRS][_MODELS]: Directory where models can be found
- $configData[_BASE_URL]: The base URL related to the controller
- $configData[_DEFAULT_SECURITY_POLICY]: Set default policy for objects

2) I have worked security into this MVC implementation.  Security checks 
are still up to the developer to implement but the default policy will 
be used to determine the default security policy.  If set to _TRUSTED, 
the default policy is to allow access to anyone.  If set to _UNTRUSTED, 
all models/views will have security checks enabled by default.

3) A big problem with Phrame is it will load a lot of unneeded code to 
process a request.  Specifically, all the actions in phrame are loaded. 
  By using the path config information for the views/models, you can 
dynamically include the right code on demand.

4) Use of session data was completely removed. The main justification is 
not all applications will use PHP4 sessions and even then, jamming stuff 
into the session that isn't user specific is a waste of server resources 
  IMHO.

5) Forwards come in two basic types, 1) redirects, 2) model/view 
forwards.  As the first implies, URL redirects is supported and working. 
  However, often it is desireable to forward processing off to a 
different model or view managed by the current controller.  With that 
said, you can now forward processing on to another model or view 
requiring no URL redirect.

6) Refactoring, I mentioned this a few times.  I saw a need for a model 
and view factory.  Both have been implemented.  Additionally, I added a 
LoaderFactory class.  The loader factory allows for any number of 
configuration sources without requiring changes to the core code.  I 
added this after hearing thoughts on supporting XML config files.  My 
implementation will require the configuration data, regardless of 
format, to be converted into a PHP array.  Right now I have an 
ArrayLoader which is working but adding an XMLLoader is trivial at this 
point.

7) the Phrame Mappings and Forwards classes have been dropped.  Forwards 
are simply implemented as an array.  When a request is received, only 
the forwards for the model or view is loaded.  Similarly, only the 
mapping information for the current request is loaded.

8) Documentation, though not a big deal, PHPDoc comments are included 
and I will be publishing this documentation along with the code when I 
get a chance.

9) Many applications output views differently. Some echo or print the 
HTML directly to the browser, others build the HTML in a string and at 
the end echo that single string.  The view implementation is a 
configuration setting that lets you specify which behaviour is supported 
and the controller will act accordingly.

At this point I am not releasing the code until I have implemented a 
fairly 'real world' example using this implementation and generated the 
PHPDoc documentation.  I anticipate having this available to this list 
sometime in the next day or so.

-- 
+-------------------+--------------------------------------------------+
|Tony Bibbs         |[R]egardless of what you may think of our penal   |
|to...@to... |system, the fact is that every man in jail is one |
|                   |less potential fisherman to clutter up your       |
|                   |favorite pool or pond. --Ed Zern                  | 

+-------------------+--------------------------------------------------+