Application Topography and Configuration

At this point, the reader should be familiar with elementary Zend Framework "hello world" applications that have a bootstrap script routing flow of control to a front controller, and an action controller with a single action method that uses a single view template to produce a basic "hello world" web page.

Demo Features

The forum demo application in this tutorial features a classic approach to forum / bulletin board systems without most of the extras. Since the demo emphasizes clarity of purpose and clarity in its use of ZF components, it does not contain some obvious performance tweaks and features. Instead, the demo features:

1. support for anonymous sessions
2. support for authenticated sessions mapping the user to an authorization identifier
3. access control for authorized users
4. modular "MVC" layout, where the forum system could be combined with other "modules"
5. table/row patterns with a MySQL backend
6. automatic localization of dates, times, places
7. translation of phrases within the interface
8. attachment of images via retrieval using HTTP and local hosting of the images
9. logging of important events
10. emails for watched topics
11. searching of posts
12. topic to feed gateway
13. performance tweaks using caching

Bootstrap

Not surprisingly, the bootstrap looks similar to the example in the previous section, except for the introduction of controller modules, using the Conventional Modular Layout. Modules represent logical collections of related controllers that are designed to work together, yet mostly independent from other modules. Thus, controllers from a module generally exhibit much tighter coupling than between controllers in different modules.

Now we can define the bootstrap in terms of modules. The bootstrap provides the skeletal structure controlling and regulating the flow of execution and interoperation between modules. Core ZF library components automate most of the bootstrap process, leaving an application "skeleton" for the developer to create. Since the ZF design objectives emphasize flexibility, there are many design decisions left to the developer in the bootstrap. Different choices suit different practices and different styles and different solutions.

The ZFDemo aims to highlight some possible design decisions both in the bootstrap and modules. This goal leads to a reusable application skeleton, although you will likely find some "pruning" required, and areas to tweak to suit your specific needs.

Registry

The ZFDemo relies heavily on a simple design pattern called simply "registry". In the ZF, the Registry acts more like an iterable hash table than anything else. Since elements can be accessed with or without a local reference, it is also capable of replacing the need for global variables with something more structured (and capable of throwing an exception when unknown keys are referenced). If you need something more restrictive, such as a registry that only accepts objects and refuses delete and overwrite of keys, then the Zend_Registry could be subclassed in your application.

Configuration and Initialization

In the ZFDemo, all configuration files are centralized to a shared subdirectory, "config", within each version of the ZFDemo. Each section of the manual has a corresponding version of the ZFDemo containing a full copy of the source code, including all additions made in prior sections of the tutorial. Thus, changes to a single configuration file must be replicated to all later versions of the ZFDemo for the later sections, in order to have effect when using this other versions.

Although modules can act as prototypical "mini" applications, complete with their own configuration file, the ZFDemo adheres to the perspective of developers integrating these modules into a final application by unifying the module configuration files into a complete whole. Thus, there is only one "config/modules.ini" for the ZFDemo. This also allows for an inheritance hierarchy to exist between the configuration sections of modules using Zend_Config.

Unlike the modules' configuration, "config/config.ini" uses a different inheritance hierarchy based on the deployment platform, where sections in the ".ini" are related by the server environment, such as "default -> production server" and "default -> developement server".

Conventional Modular Application Layout

For this demo, we use the ZF recommended layout following a Conventional Modular Layout pattern, and the ZF coding standard. The file layout of this demo follows a common and popular approach to keep files logically organized, with only the bootstrap script located under the web server's document root directory for security reasons. In this style, models, views, and controllers for a specific application module (e.g. the forum module) are grouped into logical "packages" in the form of directories.

The key application-specific directories include:

/home/you
/home/you/zfdemo - zfdemo source files, including data files
/home/you/www - web document root
/home/you/www/zfdemo/index.php - zfdemo bootstrap script

In total, the Conventional Modular Layout typically includes the following subdirectories, although the exact names might vary. Also, some systems place severe restrictions on which directories PHP can write into, which affects the location of the "data" (i.e. tmp/) directory below.

