ZF Blog

2011-08-19 Dev status update

The first weekly status update about the development of ZF2.

Community Initiatives

Obviously, community interaction has exploded. Since last week, we've had almost 400 messages in the zf-contributors mailing list, an IRC meeting, and the start of a dedicated "ZF2" area of the main website (if you're reading this, you're in it).

Topics that have been under heavy discussion include:

  • What will modules look like, and how will they be installed (and potentially distributed).
  • Process: how should the proposal process work moving forward, and what ideas fit for it. One item we've agreed upon is that for architectural issues, posting to the mailing list, discussing in IRC, and creating RFC-style pages in the wiki is probably better.
  • Visualizing development status: a page has been built, based on the work of Evan Coury in his zf-status project. This should help folks identify what new changes and features exist that they may want to review.

If you missed the IRC meeting, we have a summary posted.

Development status

The Zend Framework core team has decided to write, every week, a post on this blog to inform about the development status of ZF2.
The aim of this update is to have a new channel where the developers that are working on the ZF2 can share ideas with the community and inform people about the working progress of the project. Of course, we have the ZF wiki, the mailing lists and the IRC channels (#zftalk.dev, #zf2-meeting) but we think that this blog can be helpful as well.
This is the first post of the new ZF2 blog about the dev status update of ZF2. We hope you will find it useful.

In the last week the Zend Framework Core Team has been involved in the development of the new Zend\Http components. In particular we have redesigned the following classes:

  • Zend\Http\Request
  • Zend\Http\Response
  • Zend\Http\Headers
  • Zend\Http\Client

We implemented these components following the RFC specifications:

  • RFC2616, for the HTTP 1.1
  • RFC3986, for the Uniform Resource Identifier (URI)
  • RFC2069, RFC2617, for the HTTP Authentication: Basic and Digest Access Authentication

The new API provided is more convenient compared with the ZF1. We provided a full OO implementation of the Headers with specific features for each type (for instance we have Zend\Http\Header\Accept that implements the Accept header type).
These classes are implemented in the namespace Zend\Http\Header. In order to support not standard headers we built a generic header class, Zend\Http\Header\GenericHeader.

The new Zend\Http\Client is basically a class that uses the Request, Response, Headers components to send request to a specific HTTP adapter.
Just to give you an idea of these new architecture, we reported an example of two different uses for the same use case:

First example


<?php
    $client
= new Zend\Http\Client('http://www.test.com');
    
$client->setMethod('POST');
    
$client->setParameterPost(array('foo' => 'bar));
    
    $response= $client->send();
    
    if ($response->isSuccess()) {
        //  the POST was successfull
    }
Second example

<?php
    $request
= new Zend\Http\Request();
    
$request->setUri('http://www.test.com');
    
$request->setMethod('POST');
    
$request->setParameterPost(array('foo' => 'bar));
    
    $client= new Zend\Http\Client();
    $response= $client->send($request);
    
    if ($response->isSuccess()) {
        //  the POST was successfull
    }

Moreover, we implemented a static version of the Zend\Http\Client to be able to write something simple code like that:

<?php
    $response
Zend\Http\ClientStatic::post('http://www.test.com',array('foo'=>'bar'));
    
    if (
$response->isSuccess()) {
        
//  the POST was successfull
    
}

Return to entries

blog comments powered by Disqus