Skip to end of metadata
Go to start of metadata

Zend Framework: Zend_Application Component Proposal

Proposed Component Name Zend_Application
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Application
Proposers Ben Scholzen
Zend Liaison Matthew Weier O'Phinney
Revision 1.0 - 16 September 2008: Initial Draft.
1.1 - 30 September 2008: Renamed to Zend_Application.
1.1 - 30 November 2008: Continued work
1.2 - 19 March 2008: Updated to follow current incubator API (wiki revision: 14)

Table of Contents

1. Overview

Under Development
This component is under active development in the incubator. While we are making every effort to keep this document up-to-date, it may on occasion fall behind. When in doubt, look at the unit tests for usage examples.

Zend_Application is a component to simplify and normalise the entire bootstrapping procedure into an easy and extensible system. This proposal uses ideas from other proposals like Zend_Application, which was archived yet. It is intended to take care of the entire ZF enviroment setup like database, view, layout and controller.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component MUST be configuration driven. Configuration may take the form of any combination of the following
    • MUST allow programmatic configuration (i.e., via method calls)
    • MUST allow passing configuration to the constructor via an array, Zend_Config object, or path to configuration file
    • SHOULD allow passing configuration to one or more mutators via an array, Zend_Config object, or path to configuration file
  • This component MUST provide bootstrapping of the PHP environment (i.e., any ini_set-configurable keys)
    • This component MUST allow setting the application include_path (aka library)
    • This component MUST allow autoload initialization
      • It SHOULD allow specifying the alternate autoloading classes
    • PHP environment bootstrapping MUST occur at instantiation, prior to application bootstrapping
  • This component MUST allow specification of environments
    • Common default environments MUST be supported (development, testing, production)
  • This component MUST provide a plugin architecture for common application events/resources
    • This component MUST provide common resources
      • configuration
      • route setup
      • controller/module directory setup
      • view and layout setup
      • DB initialization
      • cache initialization
      • i18n setup
      • etc
    • This component MUST allow specification and utilization of arbitrary resources
    • Resources SHOULD
      • run independently
      • run in groups or all at once
      • allow for dependencies
      • use naming conventions for initialization
  • This component MUST account for initialization of independent modules
    • It SHOULD allow configuration of a standard bootstrap script location per module
    • Module bootstrapping MUST run independently
    • Module bootstrapping MUST be triggered by the application bootstrap

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Loader
  • Zend_Loader_Autoloader
  • Zend_Loader_Autoloader_Resource
  • Zend_Loader_PluginLoader

5. Theory of Operation

Getting an MVC application configured and ready to dispatch has required an increasing amount of code as more features become available: setting up the database, configuring your view and view helpers, configuring your layouts, registering plugins, registering action helpers, and more.

Additionally, you will often want to re-use the same code to bootstrap your tests, a cronjob, or a service script. While it's possible to simply include your bootstrap script, oftentimes there are initializations that are environment specific – you may not need the MVC for a cronjob, or just the DB layer for a service script.

Zend_Application aims to make this easier and to promote reuse by encapsulating bootstrapping into OOP paradigms.

Zend_Application is broken into three realms:

  • Zend_Application: loads the PHP environment, including include_paths and autoloading, and instantiates the requested bootstrap class
  • Zend_Application_Bootstrap: provides an interface for bootstrap classes; and a base bootstrap class, Zend_Application_Bootstrap_Base, that provides common functionality for most bootstrapping needs, including dependency checking algorithms and the ability to load bootstrap resources on demand.
  • Zend_Application_Resource provides an interface for standard bootstrapping resources that can be loaded on demand by a bootstrap instance as well as several standard resources to use with your applications.

Developers will create a bootstrap class for their application, extending Zend_Application_Bootstrap_Base or implementing minimally Zend_Application_Bootstrap_IBootstrap. The entry point (e.g., public/index.php) will load Zend_Application, and instantiate it by passing:

  • The current environment
  • Options for bootstrapping

Bootstrap options will include:

  • Optionally, any extra include_paths to set
  • Optionally, any additional autoloader namespaces to register
  • Optionally, any php.ini settings to initialize
  • Path to the file containing the bootstrap class
  • Optionally, the class name for the bootstrap class (if not "Bootstrap")
  • Optionally, resource prefix/path pairs to use
  • Optionally, any resources to use (by class name or short name)
  • Optionally, additional configuration options

Bootstrap options may be passed as an array, a Zend_Config object, or the path to a configuration file.

The Bootstrap class itself will typically be fairly minimal; often, it could consist of solely the following:

However, should custom initialization be necessary, the developer has two choices. First, they can write methods prefixed with "_init" to specify discrete code to bootstrap. These methods will be called by bootstrap(), and can also be called as if they were public methods: bootstrap<resource>().

Note in this example the call to "initFrontController"; this ensures that the front controller has been initialized prior to calling this method. That call may trigger either a resource or another method in the class.

