Added by Luke Crouch, last edited by Luke Crouch on May 15, 2008  (view change)

Labels

 
(None)
Under Construction

This proposal is under construction and is not ready for review.

Zend Framework: Zend_Controller_Router_Route_Rest Component Proposal

Proposed Component Name Zend_Controller_Router_Route_Rest
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Controller_Router_Route_Rest
Proposers luke.crouch@gmail.com
Revision 1.0 - 23 February 2008: Started.
1.0 - 15 May 2008: changed from Route class to full-on Router class.
1.0 - 15 May 2008: changed back to Route class (wiki revision: 24)

Table of Contents

1. Overview

Zend_Controller_Router_Route_Rest is a route that uses URI to route the module & controller and HTTP request method to route the action.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • ???

4. Dependencies on Other Framework Components

  • Zend_Controller

5. Theory of Operation

A RESTful routing paradigm for Zend_Controller should behave as follows:
Request method URI Module_Controller::action
GET /product/ratings/ Product_RatingsController::indexAction()
GET /product/ratings/id/:id Product_RatingsController::getAction()
GET /product/ratings/new Product_RatingsController::newAction()
GET /product/ratings/id/:id/edit Product_RatingsController::editAction()
POST /product/ratings Product_RatingsController::postAction()
PUT /product/ratings/id/:id Product_RatingsController::putAction()
DELETE /product/ratings/id/:id Product_RatingsController::deleteAction()
POST /product/ratings/id/:id/_method/PUT Product_RatingsController::putAction()
POST /product/ratings/id/:id/_method/DELETE Product_RatingsController::deleteAction()

6. Milestones / Tasks

  • Milestone 1: Working prototype checked into the incubator supporting use cases #1
  • Milestone 2: Unit tests exist, work, and are checked into SVN.
  • Milestone 3: Initial documentation exists.

7. Class Index

  • Zend_Controller_Router_Route_Rest

8. Use Cases

UC-01

9. Class Skeletons

Martel,

I actually started working on this again recently for a project and I ended up writing a Zend_Controller_Router_Rest class instead of a specific Route class. I updated my proposal in the wiki and would appreciate some feedback from you before I announce it to the mailing list. It actually works for me, but I'm sure it could use some cleanup and such ...

Luke, I don't really see anything in there that couldn't be used in the route class instead of a router. While overriding the router you're basically removing support for chaining different types of routing. And you render the URL view helper useless. And that's all. That's what you get by doing it in the router instead of a route class.

If you leave automatic module detection out, you don't even need the dispatcher instance (and router in fact shouldn't be aware of the dispatcher). All you need is the request object which will be passed to route instances in a very near future.

Posted by Michal Minicki at May 15, 2008 11:49 Updated by Michal Minicki

yeah, that's the best design, but RESTful routing needs the full request object and it's not currently available to Route classes, as you mentioned. I have this same code in a Route class as well, but it couldn't access the request object, so it's impossible to get the request method in a Route.

I'll just use this Router class in my project for now, but I will change this back into a Route and I think it will just have to wait until the request object is passed into Route instances. please keep me posted on how and when that advances. thanks.

Luke, pay attention to this issue:
http://framework.zend.com/issues/browse/ZF-777

As Matthew mentioned it in the last comment, I have a patch that keeps backwards compatibility intact. Basically this means you will just have to implement an additional interface (with setRequest method). And that's it - the request will be available for you on match().

As I have mentioned before, you now have a Request object passed as a first parameter to match() method on version 2 routes. Just extend abstract class to get this behavior by default.

Michal,

cool, thanks! I saw the issue update. is this presently only in trunk? is it slated to go out with next release?