Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History
New Proposal Template
This page has been created from a template that uses "zones." To proceed:
  1. Edit the page
  2. Replace sample content within each zone-data tag with your own content
  3. Remove this notice
  4. Save the page
  5. When you are ready for community review, move this page to the Ready for Review section on the edit page.
No placeholders allowed!
Please do not create placeholders. Wait until you have sufficient content to replace all sample data in the proposal template before creating your proposal document.

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

Zend Framework: Zend_Container Component Proposal

Proposed Component Name Zend_Container
Developer Notes
Proposers Bradley Holt
Zend Liaison TBD
Revision 1.0 - 28 July 2008: Initial Draft. (wiki revision: 14)

Table of Contents

1. Overview

Zend_Container is a simple dependency injection container that is intended to replace use of Zend_Registry and class-based singletons. This is a proposal for a simpler dependency injection component than Zend_Di and Zend_Context. Note that the word "component" is overloaded in this proposal. This proposal is for a Zend Framework "component" but it also uses the word "component" to refer to an object managed by Zend_Container.

The author of this component is not entirely sure that a dependency injection component is inline with Zend Framework's balance of power and simplicity. However, the author believes that if Zend Framework is to have a dependency injection component that this component should be as simple as possible and designed to solve a limited set of use cases.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will replace Zend_Registry.
  • This component will use reflection.
  • This component will not allow more than one instance of a given type to be registered in a given container.
  • This component will not act as a factory (except for creating the single instance of a given type).
  • This component will allow manual component registration or configuration-based component registration.
  • This component will allow a hierarchy of containers.
  • This component will allow a container to have zero or one parent container.
  • This component will allow a container to have zero or more child containers.
  • This component will allow a child container to access components in its parent container.
  • This component will not allow a parent container to access components in its child container(s).

4. Dependencies on Other Framework Components

  • Zend_Reflection
  • Zend_Loader
  • Zend_Config (optional)
  • Zend_Exception

5. Theory of Operation

Zend_Container provides a simple dependency injection container in which components may be registered. A component may be registered under its own type or one of its parent types (class or interface). Only one component of a given type may be registered in a given container. This means that two objects of the same type may be registered in the same container if they are registered under different parent types. This also means that two objects of different types may not be registered in the same container if an attempt is made to register them under the same parent type.

Components can be registered manually using calls to the addComponent method or through configuration. Registering components through configuration simply calls the appropriate addComponent methods for you based on the contents of your configuration object. Dependencies to be injected are detected using reflection on added components.

A hierarchy of containers can be created by assigning a parent container upon instantiating a new container. When attempting to get a component of a given type a container will first look in itself and then its parent container (if applicable). The parent container will recurse to its parent container until the component is found or there are no more parent containers. This means that if a component of the same type is registered in a child and a parent container, the component in the child container will be used.

6. Milestones / Tasks

  • Milestone 1: Write proposal
  • Milestone 2: Design interface
  • Milestone 3: Use cases
  • Milestone 3: Gather feedback and incorporate design changes
  • Milestone 4: Approval of Zend_Reflection
  • Milestone 5: Review by the Zend Team
  • Milestone 6: Write unit tests
  • Milestone 7: Develop full implementation
  • Milestone 8: Write API doc
  • Milestone 9: Documentation

7. Class Index

  • Zend_Container
  • Zend_Container_Components
  • Zend_Container_Exception
  • Zend_Container_Types

8. Use Cases

UC-01: Manually wiring dependencies

The above code is the equivalent of (assuming setter injection):

UC-02: A container with a parent container

9. Class Skeletons


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