<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: ZFApp Component Proposal

Table of Contents

1. Overview

ZFApp 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 is in fact an application itself, and new applications are created using ZFApp by effectively "Copying" ZFApp into a new application directory and running a configuration script to set application-specific variables.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

• Zend Framework .15
• Smarty 2.6.14
• PHP 5.1

4. Dependencies on Other Framework Components

• Zend
• Zend_Controller_Action
• Zend_Controller_Dispatcher
• Zend_Controller_Dispatcher_Token
• Zend_Filter_Input
• Zend_Controller_Front

5. Theory of Operation

The ZFApp 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 is designed to lead the developer using sound architectual principals.

The ZFApp 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/ 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 to be upgraded as new versions of ZFApp 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 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, it is only included so a new application has a nice "face" when a new application is generated.

Upon downloading ZFApp, you will find that it is as much an application template as it is a framework. In fact, the only difference between ZFApp and an application generated by ZFApp (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 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 will also look to simply render foo/bar.tpl prior to throwing a no-route condition
• Beautified Error handling: ZFApp 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 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 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 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)

6. Milestones / Tasks

7. Class Index

• ZFApp_Controller_Front
• ZFApp_Controller_Renderer
• ZFApp_Controller_Dispatcher
• ZFApp_Controller_Front_Plugin
• ZFApp_Controller_Action_Base
• ZFApp_Controller_Action_List
• ZFApp_Controller_Action_Private
• ZFApp
• ZFApp_DB
• ZFApp_View
• ZFApp_View_Engine
• ZFApp_View_Plugin_Render (function, not class)
• ZFApp_Filter_Input
• ZFApp_Error_Handler

And a relationship diagram...

8. Use Cases

9. Class Skeletons

See the Working ZFApp preview release http://private.coggeshall.org/ZFApp-preview-release-1.tar.gz/