Version 11 by Gavin
on Sep 20, 2006 16:37.

compared with
Current by Darby Felton
on Sep 21, 2006 16:17.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (33)

View Page History
<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{zone-template-instance:ZFDEV:Zend Proposal Zone Template}

ZFApp Primitus

ZFApp Primitus is an application framework built on top of Zend Framework to ease the rapid development of new applications built on top of ZF. It extends the foundation provided by ZF's MVC model to implement a number of ease-of-use features. As a framework designed specifically for new development it's goal is to provide structure to using the Framework in an intelligent fashion, and makes efforts to ensure applications developed with the Framework are done in the most intelligent way possible. It borrows some stylistic and feature abilities from other application frameworks without the overbearing natures many impose. ZFApp Primitus is in fact an application itself, and new applications are created using ZFApp Primitus by effectively "Copying" ZFApp Primitus into a new application directory and running a configuration script to set application-specific variables.

The ZFApp Primitus Framework functions on two key principals:
* Completely self-contained (bundles necessary components)
* Standardized filesystem structure

These principals, combined with the power of Zend Framework, allow developers to quickly build powerful applications without spending signficant time on the repetitious tasks involved in any application. Even many architectual requirements can be avoided, since ZFApp Primitus is designed to lead the developer using sound architectual principals.

The ZFApp Primitus directory structure is as follows:


As it makes sense, all code which a normal developer should never have to touch has been placed into the ZFApp/ Primitus/ library directory. This has both the benefit of a clear separation between user code and library code, but also makes it possible for applications build on top of ZFApp Primitus to be upgraded as new versions of ZFApp Primitus are developed. Only a few special directories are required in the application-space:

* include/controllers/ApplicationController.php: A global controller, all public controllers should extend from this controller
* include/views/_main: Views in this directory are referenced directly from within the ZFApp Primitus library and serve a special purpose such as error message handling, no-route conditions, and the main template
* include/views/index: Not really required by ZFApp, Primitus, it is only included so a new application has a nice "face" when a new application is generated.

Upon downloading ZFApp, Primitus, you will find that it is as much an application template as it is a framework. In fact, the only difference between ZFApp Primitus and an application generated by ZFApp Primitus (at least before development begins) is that constants relied on by the framework have been correctly set. These constants are determined at application generation by the appgen.php script included with the framework. These constants may eventually be removed all-together in lieu of a relative-referenced path system.

For reference, the dispatch flow which produces controller-less views is as follows:

Upon creating a new ZFApp Primitus Application, you will notice a number of features provided by the framework:

* Controller-less views: Views are organized in the include/views directory as controllername/action.tpl. If the router determines it should execute the "Foo" controller's "Bar" action and no such controller exists, ZFApp Primitus will also look to simply render foo/bar.tpl prior to throwing a no-route condition
* Beautified Error handling: ZFApp Primitus catches all uncaught exceptions and uses the opportunity to display the user with a clean, customizable, error page describing the error, where it occurred, and the backtrace for faster development. In a production environment, this functionality can be replaced with a more user-friendly error
* Improved Control-chain introspection: ZFapp Primitus keeps track of which controllers (or controller-less views) ocurred, useful for tracing complex control chains
* Complete separation of Controller from View: Views are rendered piece-wise by using the "render" view function. This function comes with a default implementation which will simply display the controllername/action.tpl template, however can be completely overridden to display other types of data or custom views as needed
* Improved Filtering: ZFApp Primitus re-implements Zend Framework's Input Filter to allow better access to the data, including allowing it to filter a single variable (instead of an array).
* Scoped View Variables: Unless explicitally specified, variables assigned in a controller action are scoped specifically to that action's view template and will not clash with other templates.
* Convience in data access: ZFApp Primitus controllers all implement a robust base controller which provides access to the controller's scoped view, the database, and filtered references to all user-input points (GET, POST, COOKIE, etc)


* ZFApp_Controller_Front Primitus_Controller_Front
* ZFApp_Controller_Renderer Primitus_Controller_Renderer
* ZFApp_Controller_Dispatcher Primitus_Controller_Dispatcher
* ZFApp_Controller_Front_Plugin Primitus_Controller_Front_Plugin
* ZFApp_Controller_Action_Base Primitus_Controller_Action_Base
* ZFApp_Controller_Action_List Primitus_Controller_Action_List
* ZFApp_Controller_Action_Private Primitus_Controller_Action_Private
* ZFApp Primitus
* ZFApp_DB Primitus_DB
* ZFApp_View Primitus_View
* ZFApp_View_Engine Primitus_View_Engine
* ZFApp_View_Plugin_Render Primitus_View_Plugin_Render (function, not class)
* ZFApp_Filter_Input Primitus_Filter_Input
* ZFApp_Error_Handler Primitus_Error_Handler

And a relationship diagram...

See the Working ZFApp Primitus preview release []