Introduction and how it relates to Zym_App

First of all, this component is really needed. ZF lacks a standardized way of bootstrapping the application, and a component like this would both make it easier for newcomers to get into the bootstrapping process as well as allowing devs to move on to application specific coding right away. Combined with Zend_Tool, this component should hopefully allow newcomers to make the basic "Hello World!" MVC app in 5 minutes.

The proposal references Bill Karwin's Zend_Application from a while back. That proposal is currently refined and implemented as Zym_App, so a lot of functionality could be taken from that implementation. It has been revised in several iterations (found a couple of quirks and gotchas), and is currently in a fully functional and stable state.

Zym_App related links:

• The manual for Zym_App
• API documentation for Zym_App
• Demo application using Zym_App

Now, time for thoughts and feedback.

 What should the component do?

Mainly, the component should follow convention over configuration, and it should be possible to dispatch/run the bootstrap with decent configuration with a single line of code in index.php or bootstrap.php. Convention in bootstrapping means that by default, the component should use the default project structure (currently a proposal), and it should follow best practices regarding how other components are used and set up. Then, following the ZF spirit of use-at-will (and may I add use-however-you-like), the component should be flexible enough allow developers to set up virtually anything related to bootstrapping through configuration settings.

Bootstrapping becomes a somewhat heavy process which would have to be done for each request. This is leveraged by lazy loading and caching. Lazy loading is indeed supported inherently in most ZF classes, but caching is something users have to set up themselves. The bootstrap class should be self-cachable with no effort at all.

Resources / bootstrap modules

The way flexibility is added to Zym_App/Zend_Application is by letting the bootstrap class load arbitrary application resources. Resources are best described as "bootstrap modules", which is a means of providing moduarized bootstrapping. Example resources are; 1) Controller, 2) Cache, 3) View, and 4) Db, which would respectively set up; 1) classes in the Zend_Controller package (like Zend_Controller_Front), 2) classes related to caching, 3) Zend_View package (or any other view implementation you'd like), including helper paths, view helpers, etc, and 4) database connection(s) and Zend_Db setup.

Resources, or boostrap modules, have a predefined default configuration (this is where best practice should be followed), and allows users to override any of the settings by using config files. The responsibilities of "what resources should be loaded" and "which configuration file(s) should be loaded" are delegated to the bootstrap class, which reads a user defined configuration file, possibly also with a user defined "runtime environment" like development/testing/production, and dispatches the resources defined in the configuration file for the given environment. Each resource has its own responsibility, which makes it easy to see where and how the application is set up and dispatched.

The environment is a rather important aspect of the bootstrap process, because it allows different application setups for development, staging, production, testing, CLI, and so on. Say you want to disable caching when developing, but want full-blown page caching in production. Or for testing you might want to use a mock database in sqlite. Or you want a CLI interface to your application, in which case you don't want to use Zend_Controller_Front and Zend_View at all. Using different settings for different environments makes all of this trivial, and you don't lose control of where things are set up.

Relation to other components

The proposal for Zend_Container looks interesting, and could probably be used in Zend_Bootstrap/Zym_App. Also, the resource dispatching process could use some event handling features to allow arbitrary callbacks for certain events in the process. This should be implemented using Zend_Message. Currently, Zym_App does not utilize Zend_Loader_PluginLoader to load classes, but the bootstrap class should aggregate a plugin loader and allow user defined paths and prefixes to be added (for resources).

Conclusion (for now)

Bootstrapping deals with setting up arbitrary application resources. The component should be flexible enough to set up anything, and simple enough to bootstrap an application with a single line. Default configurations should follow best practices.

That's it for now, but I will follow this proposal with genuine interest and care.