The other option is to use bootstrap resources. Bootstrap resources are objects that perform specific initializations, and may be specified:

  • when instantiating the Zend_Application object
  • during initialization of the bootstrap object
  • by explicitly enabling them via method calls to the bootstrap object

Resources implement Zend_Application_Resource_IResource, which defines simply that they allow injection of the caller and options, and that they have an init() method. As an example, a custom "View" bootstrap resource might look like the following:

To tell the bootstrap to use this, you would need to provide either the class name of the resource, or a combination of a plugin loader prefix path and the short name of the resource (e.g, "view"):

Resources can call on other resources and initializers by accessing the parent object:

In normal usage, you would instantiate the application, bootstrap it, and run it:

For a custom script, you might need to simply initialize specific resources:

6. Milestones / Tasks

  • Milestone 1: [DONE] Requirement specifications
  • Milestone 2: [DONE] Creating working prototype
  • Milestone 3: [DONE] Unit tests exist
  • Milestone 4: Documentation exists

7. Class Index

  • Zend_Application
  • Zend_Application_Exception
  • Zend_Application_Bootstrap_Base
  • Zend_Application_Bootstrap_Exception
  • Zend_Application_Bootstrap_IBootstrap
  • Zend_Application_Bootstrap_IResourceBootstrap
  • Zend_Application_Module_Autoloader
  • Zend_Application_Module_Bootstrap
  • Zend_Application_Resource_IResource
  • Zend_Application_Resource_Base
  • Zend_Application_Resource_Exception
  • Zend_Application_Resource_Db
  • Zend_Application_Resource_Frontcontroller
  • Zend_Application_Resource_Layout
  • Zend_Application_Resource_Modules
  • Zend_Application_Resource_Session
  • Zend_Application_Resource_View

8. Use Cases

9. Class Skeletons

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

56 Comments

