Zend Framework

Zend_Controller_Request should have a clean interface

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: Next Major Release
  • Component/s: Zend_Controller
  • Labels:
    None
  • Fix Version Priority:
    Should Have

Description

Zend_Controller_Request should have a clean and well defined interface to allow for switching to user created (possibly lightweight) request objects. All below framework classes should use an interface instead of an abstract class:

  • Zend/View/Helper/Action.php
  • Zend/Layout/Controller/Plugin/Layout.php
  • Zend/Controller/Action.php
  • Zend/Controller/Plugin/ErrorHandler.php
  • Zend/Controller/Plugin/Broker.php
  • Zend/Controller/Plugin/ActionStack.php
  • Zend/Controller/Plugin/Abstract.php
  • Zend/Controller/Router/Route/Module.php
  • Zend/Controller/Router/Rewrite.php
  • Zend/Controller/Router/Interface.php
  • Zend/Controller/Request/Simple.php (should probably use an abstract)
  • Zend/Controller/Request/Http.php (should probably use an abstract)
  • Zend/Controller/Dispatcher/Interface.php
  • Zend/Controller/Dispatcher/Abstract.php
  • Zend/Controller/Dispatcher/Standard.php
  • Zend/Controller/Front.php
  • Zend/Controller/Action/Helper/ActionStack.php
  • Zend/Controller/Action/Helper/Abstract.php

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Michal Minicki added a comment -

I will be happy to work on this but I'm sure somebody should review this issue first. Feel free to assign it to me if you find it useful.

Show
Michal Minicki added a comment - I will be happy to work on this but I'm sure somebody should review this issue first. Feel free to assign it to me if you find it useful.
Hide
Permalink
Matthew Weier O'Phinney added a comment -

While I understand the rationale behind this from a strict OOP point of view, I disagree with it in practice. Most times, users would rather not need to write all the functionality, but rather simply use it and/or override the default functionality for a subset of methods. While there's nothing saying that we can't have abstract implmentations of the interfaces that people can standardize on, that adds yet another layer into the hierarchy, and the more of this present, the more bloated ZF will look to the lay observer.

Additionally, since many signatures are referencing the Abstract classes, we have the potential for a pretty big BC break, which is a big concern.

I'm not going to rule these changes out, but I need to sit and think on them for a while, and see what comments others might have.

Show
Matthew Weier O'Phinney added a comment - While I understand the rationale behind this from a strict OOP point of view, I disagree with it in practice. Most times, users would rather not need to write all the functionality, but rather simply use it and/or override the default functionality for a subset of methods. While there's nothing saying that we can't have abstract implmentations of the interfaces that people can standardize on, that adds yet another layer into the hierarchy, and the more of this present, the more bloated ZF will look to the lay observer. Additionally, since many signatures are referencing the Abstract classes, we have the potential for a pretty big BC break, which is a big concern. I'm not going to rule these changes out, but I need to sit and think on them for a while, and see what comments others might have.
Hide
Permalink
Michal Minicki added a comment -

The problem, which may not be clear from the first glance, is that abstract classes generally include lots of other framework components.

As well as you I would see the resulting code as abstract classes implementing the interfaces. The main difference being the rest of the framework coded against interfaces instead of abstract classes. Furthermore, this shouldn't generate BC problem since we're loosening the constraints not enforcing more (abstract class which users already extend will still implement the new interface). But I agree we're generating more "clutter" for those not well versed in OOP methodology.

The second thing is, one can implement more than one interface which is not possible with extending abstract classes. Imagine one could wich to create one object for HTTP handling, for both request and a response (abstract example, may not be as good as I wanted it to be).

In this exact moment we have both solutions in the code base - take a look at Controller Response / Request objects and a Router for instance. Router has an interface as well as a lightweight Abstract class which can be easily extended but has a dependency on Front Controller (which I have removed today by JIT loading, btw).

I know you're against it Matthew, but please take that in a serious consideration

Show
Michal Minicki added a comment - The problem, which may not be clear from the first glance, is that abstract classes generally include lots of other framework components. As well as you I would see the resulting code as abstract classes implementing the interfaces. The main difference being the rest of the framework coded against interfaces instead of abstract classes. Furthermore, this shouldn't generate BC problem since we're loosening the constraints not enforcing more (abstract class which users already extend will still implement the new interface). But I agree we're generating more "clutter" for those not well versed in OOP methodology. The second thing is, one can implement more than one interface which is not possible with extending abstract classes. Imagine one could wich to create one object for HTTP handling, for both request and a response (abstract example, may not be as good as I wanted it to be). In this exact moment we have both solutions in the code base - take a look at Controller Response / Request objects and a Router for instance. Router has an interface as well as a lightweight Abstract class which can be easily extended but has a dependency on Front Controller (which I have removed today by JIT loading, btw). I know you're against it Matthew, but please take that in a serious consideration
Hide
Permalink
Wil Sinclair added a comment -

Please categorize/fix as needed.

Show
Wil Sinclair added a comment - Please categorize/fix as needed.
Hide
Permalink
Matthew Weier O'Phinney added a comment -

Scheduling for next major release.

Show
Matthew Weier O'Phinney added a comment - Scheduling for next major release.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.