Skip to end of metadata
Go to start of metadata

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

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

Zend Framework: Zend_Factory_Abstract Component Proposal

Proposed Component Name Zend_Factory_Abstract
Developer Notes
Proposers Mickael Perraud
Matthew Weier O'Phinney (Zend Liaison)
Revision 0.1 - 17 March 2008: Initial proposal creation.
0.2 - 20 March 2008: Corrections and comments.
0.3 - 24 September 2008 : Corrections (wiki revision: 13)

Table of Contents

1. Overview

Zend_Factory_Abstract helps to create components by centralizing the code of creation which can apply to several components

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component must not break backward compatibility
  • This component will create new element

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Loader

5. Theory of Operation

When I began to write the code proposed in Zend_Image_Barcode, I looked Zend_Db and Zend_Form:

  • Zend_Db for factory() method
  • Zend_Form for __construct(), setOptions() and setConfig() methods.

And I saw that I entirely copied the code of Zend_Db factory() method with just strings changements.
So I propose to extract this code into Zend_Factory_Abstract and that the Zend_Db class and other components extend Zend_Factory_Abstract.

This proposal is just an extraction of the code of factory method of Zend_Db to be able to use for other components.

6. Milestones / Tasks

  • Milestone 1: design notes will be published here
  • Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
  • Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
  • Milestone 4: Unit tests exist, work, and are checked into SVN.
  • Milestone 5: Initial documentation exists.

7. Class Index

  • Zend_Factory

8. Use Cases

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Mar 18, 2008

    <p>This seems to me like another proposal to solve the inversion of control problem. Did you took a look at Zend_Di?</p>

    1. Mar 20, 2008

      <p>I didn't look Zend_Di before and I'm not familiar with this pattern but I think my proposal approaches this <a href="">comment</a>.</p>

  2. Sep 24, 2008

    <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[There is a major bug in the Zend_Factory::_factory method:

    if ($element instanceof Zend_Config) {
    if (isset($adapter->params))

    Unknown macro: { $config = $element->params->toArray(); }

    $adapter does not exist there. Also this is using Zend_Db configuration "params" and "adapter" naming. This has to be refactored into Zend_Db::factory before calling _factory.

    Plus in the Use Case for Zend_Db you still have a $barcode variable.

    Although i like the approach, i dont think it can be done. Almost every component using a Factory method has a different implementation, than the other. Have a look at Zend_Cache factory for example.]]></ac:plain-text-body></ac:macro>

    1. Sep 24, 2008

      <p>This is an old proposal. I created this when I began to write my Zend_Image_Barcode but I didn't use it so there is effectively some bugs. I make corrections but my initial goal is not to use "as is" but to discuss.</p>

  3. Oct 13, 2008

    <p>You seem to be combining several things into one umbrella here: an abstract factory class, a factory interface, and configuration. I'd rather see these broken into separate items. As it stands, there is (or was) a proposal on the table for a "configurable" interface – any class implementing it would have a setConfig() method for passing in a Zend_Config object (at this point, we've decided it should look similar to the setOptions/setConfig pair as done in Zend_Form).</p>

  4. Oct 31, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Rejection</ac:parameter><ac:rich-text-body>
    <p>We are rejecting this proposal at this time. We feel that concrete factories give more flexibility of implementation, and that we desire for flexibility of implementation of the actual adapter constructors as well (though we heavily recommend using an array or Zend_Config object of options).</p>

    <p>Additionally, this begins to look like an inversion of control solution, and we feel a Dependency Injection strategy, as proposed elsewhere, would make more sense in such situations.</p></ac:rich-text-body></ac:macro>