comments.show.hide

  1. Sep 30, 2008

    Robin Skoglund

    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:

    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.

  2. Dec 02, 2008

    Matthew Weier O'Phinney

    Current list of requirements

  3. Dec 25, 2008

    Hinikato Dubrai

    Please take a look here: Myak class. I wrote this class and you can use some ideas from it (if you want ).
    Can i help you with this proposal?

  4. Jan 27, 2009

    Robin Skoglund

    I absolutely love the idea behind this proposal - an OO approach to modularized bootstrapping - and I already use this in every project I have (using Zym_App, that is). However...

    There has been almost no discussion about Zend_Application since the idea was born. Well, at least not publicly available community discussion. If this component is due for the 1.8 release, we better get a serious discussion going right now. This is important, because as much as the component is useful, it is also complex. It has a lot of code, and introduces several concepts that may not be easy to grasp for newcomers, nor for people wanting to port their bootstrap to Zend_Application. Also, the component will be used at every request to the web server, which means two things: a) the API would have to be stable from the get go, and b) performance is an issue that needs to be addressed.

    I agree on all the requirements listed, but I'm struggling with the design. The problem is that I just don't fully understand it.

    Zend_Application is broken into three realms:

    • Zend_Application: loads the PHP environment, including include_paths and autoloading, and instantiates the requested bootstrap class
    • Zend_Application_Bootstrap: provides an interface for bootstrap classes. Zend_Application_Bootstrap_Base provides common functionality for most bootstrapping needs, including dependency checking algorithms and the ability to load bootstrap resources on demand.
    • Zend_Application_Bootstrap_Resource provides an interface for standard bootstrapping resources that can be loaded on demand by a bootstrap instance.

    A few things pop into my head:

    • What's the reeasoning behind this division?
    • Loading the PHP environment could/should be done in a resource, e.g. Zym_Application_Resource_Php, to make the API (and persistence of configuration settings) more consistent.
    • Could you elaborate on how the dependency checking algorithms work? Put in terms of an example; will the dependency checking solve the following problem: Both a Locale resource and a Translator resource are to be set up, but since the Translator has a soft dependency on the Locale resource, the Locale resource will be set up first?.

    Another one:

    However, should custom initialization be necessary, the developer has two choices. First, they can write methods prefixed with "_init" to specify discrete code to bootstrap. These methods will be called by bootstrap(), and can also be called as if they were public methods: init<resource>(). They should accept an optional array of options.

    I don't understand what this is about, but it seems like an awefully complicated/intricate way of customizing the bootstrap. Should those methods go in a Zend_Application_Bootstrap class? In that case, why would you do some initialization in resources, and some in the bootstrap class? In my opinion, all initialization should be done in resources. First of all, the resources should be generic enough so that you could customize the entire resource by giving it configuration settings. Secondly, if you have requirements that surpass the scope of a resource, say a DB resource, you extend the DB resource and add your features to it. Thirdly, if you need to initialize something that doesn't exist as a resource (e.g. a Doctrine resource), you simply write a resource class for it. I do not at all see the point of 'protected _init<Module>' and 'public init<Module>', nor the bootstrap class itself.

    Another point of interest is performance. As mentioned, this component is huge, and it is used on every request to the web server. How will the component use caching (preferably in-memory) to cache itself across requests? How should we deal with the catch 22 of setting up caching and using caching for the app instance itself?

    Conclusion: Simplify the API. Otherwise people will have a hard time using it, and fw-general will be spammed with silly and redundant questions.

    1. Jan 27, 2009

      Dolf Schimmel (Freeaqingme)

      I must say I basically agree with Robin on all his points.

      What I wonder; on IRC it was said that you (be it Ben, Wil or Matthew) had looked at Zym_App. Could either one of you three say what exactly you didn't like about Zym_App?

      1. Jan 27, 2009

        Matthew Weier O'Phinney

        I have looked at Zym_App, and there are many things I like about it – much of the resource design here was influenced by it. The few things I don't like include:

        • requirement of a configuration file. If no configuration or minimal configuration is required by the application, why require a configuration file?
        • requirement that configuration be in XML. Not everyone likes XML, and the evidence for this is the fact that Zend_Config supports multiple adapters (we're even looking at JSON and YAML adapters in future releases). Why require XML?
        • hardcoding of configuration keys. While it's nice to have a table of configuration options... wow, but Zym_App has a ton. I'd prefer to leave documentation of the available keys up to the individual resources and/or components they initialize.
        • the priorities system feels restrictive. If order matters, it makes more sense to provide a mechanism for enforcing dependencies. As demonstrated in the use cases, its possible to do so very simply.
        • no acknowledgement of modules as separate entities needing bootstrapping. A goal for the ZF MVC has been to better facilitate the conventional modular directory structure – basically to allow self-contained mini applications that can be dropped into your site. These potentially would require bootstrapping – initialization of plugins and helpers, etc.

        Zend_Application addresses each of these problems.

    2. Jan 27, 2009

      Matthew Weier O'Phinney

      I'm going to start by addressing one of your last statements first: "this component is huge." To that I have to ask: have you actually looked at any of the code linked in the proposal? All of it is very slim; the majority of the functionality is achieved in a few dozen lines of code.

      Now, the reasoning behind some of the decisions.

      • Regarding separating the PHP bootstrapping from application bootstrapping, the rationale is simple: your PHP environment will need to differ based on the desired application environment. For example, you may need a different PHP environment for testing than you would for development than you would for production. Additionally, you usually want your PHP environment completely initialized prior to beginning application configuration. Reasons include ensuring that the include_path is setup correctly, ensuring that error reporting is setup appropriately, ensuring the date settings are initialized, etc – all of which need to be in place prior to the components that depend on them being initialized. We may actually implement the PHP env initialization as a resource (this is still TBD) – but it will be performed prior to any other initialization.
      • Bootstrapping is where the actual application bootstrapping occurs. There will likely be bootstrapping for your default module, and bootstrapping for discrete modules in your application. This separation allows modules to be self-contained, as they contain their own bootstrapping (which might include setting up routes, resource loaders, etc).
      • Zend_Application then becomes a class that delegates to PHP initialization and application bootstraps, plural. This is why bootstrap classes are necessary – because there may be multiple bootstraps for a given application, particularly if it is built as a modular application. It's a compositional layer.
      • Regarding dependency checking, it's relatively simple: if a resource has a requirement on another resource, it attempts to initialize it. If the bootstrap has already initialized it, it returns early; otherwise, it performs the initialization. With this in place, you don't have to define an order in which resources are initialized, as they can ensure that all dependencies are performed first. In your example, if the Translator resource triggers first, it would attempt to initialize the Locale resource prior to its own work. When the Locale resource is later run, the bootstrap recognizes that it has already been run and moves on. The checking is not automated, however; the developer has to indicate in the resource method what dependencies the resource has.
      • What makes the dependency checking work is that all initializers must be run via a single public method (though we would allow virtual, direct access to each via method overloading – thus the difference between _init*() and init*() – the latter is achieved through method overloading); that method keeps track of whether or not the initializer has been run already.
      • Regarding the decision to have both _init*() methods and discrete resource classes, there are two primary considerations.
        • First is performance; having every initializer a resource means an object per initializer, which means stat calls and more memory and processing overhead. Since Zend_Application would trigger for every request, having a way to optimize it is a critical part of its design.
        • The second consideration is ease of use ; it will be easier for many developers to simply extend Zend_Application_Bootstrap_Base and add some _init*() methods than to tell them to write some classes. (The reason for having these methods protected is so they cannot be called directly, but must be proxied through the method decribed above when detailing dependency checking; it also ensures that there is a consistent API between method-based initializers and class-based initializers.) Not everyone is comfortable with writing plugin classes – as can be seen from the number of people with problems utilizing the various plugin classes in Zend_Form.
      • Regarding performance, one design decision – the ability to use methods instead of classes for resources – addresses part of this. Autoloading addresses part of this as well, and Zend_Application depends on the new Autoloader and resource loader implementations for this reason. However, since most of Zend_Application will be programmatic, the primary way to address performance is to use an opcode cache, and to cache the configuration passed to it in memory or as PHP arrays.

    3. Jan 27, 2009

      Matthew Weier O'Phinney

      One last note: I take issue with your initial statement: "There has been almost no discussion about Zend_Application since the idea was born. Well, at least not publicly available community discussion." If there hasn't been much discussion, it hasn't been for lack of Ben or I asking for input. When the original proposal went up, Ben asked on list at least once a week for feedback, and continually in the IRC channel. When I started gathering requirements, I also went to the lists and IRC. The fact of the matter is that we simply have not had many people respond to the proposal, the mailing list, or IRC. So, I'm very happy that you're raising questions now so that we will have some input.

  5. Jan 28, 2009

    Ralf Eggert

    I had a closer look at the Zend_Application proposal a couple of days ago and also got in contact with Ben to ask a couple of questions I had. To be honest I really like the flexibility of using either a Bootstrap class or the resources. If Zend_Application provides a good set of resources for the most commonly used initializations (database setup, controller setup, cache setup, you name it) it will be quite easy to start using it.

    The only problem I had was to get the difference between using a class or the ressources (with or without a config file) because it is mixed up a little in this proposal. So to minimize the beginners questions from the start these differences should be made really clear in the documentation for Zend_Application. A good, complete and easy to understand documentation will be the key to the acceptance of the component.

  6. Jan 28, 2009

    Laurent Melmoux

    Is there some prototype code to look at ?

    1. Jan 28, 2009

      Matthew Weier O'Phinney

      Yes, and I thought all of them were linked already. Oops!

      None of these incorporate all of the requirements in this proposal, however.

  7. Feb 05, 2009

    Geoffrey Tran

    Well this really isn't part of the discussion, but I just wanted to point a few things about zym_app that you mentioned.

    1. requirement of a configuration file. If no configuration or minimal configuration is required by the application, why require a configuration file?

    • Actually there's no requirement, everything can be configured with either a zend_config object or an array. Even through getters/setters themselves; however, for simplicity's sake there was not mention of the other possibilities. Uniformity was our goal.

    1. requirement that configuration be in XML. Not everyone likes XML, and the evidence for this is the fact that Zend_Config supports multiple adapters (we're even looking at JSON and YAML adapters in future releases). Why require XML?

    • This was never a requirement, as it accepts any format that zend_config can support. Once again though, the reasoning here was uniformity and that pushing an xml format by default would allow us to have schemas that could easily debug simple structure problems. Also a utility could easily be created to generate from schemas a dynamic form to select which options you wanted in a bootstrap.

    1. hardcoding of configuration keys. While it's nice to have a table of configuration options... wow, but Zym_App has a ton. I'd prefer to leave documentation of the available keys up to the individual resources and/or components they initialize.

    • I'm not sure what you mean here, but not every component accepts a Zend_Config/Array for setup in ZF. That's why there was some setter -> config key mapping in the resources.

    1. the priorities system feels restrictive. If order matters, it makes more sense to provide a mechanism for enforcing dependencies. As demonstrated in the use cases, its possible to do so very simply.

    • It was, but a few months ago, the component was branched and rewritten to use the pluginloader, dispatch events (through the use of it, we were able to cache the component itself using configuration from the cache resource without each knowing about the other... It probably was overkill though, but I had fun ) and replace the priority system with a dependency resolver.

    Anyways, I'm glad that development has been moving forward, even though I feel that this is also being rushed.

    "Zend_Application: loads the PHP environment, including include_paths and autoloading, and instantiates the requested bootstrap class"

    • Shouldn't this be the job of a resource/bootstrap class?

    1. no acknowledgement of modules as separate entities needing bootstrapping. A goal for the ZF MVC has been to better facilitate the conventional modular directory structure - basically to allow self-contained mini applications that can be dropped into your site. These potentially would require bootstrapping - initialization of plugins and helpers, etc.

    • Can you explain more of how this will be implemented? Will each module be bootstrapped during the dispatch process of the controller or at the application bootstrap? How will routes inside modules (of which I assume any self-contained module will have) be setup before the routing process if each module is lazy-bootstrapped.

  8. Feb 06, 2009

    Laurent Melmoux

    I really like the architect and the flexibility of the component. I have a couple of questions though :

    • About module bootstrapping : beside the advantage to setting up routes in each module, is initializing each module's bootstrap in _initModules() not too much overhead ?
      What about to load only one module's bootstrap at routeShutDown when the module name is known ? And use routeStartup only for setting up routes with some caching mechanism ?
    • Is there some advantages to use discrete resource classes instead of _init*() methods ?
    • The Pastbin App use a front controller plugin, but it doesn't look it is the same here ? I was wondering what are the advantages/disadvantages the front controller plugin brings ?

    1. Feb 06, 2009

      Robin Skoglund

      • About module bootstrapping : beside the advantage to setting up routes in each module, is initializing each module's bootstrap in _initModules() not too much overhead ?
        What about to load only one module's bootstrap at routeShutDown when the module name is known ? And use routeStartup only for setting up routes with some caching mechanism ?

      I have no idea how module bootstrapping should be implemented. Setting up module routes is mentioned as an advantage, but the problem is that you would need to know which module you should bootstrap, and you can't do that until the routes are set up (and the request arrives at the dispatcher), so it's a catch 22.

      • Is there some advantages to use discrete resource classes instead of _init*() methods ?

      Uniformity, flexibility, configurability. Personally, I find it easier to get an overview of the bootstrap process when using discrete resource classes. The only drawback is performance, but that is solved through caching.

      The Pastbin App use a front controller plugin, but it doesn't look it is the same here ? I was wondering what are the advantages/disadvantages the front controller plugin brings?

      The advantage of using a plugin is that plugins are well-known in the ZF world. People know what they are, how to use them, and can easily relate to a plugin. Disadvantages: When using a plugin, bootstrapping occurs too late in the dispatch process to set up routes (and other things related to Zend_Controller_*). Another disadvantage is that it bootstrapping in a plugin will not encompass configuring and dispatching of the front controller (you would still have to set up your front controller outside of the bootstrap plugin).

      1. Feb 06, 2009

        Laurent Melmoux

        Thanks Robin for you detailed answer.

        I have no idea how module bootstrapping should be implemented. Setting up module routes is mentioned as an advantage, but the problem is that you would need to know which module you should bootstrap, and you can't do that until the routes are set up (and the request arrives at the dispatcher), so it's a catch 22.

        Then it is probably best to set up module routes with a plugging and a cache than in the bootstrap...

        Disadvantages: When using a plugin, bootstrapping occurs too late in the dispatch process to set up routes

        the routeStartup() method is called before routing occurs, no ?

      2. Feb 06, 2009

        Matthew Weier O'Phinney

        Module bootstrapping will occur if and only if a module has a bootstrap class file present; otherwise, no bootstrapping will occur. Typically, you'll want to utilize it, as it will ensure at the minimum that there is an autoloader for the module's resource classes (models, forms, etc.). Module bootstrapping will occur during application bootstrapping to ensure resources such as routes are setup appropriately prior to dispatching the front controller.

    2. Feb 06, 2009

      Matthew Weier O'Phinney

      A module will be bootstrapped only if it has a bootstrap class file; otherwise, nothing will happen. There are several reasons to bootstrap a module: initializing module-specific plugins, adding module-specific routes (which need to be added prior to routing in order to be matched), registering module-specific action helper prefixes, and, of course, registering module autoloaders. Waiting to do this until after routeShutdown() will not work in the case of adding routes, and I'm loathe to have one mechanism for loading module-specific routes and another for bootstrapping the module.

      Regarding usage of discrete resource classes, the main goal here is re-use. You can define resources that may be common to sites you develop, and then re-use them across multiple applications easily if you can define them as discrete classes. This also allows you to mix-and-match resources needed for specific applications.

      Regarding the front controller plugin in the Pastebin app – take a look at the bugapp branch of that application, where I've now moved to a prototype of Zend_Application. I've used the plugin approach for some time as it's a familiar paradigm, and provides a class I can easily re-use for testing. Zend_Application will offer several benefits over the approach (module bootstrapping and configuration of the PHP environment, and initalization of autoloading).

  9. Feb 06, 2009

    Laurent Melmoux

    An other point related to bootstrapping what I would like to see, is how to lazyload some object instead of an initialization in the bootstrap + storage it in the registry.
    The logger is a good exampl: initLog()

    Unknown macro: {... Zend_Registry}

    1. Feb 06, 2009

      Matthew Weier O'Phinney

      Part of this will be handled by the module resource autoloaders, which will allow you to simply instantiate the class or call its static methods without needing to first require_once it:

      The resource autoloader implementation also allows it to act as an object registry, and will lazyload objects for you:

      I'm realizing now, however, that we need some mechanism for getting at the various module bootstrappers used so you can get to the individual resource loaders.

  10. Feb 06, 2009

    Laurent Melmoux

    Thanks Matthew for you detailed answers. I'm looking forward to this. I'll have a look at the bugapp branch.

  11. Feb 12, 2009

    Benjamin Eberlei

    I am totally missing a use case for webservices here. How can you setup an enviroment that does NOT use the Zend_Controller_Front and directly hits some light self-written dispatcher that distributes to Webservice Server Classes?

  12. Feb 12, 2009

    Dolf Schimmel (Freeaqingme)

    How can this proposal be set to ready for recommendation when there hasn't been added a single class skeleton? I think those should be added first, then give the community-members like 2-4 weeks the chance to give their opinion. And after that, set it to 'ready for recommendation'.

    1. Feb 12, 2009

      Matthew Weier O'Phinney

      Class skeletons are not necessary – but use cases showing the intended API – which are clearly presented here – are. It's not uncommon for the API to change dramatically during development in order to meet the proposal requirements, which leaves the class skeletons out-of-date, particularly with large components.

      By the way, the proposal has been marked ready for review for well over a month now...

      1. Feb 12, 2009

        Dolf Schimmel (Freeaqingme)

        I wonder how people can review a proposal if it isn't complete. The usecases don't say anything about the protected (or even private methods we've had in the past) or other undescribed methods that are going to be used, nor anything about their API's. This will make it impossible to fully review a proposal and have a legit opinion about it. When it comes to a vital component like this, I think that it can never be rushed, and should be worked out in detail, before a request for recommendation is even considered.

        1. Feb 12, 2009

          Matthew Weier O'Phinney

          The class skeletons should only ever show the public API; how things are handled internally is up to the developer. Those things are also reviewed prior to inclusion in trunk, and can be reviewed by interested developers during the course of development.

          The use cases do indicate how the component will be used, and we tried to show a variety of use cases to cover the full spectrum of the component. These specifically should be reviewed.

          I've also noted previously that there are three prototypes floating around (linked in a previous comment); you can review these to get an idea of the potential code structure, though the final version will combine strengths of each approach.

          There has been no rush to completion for this component. Ben proposed it immediately following ZendCon in September, and I helped him finish out the scope of the proposal in early December, and sent out requests for feedback at that time. Now almost two months have passed, with some feedback in comments above, a little feedback in the mailing lists, and some private feedback. It is time to move forward with the proposal.

          1. Feb 13, 2009

            Dolf Schimmel (Freeaqingme)

            Of course the non-public API is as important as the public API. People are expected to be able to extend components and add/change behaviour to them.

            "Those things are also reviewed prior to inclusion in trunk, and can be reviewed by interested developers during the course of development."
            Now I thought I knew the proposal process pretty well, but I guess I was wrong. I don't see anywhere in the process a point where a component needs to be reviewed /after/ it has been recommended by Zend. In other words: the proposal itself is meant to be reviewed (incl. it's full api), and not the code when it is included in trunk.

            What the rush is concerned, I do think that this component is being rushed. If it isn't, why not add class skeletons (the public AND nonpublic api) first, then have the proposal reviewed for 2 - 4 weeks, and only after that, have it recommended by Zend? Imho (and as far as I can tell the proposal process which we all agreed with states that) that is the way to go.

          2. Feb 18, 2009

            Vincent de Lau

            I think it is good idea to move forward with this proposal. A couple of weeks ago I was working on our bootstrapping process and found that Zend_Application could solve most of my issues. I've spoken with Ben about this on IRC, but there was no clear direction where to start.

            At this point in time, I am still in the position where I could work with lesser quality code and provide feedback and patches. I suppose the biggest problems in the design is regarding module bootstrapping, but that wouldn't be a problem for me.

            Will this component be built from scratch, or is one of the three being used as a starting point? Who is going to lead the development?

            1. Feb 18, 2009

              Matthew Weier O'Phinney

              Ben has begun work in a user branch – branches/user/dasprid/Zend_Application – and it builds on all three prototypes. I am assisting, and working on autoloader and module integration. You should see something usable that fulfills the requirements of the proposal within a week.

  13. Feb 24, 2009

    Cristian Bichis

    I am a bit confused on Use case:

    defined('APPLICATION_PATH')
    or define('APPLICATION_PATH', realpath(dirname(_FILE_) . '/../application'));

    Is index.php supposed to be into root and application path root/application ?

    Because if i am not wrong path should be then dirname(_FILE_) . '/application'

    Or index.php is supposed to reside into public ?

    1. Feb 24, 2009

      Matthew Weier O'Phinney

      index.php is inside the public/ directory – it's the entry script to your application.

  14. Feb 24, 2009

    Cristian Bichis

    One more comment.

    Due to integration of AutoLoader is supposed to be slightly changed the Zend Framework Default Project Structure also ? For adding things as Forms, DbTable, aso....

    I am referring to this:

    http://framework.zend.com/wiki/display/ZFPROP/Zend+Framework+Default+Project+Structure+-+Wil+Sinclair

    1. Feb 24, 2009

      Matthew Weier O'Phinney

      Please see the dependencies list. Zend_Loader_Autoloader provides namespaced library autoloading, and Zend_Loader_Autoloader_Resource provides the ability to autoload namespaced resources from a common directory that do not have a 1:1 mapping of class name to filename. A specialized version of the resource autoloader, Zend_Application_Module_Autoloader, has also been created and provides resource mappings for all items listed in the default project structure. All of these classes are currently in the incubator.

      Zend_Application leverages these classes in several ways. First, Zend_Application itself sets up autoloading as part of its initialization. Second, a "Module" resource will be provided that, by default, creates a Zend_Application_Module_Autoloader instance for each module in your application.

      1. Feb 24, 2009

        Cristian Bichis

        I know this great updates. Just pointed that will be useful once component is released to update the Default Project Structure with the "default" values used on Autoloader.

        1. Feb 24, 2009

          Matthew Weier O'Phinney

          The module autoloader is mirroring the recommendations in the default project structure already.

          1. Feb 24, 2009

            Cristian Bichis

            With some updates as for forms...

            1. Feb 24, 2009

              Matthew Weier O'Phinney

              The default project structure already accommodates forms: application/forms/ or, when using modules, <modulename>/forms/.

              1. Feb 24, 2009

                Cristian Bichis

                Oh, ok, thanks.

                Was not into displayed structure so that's why i mentioned this. I saw now a comment related to this "We haven't decided on a location for forms in the directory hierarchy yet. My prediction would be in application/forms/, and prefix them with 'Form_'; in modules, they'd then be prefixed with '<Module>Form'.". Good to know...

                <project name>/
                application/ (dir layout here can be duplicated under modules/ minus bootstrap.php)
                apis/
                config/
                controllers/
                helpers/
                layouts/
                filters/
                helpers/
                scripts/
                models/
                modules/
                views/
                filters/
                helpers/
                scripts/
                bootstrap.php
                data/
                cache/
                indexes/
                locales/
                logs/
                sessions/
                uploads/
                docs/
                library/
                public/
                css/
                js/
                images/
                .htaccess
                index.php
                scripts/
                jobs/
                build/
                temp/
                tests/

  15. Mar 03, 2009

    Keith Pope

    Hi,

    I have successfully got Zend_Application and the autoloader working now I must say it works very well the module bootstrapping is brilliant.

    The only feedback on the api I have is when creating the bootstrap class, the control over the order in which the init methods execute is a little confusing. I found in my bootstrap methods I was needing to call the other "dependent" methods a lot, E.g. $this->bootstrapFrontController(); maybe there is a better way to handle the order from within a bootstrap, maybe adding an optional getStack() method or similar? Though I assume this is easily solved also by using resources instead as they would be FIFO ordered?

    Other than that it seems a very clean way to bootstrap an application, I look forward to seeing the final product. With the final release of this it would also be interesting to see how the process fits into using Zend_Test.

    Good work

    1. Mar 03, 2009

      Cristian Bichis

      Let's suppose you gonna have:

      public function _initFrontController()
      and
      protected function _initView()

      And you want to be sure _initFrontController runs before of _initView.

      For be sure about this you place at first line of _initView this:

      $this->bootstrapFrontController();

      So, for genealization:

      bootstrap<initmethod>

    2. Mar 03, 2009

      Matthew Weier O'Phinney

      Actually, order should not be important – which is why dependency tracking is available. Dependency tracking ensures that if your particular initializer needs to run after another one, then it can force that other initializer to run before it does its own work.

      So, all told, what you're doing is precisely the design we're attempting to achieve – having each initializer indicate which dependencies it has, and only then running its own code. This simplifies the logic within Zend_Application/_Bootstrap tremendously, and leaves it in the most flexible state it can be in.

  16. Mar 03, 2009

    Steve Wilhelm

    It may be out of the scope of the Zend_Application, but I make my request here for lack of a better forum.

    I now built a couple projects using the Zend framework. Beyond libraries and modules, I have had difficulty finding examples for building and maintaining several applications from one shared code base.

    I would like to see a use case for Zend_Application where two complete applications are defined where some bootstrap, controller, view, model, library, cron-base operations, and test code is shared, but the underlying databases, log files, and acl roles differ and are configured via application specific configuration files.

    Examples of shared code would be user login and registration behavior, user feedback code, a basic admin dashboard, and cron-based database backup or metrics calculation and reporting.

    I would really like to see an example of how this configuration would then be deployed as two applications on two separate target environments.

    Look forward to seeing how this component progresses.

  17. Mar 03, 2009

    Steve Wilhelm

    When doing a Google search for Zend_Application, the now obsolete 2006 proposal by Bill Karwin is the first result.

    Adding insult to injury, there is no indication that the 2006 proposal is obsolete except way at the bottom in the final comment that states "Proposal Rejected." It would be helpful if the obsolete proposal contained a link to the this currently active proposal.

    The Zend Framework group may want to investigate Google Webmaster Toolkit. I have found it quite helpful in improving content accessibility in Google search results (and by using sitemaps, improving accessibility in Yahoo and Microsoft's search results as well).

    1. Mar 03, 2009

      Matthew Weier O'Phinney

      Thank you for your feedback – I've slapped a big notice and link to this proposal on Bill's rejected proposal.

      While Google Webmaster Toolkit may give us some pointers, the fact of the matter is that this is a wiki, and wiki's don't play terribly well with SEO.

  18. Mar 03, 2009

    Cristian Bichis

    Bug report/improvement to add:

    Zend_Application_Module_Autoloader can't work with autoloading layout plugins (put into plugins folder), apparently due to fact that for loading this plugins is used Zend_Loader.

    Zend_Loader::loadClass($pluginClass); //line 268 of Zend/Layout.php

    1. Mar 03, 2009

      Matthew Weier O'Phinney

      Once the autoloader is moved to trunk, we plan on refactoring calls to Zend_Loader throughout the framework; until then, we need to keep the current solution intact.

      1. Mar 03, 2009

        Cristian Bichis

        Nice.

  19. Mar 04, 2009

    Cristian Bichis

    Some nice features also to add:

    • automate loading and running module bootstrapping (currently this is done by getting all modules paths, checking for bootstrap, aso)
    • automate resource autoloading for all modules (currently same: getting all modules, setting for them the resources to auto-load)

    1. Mar 05, 2009

      Matthew Weier O'Phinney

      This is already planned, and the basic implementation is in place in the most current prototype.

  20. Mar 09, 2009

    Matthew Weier O'Phinney

    Zend Acceptance
    This proposal is accepted for immediate development in the standard incubator. The following considerations are raised:
    • Dependency tracking should detect and prevent circular dependencies
    • Raise the naming of interfaces and abstract classes with the community and the greater PHP community. Currently, we have IBootstrap and IResourceBootstrap interfaces, and a Base abstract class; do we want to proceed with these conventions, or adopt others? What conventions will other projects such as PEAR2 be adopting?
    • Should an application-level registry implementation be considered? This would not require much change to the current prototypes, but the current prototype is offering a different philosophy than is currently espoused in the Quick Start: it offers dependency injection instead of a registry-based approach. DI offers better testability, while registry-based approaches are often slightly simpler to code (though introduce uncertainty about dependencies).

  21. Mar 12, 2009

    Pádraic Brady

    A few of us were seeking a clarification on the Dependency Injection aspect of the proposal (not to ignore bootstrapping itself - which I like). There some talk/perception that Zend_Application would offer full DI (in the traditional sense of Java/Ruby applicable globally) but it's not actually highlighted anywhere in that fashion in the proposal, descriptions or use cases I've seen - rather it's tied to applying DI to bootstrapping primarily which is my current understanding.

    1. Mar 12, 2009

      Matthew Weier O'Phinney

      Correct – the DI aspect of this proposal is tied to bootstrapping only, and provides DI for the various resources initialized during bootstrap.

      Theoretically, one could push the bootstrap object into the front controller, and thus provide access to all resources to the various MVC components – in other words, the bootstrap object would act as the DI container. However, this is a detail I'm still working on – right now it's all convention driven, and I'm thinking a more formal solution may be in order.

  22. Mar 18, 2009

    Rob Terzi

    Bootstrapping Zend_Application / Environment Specific Settings.

    In order to bootstrap Zend_Application, four pieces of environment dependent configuration are required to be in place before using Z_A.

    1. The intended version of the Zend Framework must already be in the include_path
    2. The application path must already be in the include_path. (APPLICATION_PATH in UC-01,02)
    3. The environment name / selector that can be used for determining which group of Zend_Config settings will be used, must be passed to Z_A. (APPLICATION_ENV in UC-01,02)
    4. Configuration for Zend_Application in the form of an array or the path to a file to be read by Zend_Config. This can contain, as per the spec, bootstrapping information such as path and php settings. Technically this is optional, in practice this is most likely required. However since this is passed into Z_A's constructor you need to have already determined what to pass in before Z_A can provide any help.

    There will always be chicken & egg bootstrapping issues, so being realistic, some configuration needs to be done first. I wanted to check my understanding.

    Thanks.

  23. Mar 20, 2009

    Rob Allen

    There's a lot of top-level config keys required in the INI file. So far I've got:

    phpsettings
    includepaths
    autoloadernamespaces
    bootstrap
    resources
    pluginpaths

    So far...

    Can we put all these under "application." ? Though that may make the keys too long?

    Rob...

  24. Mar 25, 2009

    Cristian Bichis

    Couple of settings may be useful to be set through Zend_Application, i would name few:
    1. View: doctype

    2. Db: SET NAMES

  25. Mar 28, 2009

    Cristian Bichis

    Modules Bootstrap doesn't seems to work with current SVN version...

    A very simple module bootstrap is freezing browser window and on server (either windows/linux, on windows is restarting apache !) no error is reported (i didn't debugged, just checked into logs)...

    Working with module bootstrap some time ago was np.

    class Catalog_Bootstrap extends Zend_Application_Module_Bootstrap
    {
    public function _initModule()
    {

    }

    public function run(){}

    }

  26. Apr 07, 2009

    Marc-Antoine Emond

    @Cristian Bichis

    It is possible to "SET NAMES" in the db params like this:

    resources.db.params.driver_options.1002 = "SET NAMES UTF8;"