/home/you/zfdemo

    /library                # PHP's include path should list this directory
        /Zend               # http://framework.zend.com/download
        /<other PHP libraries>

    /section5_asession # one of the many copies of the ZFDemo application

        bootstrap.php  # ZFDemo bootstrap (i.e "main")

        index.php  # hollow shell to include "bootstrap.php" (must be *copied* to your web root)

        /config    # configuration files
            config.ini       # primary ZFDemo application configuration file
            zfdemo.sql       # initial SQL code to create tables for ZFDemo application
            Zend_Session.ini # configuration information for Zend_Session component

        /data      # persistent data files
            zfdemo.log       # log of "interesting" events (verbose)

        /lib       # contains subclassed "overloads" of Zend Framework components

        /temporary # private application data files
            /sessions        # zfdemo PHP session data files
            /cache           # zfdemo cached application data
            /view_compiles   # pre-compiled templates/views

        /default   # the default module, used when none given or available from the request/URL
            /config (optional as needed)
            /controllers
                /Admin       # controllers responsible for administrating the entire site
                /UserAdmin   # controllers responsible for administrating a user's account
                ErrorController.php  # class ErrorController extends ZFDemo_Controller_Action \{...\}
                IndexController.php  # class IndexController extends ZFDemo_Controller_Action \{...\}
            /models
            /views
                /filters
                /helpers
                /scripts
    
        /forum     # module named "forum"
            /config (optional as needed)
            /controllers
                /Admin      # controllers responsible for administrating the forum module and data
                IndexController.php  # class Forum_IndexController  extends ZFDemo_Controller_Action \{...\}
                TopicsController.php # class Forum_TopicsController extends ZFDemo_Controller_Action \{...\}
            /models
            /views
                /filters
                /helpers
                /scripts
    
        /<module 2>
            /controllers
            /models
            /views
                /filters
                /helpers
                /scripts
          .
          .
    
        /<module n>
            /controllers
            /models
            /views
                /filters
                /helpers
                /scripts

    /home/you/www/zfdemo    # /home/you/public_html/zfdemo is also a very popular location
        /images
        /scripts
        /styles
        index.php           # copied from 

Advantages

1. Allows for packaging of non-interrelated application components (think "plugin" architecture for a web site with a forum, news, quote-of-the-day, and weather modules).
2. With the exception of user created library code, all application related code associated with the domain model, controllers and views are in one specific location: /home/you/zfdemo
3. Works smoothly with other libraries installed in a global location shared by other applications (like PEAR).
4. Emphasizes code containment, thus creating a wider directory structure at the top-most level.
   1. Application directory in this layout means 'the code responsible for the direct duties of carrying out application specific actions'.
   2. The library directory in this layout includes libraries of code that carry out a specific and common pattern of duties, usually not related to the specifics of an application, but related to the carrying out of common patterns of tasks.
   3. An application-specific data or temporary directory aids the application in its duties, but normally requires the use of a filesystem (possibly tmpfs or RAM-based) to create temporary files like session files, cache files, or view compiles.
5. The popularity of this layout reduces the learning curve for those already familiar with it, including the learning curve of those who are providing support to others.
6. By grouping administration "business logic" into subdirectories in relevant controller directories, security becomes slightly easier to enforce. Logically related administration controllers grouped into a common directory simplify application of authorization controls. A certain type or level of authorization can be applied universally to these directories (each group of controllers), in order to prevent unauthorized access to administration functions. Reducing the complexity of logic and code required to achieve security reduces the risk of bugs exposing security flaws. Separating controllers requiring extra security and grouping them into shared directories may also help developers maintain and manage the most security-sensitive portions of an application.
7. Administration controllers are distributed across each module, resulting in greater encapsulation of module-specific code, including both domain models (/models directory) and presentation models (data in ZF's Zend_View objects).

Disadvantages

1. The wider top level of directories and resulting duplication of subdirectories to group models, views, and controllers by purpose (i.e. module) results in a proliferation of directories and files.
2. Deployment to production systems not directly supporting this layout poses configuration and deployment issues, including more complex routes and more points requiring security measures. For example, unrelated physical directory paths coinciding with logical routes may collide, if the application directory is merged into the web server's document root directory. Regardless, most security experts do not recommend locating the application source code directly under the document root directory.
3. If an application needs to use a locally modified version of a library in "/library", but continue using the other libraries in "/library" as-is, then complications arise. For example, PHP's include path does not provide a way to have "/home/you/FooLib" and "/library" both in the include path, yet exclude the copy of "FooLib" found in "/library/FooLib". The danger results from accidental inclusion of the wrong files from the original library.
4. Additional complexity results if "/admin/<module>/<controller>/<action>" should be routed to "/<module>/admin_<controller>/<action>". The latter form is needed by the ZF Controller system to access the controller in "/home/you/zfdemo/forum/controllers/Admin/<action>Controller.php".
5. Administration controllers are distributed across each module, resulting in more directories and a lack of encapsulation of administration features within a common area.

Next Section: 4. MVC - Models, Views, Controllers