compared with
Version 4 by Casey Wilson
on Sep 22, 2010 14:52.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
* _Singletons_. Many singletons have a lot of behavior coded into them, making it difficult, if not impossible, to provide alternate implementations. Examples include {{Zend_Controller_Front}}, {{Zend_Auth}}, and {{Zend_Session}}.
* _Use of abstract classes instead of interfaces_. Many ZF components define rich abstract classes with a plethora of behaviors. While these may be extended and alternate implementations provided, doing so often requires accepting functionality you don't need, or needing to overwrite large sets of functionality you don't want. In many cases, the consuming classes only rely on a small subset of behaviors.
* _Hard-coded dependencies_. In many cases, components have hard-coded dependencies, making it impossible to alter behavior without extending the class to add your own dependency or to allow injecting the dependency.
* _Failure to identify processes that could benefit from collaborators_. As an example, many of {{Zend_Db}}'s methods could benefit from user extension -- for instance, to allow checking for and writing to a cache, normalizing values prior to insertion, etc. In order to do this now, users must extend the existing classes, leading to difficult to traverse hierarchies and reducing re-usability. A plugin/filter system could alleviate these issues easily.

* *MUST* remove hard-code dependencies and allow for dependency injection.
* *MUST* examine each component and address the need for collaborators.
* *SHOULD* add a section to the documetnation documentation for each component, showing in a consistent structure the component's support for extension, plugins, and hooks.

h3. Improve baseline performance of the framework
h3. Simplify maintenance of the framework

As of the time of this writing, Zend Framework consists of over 2 million lines of code, including over 14k unit tests. The internal team at Zend consists of a project lead and two engineers, while actual contributors number in the dozens. Contributors come and go, largely based on their interest in specific components and the time they have to devote to the project. High turnover of maintainers and lack of availability from maintainers, both internally and amongst contributors, has led to many orphaned components and/or components with large numbers of issues filed against them.

Additionally, with the growing complexity of many of the components, often due to differing expectations between different end-users and the original designs, we often get internal conflicts within components, where resolving one issue or addressing one feature requests can spawn regressions for existing functionality.
On a related note, when pushing an application to production, often there are huge swaths of the framework that must be pushed that will never, ever be used, which wastes bandwidth, time, and disk space.

We have traditionally shipped the entire framework because it makes sense to have the entire framework available; if you need a component, you don't need to fetch it before using it. However, with the shear breadth of the framework, and the many uses to which developers are putting it, the time has come to enable developers to select individual components.

h4. Goals
requirements of collaborators.

As an example, in the 1.X series of {{Zend_Controller}}, we have abstract {{Request}} and {{Response}} objects. These have grown over time to include additional functionality useful to developers, but the core functionality used within the ZF components themselves is quite minimal. Ideally, we would create lean interfaces capturing the behavior necessary for {{Request}} and {{Response}} objects to work in the ZF MVC -- thus making it easier for developers to slip-stream in their own implementations. Any functionality beyond what is defined in the interface would be relegated to individual implementations, and likely through collaborator objects to ensure that alternate implementations don't break additional functionality.

h4. Goals