http://packages.zendframework.com/

This is the second in a series of planned beta releases. The beta release cycle is following the "gmail" style of betas, whereby new features will be added in each new release, and BC will not be guaranteed; beta releases will happen approximately every six weeks. The desire is for developers to adopt and work with new components as they are shipped, and provide feedback so we can polish the distribution.

Once all code in the proposed standard distribution has reached maturity and reasonable stability, we will freeze the API and prepare for Release Candidate status.

Featured components and functionality of 2.0.0beta2 include:

• Refactored Mail component
  • The Storage API has been left intact, though several classes and interfaces were shuffled around.
  • Zend\Mail\Mail was renamed to Zend\Mail\Message; it now encapsulates a mail message and all headers. MIME messages are created by attaching a Zend\Mime\Message object as the mail message body
  • Added Zend\Mail\Address and Zend\Mail\AddressList, used to represent single addresses and address collections, particularly within mail headers
  • Added Zend\Mail\Header\* and Zend\Mail\Headers, representations of mail headers.
  • A new Zend\Mail\Transport interface defines simply send(Message $message). The SMTP, File, and Sendmail transports were rewritten to consume Message objects, and to introduce Options classes.
• Refactored Cache component
  • Completely rewritten component.
  • New API features storage adapters and adapter plugins for implementing cache storage and features such as serialization, clearing, and optimizing.
  • Current adapters include filesystem, APC, memcached, and memory.
  • All adapters can describe capabilities.
  • Plugins are implemented as event listeners.
  • A new "Pattern" API was created to simplify things like method, class, object, and output caching.
• MVC updates
  • Zend\Module\Manager was stripped of most functionality; it now simply iterates requested modules and triggers events.
  • Former manager functionality such as class loading and instantiation, init() triggering, configuration gathering, and autoloader seeding were moved to event listeners.
  • Post-module loading configuration globbing support was added, simplifying the story of overriding module configuration.
  • The recommended filesystem no longer uses plurals for directory names.
  • The recommendations now include a chdir(__DIR__ . '/../') from the "public/index.php" file, and specifying configuration paths to be relative to application directory.

In addition, over 100 bug and feature requests were handled since 2.0.0beta1.

The skeleton application and a skeleton module built for 2.0.0beta1 have been updated for 2.0.0beta2, and are a great place to look to help get you started. You may also want to check out the quick start guide to the MVC. powerful.

As a reminder, all ZF2 components are also available individually as Pyrus packages; packages.zendframework.com is our official channel.

I'd like to thank each and every person who has contributed ideas, feedback, pull requests (no pull request is too small!), testing, and more -- we have a solid chunk of quality new functionality to test now thanks to your efforts!

We've now moved our canonical repository to GitHub, which is where most folks were forking and doing development anyways. The reasons were several:

• The main reason for self-hosting was to make checking CLA status simpler. As ZF2 development no longer requires a CLA, this reason is gone.
• ACLs for providing commit access are easier to manage on GitHub, and do not require us to first receive SSH keys from contributors.
• Using GitHub directly simplifies the pull request process. When self-hosting, we would merge and push to the canonical repo, and then need to manually close the pull request; using GitHub, PRs are automatically closed when the code is merged. Additionally, because the mirroring only occurred a few times per day, it was not immediately evident on GitHub when a change was available to test.
• There was often confusion by developers on where the most current changes were, particularly if they forked from the GitHub repository.

The practical upshot is that if you had git.zendframework.com as a remote on your repository, you should remove it. If you didn't have a github.com/zendframework/zf2 remote, you should add one. The ZF2 Git Guide details adding the remote.

MVC Developments

Two big things occurred in the MVC this week.

First, we did some re-thinking of the duties of the Module Manager. Previously, it was responsible for merging configuration and firing module initialization. A recommended part of module initialization was to initialize autoloading.

What we noticed was:

• Configuration merging was getting more complex, and we were getting potentially incompatible feature requests.
• Our modules were getting hard dependencies on things like autoloaders, and were also introducing a lot of boiler-plate code.
• We had no clear path to how we might cache autoloading configuration for production.
• We were noticing more and more places where we might want to loop through the loaded modules in order to trigger methods of interest.

So, the solution was to change things: Zend\Module\Manager::loadModule() now triggers a "loadModule" event, passing it the newly created module. This allows listeners to react to modules real-time as they're loaded.

This also meant that the code for the following actions could be moved to listeners:

• Autoloading
• Configuration loading
• Module "initialization"

This allows modules that look like this:

namespace Blog;

use InvalidArgumentException,
    Zend\EventManager\StaticEventManager,
    Zend\Module\Consumer\AutoloaderProvider;

class Module implements AutoloaderProvider
{
    public function init()
    {
        $events = StaticEventManager::getInstance();
        $events->attach('bootstrap', 'bootstrap', array($this, 'bootstrap'));
    }

    public function getAutoloaderConfig()
    {
        return array(
            'Zend\Loader\ClassMapAutoloader' => array(
                __DIR__ . '/autoload_classmap.php'
            ),
        );
    }

    public function getConfig()
    {
        return include __DIR__ . '/configs/module.config.php';
    }
    
    /* ... */
}

This looks about the same as before! The differences are:

• getAutoloaderConfig() can simply return an array of options to pass to Zend\Loader\AutoloaderFactory. This allows us to obtain a fully configured autoloader at the end -- which we will eventually be able to cache, and thus eliminate the need for the autoloader listener.
• getConfig() is no longer called directly by the module manager, but instead by a listener. Again, this will make it possible to cache the full application configuration.
• init() is called by a listener now.

In other words, the differences are largely under the hood. But those differences mean that it's trivially easy to develop your own listeners to tie into the module loading process in order to do interesting things -- all without needing to touch or extend the main module manager.

Application Configuration

Several people indicated that much as they like module configuration merging, they weren't liking the solutions for overriding configuration at the application level. The solutions to date have been:

• Register the module with overrides last -- for instance, your Application module.
• Create a configuration-only module that registers last.

The consensus was that a module for simply providing configuration overrides "sucks", and that using the "Application" module sometimes was problematic (especially for purposes of registering view script paths).

The solution was to add some logic to provide application-level configuration. This was added to the configuration listener, and allows for you to specify a directory with configuration (ala "conf.d" style configuration now commonly used across a number of *nix distributions); this configuration is then merged after module configuration is aggregated. Your index.php would then contain something like the following:

$moduleManager = new Zend\Module\Manager($appConfig['modules']);
$listenerOptions = new Zend\Module\Listener\ListenerOptions($appConfig['module_listener_options']);
$moduleManager->setDefaultListenerOptions($listenerOptions);
$moduleManager->getConfigListener()->addConfigGlobPath(dirname(__DIR__) . '/config/autoload/*.config.php');
$moduleManager->loadModules();

Hopefully, these changes will simplify how app-specific configuration is managed.

Beta2 is coming!

Beta2 is coming up soon! We're hoping to have it ready by the end of the month. The components currently under development for beta2 include:

• Zend\Log
• Zend\Cache
• Zend\Mail

Cache is mostly complete and needs some review and input regarding its usage of the EventManager. Log and Mail are currently under development. We encourage you to reach out on the #zftalk.2 IRC channel on Freenode or the zf-contributors mailing list if you would like to assist with testing or development of these components.

IRC meeting this week

We have another IRC meeting this week. Follow the link to see the agenda -- and add to it if you want to discuss additional topics.

The last update was during the busy-ness of ZendCon, where we announced the first beta release of ZF2. The release was met with a lot of enthusiasm, and we've seen increased usage and testing of ZF2 in the weeks following.

Since then, let's recap what's been going on in ZF2 development.

IRC Meetings

26 October 2011 IRC Meeting

We held an IRC meeting the Wednesday immediately following ZendCon. During the meeting, we discussed three items: a nascent ACL/RBAC RFC, differences between RFCs and proposals, and module distribution and installation.

The conclusions were:

• Not enough details as to whether we need to refactor ACL, other than to take advantage of some SPL interfaces and classes. Somebody needs to spearhead this. Additionally, if those changes are made, the few calls for an RBAC component may be moot.
• RFCs are for architectural changes or to discuss refactors/rewrites of existing components; proposals are for new components. Consensus is that we need more action and visibility from the CR-Team, and those on the team that were present took notes and followed up with a meeting.
• Basically, the Modules distribution/instalation RFC is on hold until some other intitiatives (such as the CLI RFC) are finalized.

Read the full log.

9 November 2011 IRC Meeting

Two weeks later (this week!) we had another IRC meeting, covering three separate RFCs: Mail, Log, and CLI.

Both the Mail and Log RFCs were approved for development, with some questions/changes/additions/etc. highlighted during the meeting.

The CLI RFC is still somewhat rough and needs additional detail, but is headed in the right direction.

Read the full log.

RFCs

Three new RFCs were added (and discussed):

• Zend\Log refactoring
• Zend\Mail refactoring
• Console refactoring/CLI component/Tool refactoring

As noted in the section on IRC meetings, the Log and Mail RFCs have been approved for development, and are on target for our second beta release. The CLI RFC is still being revised, but is on target for a potential beta3 release.

Development

Most development has centered on revisions due to feedback on beta1. In particular, some new ideas have been fleshed out to simplify the module manager, while simultaneously making it more flexible and easier to accomplish initialization tasks (such as retrieving autoloading and configuration artifacts, registering events, etc). You can view a sample here. Additionally, Ralph has been working to accommodate a number of additional DI use cases identified by users testing the new MVC.

Matthew has removed all ZF1 MVC components and pushed them into a new module, under "modules/ZendFramework1Mvc". As part of that work, he also identified all components that had dependencies on the old MVC system (particularly the front controller), and refactored them to remove those dependencies and support dependency injection. This work is on the current master.

Enrico has been working on adapting the latest version of the Windows Azure SDK to ZF2, as well as addressing it in the Zend\Cloud\Infrastructure component. We should see this work hitting master early next week.

With the Mail and Log RFCs now ratified, development on these will progress, and we should see fresh code for these components next week.

Finally, we announced that ZF2 contributions no longer require a CLA, effective immediately. Since the announcement, we've seen quite a number of new pull requests from new contributors, and we expect this trend to continue.

Fin

These are exciting times for Zend Framework 2 development, and we encourage you to get involved!

http://packages.zendframework.com/

This is the first in a series of planned beta releases. The beta release cycle will follow the "gmail" style of betas, whereby new features will be added in each new release, and BC will not be guaranteed; beta releases will happen no less than every six weeks. The desire is for developers to adopt and work with new components as they are shipped, and provide feedback so we can polish the distribution.

Once all code in the proposed standard distribution has reached maturity and reasonable stability, we will freeze the API and prepare for Release Candidate status.

Featured components and functionality of 2.0.0beta1 include:

• New and refactored autoloaders:
  • Zend\Loader\StandardAutoloader
  • Zend\Loader\ClassMapAutoloader
  • Zend\Loader\AutoloaderFactory
• New plugin broker strategy
  • Zend\Loader\Broker and Zend\Loader\PluginBroker
• Reworked Exception system
  • Allow catching by specific Exception type
  • Allow catching by component Exception type
  • Allow catching by SPL Exception type
  • Allow catching by base Exception type
• Rewritten Session component
• Refactored View component
  • Split helpers into a PluginBroker
  • Split variables into a Variables container
  • Split script paths into a TemplateResolver
  • Renamed base View class "PhpRenderer"
  • Refactored helpers to utilize __invoke() when possible
• Refactored HTTP component
• New Zend\Cloud\Infrastructure component
• New EventManager component
• New Dependency Injection (Zend\Di) component
• New Code component
  • Incorporates refactored versions of former Reflection and CodeGenerator components.
  • Introduces Scanner component.
  • Introduces annotation system.

The above components provide a solid foundation for Zend Framework 2, and largely make up the framework "core". However, the cornerstone feature of beta1 is what they enable: the new MVC layer:

• Zend\Module, for developing modular application architectures.
• Zend\Mvc, a completely reworked MVC layer built on top of HTTP, EventManager, and Di.

We've built a skeleton application and a skeleton module to help get you started, as well as a quick start guide to the MVC; the new MVC is truly flexible, and moreover, simple and powerful.

Additionally, for those who haven't clicked on the packages link above, we are debuting our new distribution mechanisms for ZF2: the ability to use Pyrus to install individual components and/or groups of components.

Since mid-August, we've gone from a few dozen pull requests on the ZF2 git repository to over 500, originating from both long-time Zend Framework contributors as well as those brand-new to the project. I'd like to thank each and every one of them, but also call out several individuals who have made some outstanding and important contributions during that time frame:

• Evan Coury, who prototyped and then implemented the new module system.
• Rob Allen, who, because he was doing a tutorial at PHPNW on ZF2, provided a lot of early feedback, ideas, and advice on the direction of the MVC.
• Ben Scholzen, who wrote a new router system, in spite of a massive injury from a cycling accident.
• Ralph Schindler, who has had to put up with my daily "devil's advocate" and "think of the user!" rants for the past several months, and still managed to provide comprehensive code manipulation tools, a Dependency Injection framework, and major contributions to the HTTP component.
• Enrico Zimuel, who got tossed requirements for the cloud infrastructure component, and then had to rework most of it after rewriting the HTTP client from the ground up... and who still managed three back-to-back-to-back conferences as we prepared the release.
• Artur Bodera, who often has played devil's advocate, and persisted pressing his opinions on the direction of the framework, often despite heavy opposition. We may not implement all (or many) of the features you want, but you've definitely influenced the direction of the MVC incredibly.
• Pádraic Brady, who started the runaway train rolling with a rant, and helped make the project much more transparent, enabling the MVC development to occur in the first place.

Welcome to the ZF2 beta cycle!

We held our fourth IRC meeting on Wednesday, 28 September 2011. On the agenda were:

• Discussion of a Doctrine Bridge
• Discussion of the Standard Distribution
• Roadmap

The meeting has been summarized previously. The tl;dr for those who don't want to click through on the link:

• Everyone agrees we'd like a Doctrine Bridge; it's up to somebody to get something concrete rolling.
• The Standard Distribution was previously defined; however, additions will be considered on a case-by-case basis.
• Expect beta 1 to drop during ZendCon.

Development Notes

View Convenience API

After a prolonged discussion, I worked on a "View Convenience API". The goal was to simplify view usage and syntax.

The end result is a syntax very much like ZF1, but more performant under the hood, and with easier ways to get at the various helper objects. Per a suggestion (and pull request!) from Rob Allen, we now extract view variables prior to rendering the view script. Since the Variables container returns escaped versions of variables by default, this makes for very succinct syntax. You may also access variables using property overloading (e.g., $this->foo), via a get() method, or by accessing the Variables container directly. Additionally, you can now access the unescaped values using a new raw() method in the renderer.

Helpers can now be accessed via method overloading, as they were in ZF1. The following will occur:

• If the helper is invocable (i.e., a functor, implementing the __invoke() magic method), it will be invoked with any arguments passed.
• If not invocable, the helper instance will be returned.

Additionally, an "escape" view helper was created. This is composed into the Variables container by default, and allows specifying alternate callbacks and encoding when desired.

<?php $this->gt;headTitle($title) ?>
<h2>gt;<?= $title ?></h2>
<ul>gt;
<?php foreach ($entries as $entry): ?>gt;
    <li>gt;<?= $this->escape($entry->getName()) ?></li>
<?php endforeach ?>gt;
</ul>gt;

tl;dr: The view layer is fun again!

Controller Convenience API

Following a couple short threads about a controller convenience API, I implemented a few new features in the MVC controller layer:

• Controllers may be optionally "event injectible". If they are, they will be injected with the MvcEvent used in the Application object. This allows it to be tied more closely into the full request cycle.
• Controllers may be optionally "locator aware". If they implement the LocatorAware interface, they will be injected with the DI container or Service Locator attached to the Application. This can be used to pull out optional dependencies.
• We've created a controller-layer plugin broker, analagous to ZF1's "action helper" system. The idea behind this is to provide re-usable functionality for controllers in a light-weight fashion. Unlike ZF1, these plugins will not be workflow-aware, and will only optionally be injected with the current controller (based on presence of a setController() method).
• You can access controller plugins via method overloading. Unlike view helpers, method overloading only ever returns the plugin instance.

So, in a nutshell:

class FooController extends ActionController
{
    public function processAction()
    {
        // Locator-awareness for pulling conditional functionality:
        $form = $this->getLocator()->get('foo-form');
        
        $post = $this->getRequest()->post()->toArray();
        if ($form->isValid($post)) {
            // do some processing
            // Redirection via a plugin:
            return $this->redirect()->toRoute('foo-success');
        }
    }
}

Working controller plugins now include:

• Url (generates URLs from a configured router)
• Redirect (updates the Response object with a redirect status code an Location header; Location URL can be either a static URL or generated from the router)
• FlashMessenger (session-based flash messages)
• Forward (dispatch an additional controller)

The last plugin enables users to dispatch an additional controller -- without requiring a dispatch loop within the Application::run() logic! It does, however, require that the controller calling it be defined as LocatorAware, so that it can obtain the configured controller instance.

tl;dr: The Controller layer is getting a lot of good functionality.

Zend\Code refactoring

Ralph worked for several weeks on a refactoring of the Zend\Code component. Part of this was moving Reflection and CodeGenerator under that tree, as well as ensuring the APIs were consistent across all three components (as Zend\Code also contains the Scanner component). This work was merged on 6 October 2011.

Part of this update also included a comprehensive annotations parser. This allows us to now scan docblocks for annotations and represent them as objects, giving rise to a number of potential new workflows for ZF2.

DI Updates

One key driver behind annotations support was to allow using annotations to hint to the DI Compiler how to create definitions. Additionally, work was done to allow creating definitions via configuration. This allows things like:

use Zend\Di\Definition\Annotation as Di;

class Foo
{
    /**
     * @Di\Inject()
     */
    public function setEvents(EventCollection $events)
    {
    }
}

which will inform the DI container that this method should be injected at construction. Additionally, you can now do things like this:

$config['di'] = array(
'definition' => array('class' => array(
    'Mongo' => array(
        '__construct' => array(
            'server'  => array(
                'required' => false,
                'type'     => false,
            ),
            'options' => array('required' => false),
        ),
    ),
    'MongoDB' => array(
        '__construct' => array(
            'conn' => array(
                'required' => true,
                'type'     => 'Mongo',
            ),
            'name' => array(
                'required' => true, 
                'type'     => false,
            ),
        ),
    ),
    'MongoCollection' => array(
        '__construct' => array(
            'db' => array(
                'required' => true,
                'type'     => 'MongoDB',
            ),
            'name' => array(
                'required' => true, 
                'type'     => false,
            ),
        ),
    ),
    'Blog\EntryResource' => array(
        'setCollectionClass' => array(
            'class' => array(
                'required' => false,
                'type'     => false,
            ),
        ),
    ),
)),
'instance' => array(
    'Mongo' => array('parameters' => array(
        'server'  => 'mongodb://localhost:27017',
    )),
 
    'MongoDB' => array( 'parameters' => array(
        'conn' => 'Mongo',
        'name' => 'myblogdb',
    )),
 
    'MongoCollection' => array('parameters' => array(
        'db'   => 'MongoDB',
        'name' => 'entries',
    )),
 
    'Blog\EntryResource' => array('parameters' => array(
        'dataSource' => 'CommonResource\DataSource\Mongo',
        'class'      => 'CommonResource\Resource\MongoCollection',
    )),
 
    'CommonResource\DataSource\Mongo' => array('parameters' => array(
        'connection' => 'MongoCollection',
    )),
));

The above will ensure that we use the provided scalar values for injection in the various constructors and setters in the definition, and still allows for object injection when required (e.g., conn, db, dataSource, connection).

tl;dr: DI has become incredibly flexible and powerful!

Cloud Infrastructure

Enrico managed to finish testing all Zend\Cloud\Infrastructure functionality, with both online and offline tests! This gives us great confidence in the components (plural, as all infrastructure services also have related components under Zend\Service), and makes for a great new feature in ZF2. Enrico also backported the Infrastructure component to ZF1's trunk, in anticipation of an additional release on the ZF1 tree in the future.

CLI Module

Robert Basic wrote to the list about a prototype CLI module. The basic idea is to leverage the module architecture for executing CLI requests; routing would be performed utilizing Zend\Console\Getopt instead of the MVC router. Additionally, it would provide functionality for colorizing output. Overall, a solid beginning to a potential new console component!

Presentations

Both Rob Allen and Robert Basic gave presentations during the weekend of 7 - 9 October 2011, with Robert Basic giving a general overview session on ZF2 at Webkonf and Rob Allen giving a full day tutorial at PHPNW. Rob Allen's slides may be viewed online.

The Future

We have an IRC meeting this coming Wednesday, 12 Oct 2011; please post topics and/or vote on those already posted -- and make sure you're in attendance for the discussions!

Also, we'll be tagging beta1 this week, in preparation for a release during ZendCon next week. If you have feedback on the MVC or DI, please let us know ASAP!

We held our third IRC meeting on Wednesday, 14 September 2011. On the agenda were:

• RFC on configuration
• Where components falling outside the standard distribution should live if incomplete
• Goals of the Module Manager
• Directory structure for modules

Configuration

Between the competing RFCs on configuration, the IRC discussion, and some back-and-forth following the meeting, the following summarizes the current consensus on how ZF2 will deal with component configuration:

• Hard dependencies that do not have sane defaults would be in the constructor signature
• The last argument in the constructor signature would be optional, and expect an instance of the component's Options class
• If a dependency has a sane default, we would not include an argument in the constructor, but would allow setter injection (which could be automated by the DI container)
• The component's Options class would handle optional configuration arguments, and provide validation for those arguments.
• The component would directly access optional arguments from the Options instance it composes

Note the word "Options". In discussions, we decided we should call this functionality "Options" as it denotes that the values are optional, and also to prevent nomenclature conflicts with the already existing Zend\Config component. We will be producing a poll on the wiki to do a final vote very soon.

Unfinished "Extras" components

The discussion centered around whether or not we would remove unrefactored components that fall outside the standard distribution -- things like service components that have not been converted to namespaces, updated to latest exceptions practices, and not refactored to use the new HTTP functionality.

Only slight debate erupted -- the decision is:

• Keep this functionality in the master branch
• Add an annotation such as "@incomplete" to the file and/or class-level docblocks.
• Add the "@incomplete" annotation to related test classes, and add a rule to phpunit.xml to skip such tests.
• Comment out sections in the manual referring to these components.

We will then add rules to packaging to omit such classes and resources.

Module Manager Goals

The Module Manager is a component for scanning and initializing modules during application bootstrapping. As such, it's fairly central to the new MVC approach, and we wanted to be sure we captured its goals. A sizable list of goals was presented, and we voted on each. There are too many to relate here, so instead I'll simply link you to the summary.

Most items were straight-forward, but there are a few conflicting ideas about what the scope of the manager; should it simply act as a kernel for bootstrapping, or have deep ties within the application?

Current development of this tool has taken the former approach, but has exposed a number of useful features that allow a ton of flexibility for a variety of approaches. One, in particular, is a method getLoadedModules(), which returns an associative array of module name/module objects. With this, I was able to do such things as loop through modules, check for the existence of specific methods, and then call them to do things such as event listener registration.

Module Directory Structure

By the time of the meeting, we already had a couple different module directory structures floating around, and the discussion centered on which one to use. Except that several people brought up one very, very good point: with a well-known class (the module's "Module" class) that we're querying, the structure doesn't matter, and does not need to be enforced.

As such, our decision was that we should have a recommended structure that satisfies the various use cases we originally brainstormed. Among these:

• Ability to serve multiple namespaces (if desired)
• Separation of code from non-code assets, if provided (such as CSS, JS, HTML)
• Separation of view templates, if provided, from code
• Separation of configuration, if provided, from code

As such, the following structure was generally agreed upon as a recommendation:

modules/
    SpinDoctor/
        Module.php
        autoload_classmap.php
        autoload_function.php
        autoload_register.php
        configs/
            module.config.php
            routes.config.ini
        public/
            images/
            css/
                spin-doctor.css
            js/
                spin-doctor.js
        src/
            SpinDoctor/
                Controller/
                    SpinDoctorController.php
                    DiscJockeyController.php
                Form/
                    Request.php
        tests/
            bootstrap.php
            phpunit.xml
            SpinDoctor/
                Controller/
                    SpinDoctorControllerTest.php
                    DiscJockeyControllerTest.php
        views/
            spin-doctor/
                album.phtml
            disc-jockey/
                turntable.phtml

Public assets such as images, CSS, and JS could either be symlinked into the public tree, copied, or managed by an asset manager such as Assetic.

Regarding the various autoload_*.php files, these were brought up in a post from Ralph, based on discussions he and I have had. The idea behind these is that we can satisfy several typical use cases for modules:

• Download and use: simply require 'autoload_register.php'; and start using classes.
• Use with custom registration: spl_autoload_register(include 'autoload_function.php');, which allows you to specify to spl_autoload_register whether or not to append or prepend the function to your autoloader stack.
• Custom autoloading class map: aggregate the returns of autoload_classmap.php into a single classmap for your application.

There's still some discussion going around these files, but they've been adopted in the prototypes at this time.

MVC Prototype Status

The MVC prototype has grown tremendously, in large part due to the efforts of Evan Coury and his work on the Module Manager. The module manager now does the following:

• Aggregates configuration from all modules
  • Including modules provided as phars!
• Provides introspection and access to discovered modules
• Optionally allows configuration caching

The MVC prototype has also grown. Based on a suggestion from Greg N. on the mailing lists, the EventManager was refactored slightly to do the following:

• Removed references to "handlers" in favor of "listeners" to provide a consistent terminology (both internally as well as with other systems of similar design)
• trigger now allows passing an Event object for any one of its required arguments. This allows creation of custom Event objects, as well as re-use of them.
• trigger was modified to allow an optional final argument, either the fourth argument or an argument following an Event object: a callback that indicates whether or not to halt execution. This largely eliminates the need for triggerUntil at this time.
• Locally attached listeners are now combined with static listeners into a single priority queue when trigger is called. This provides a consistent expectation, and allows you to register static listeners that can be called prior to those attached locally.

What the above allowed was the ability to move routing and dispatching into listeners within Zend\Mvc\Application, using a custom MvcEvent object. The upshot is:

• Simpler code
• Accessors for well-known (and/or expected) objects (e.g., getRequest(), getRouteMatch(), getResult())
• Events are registered with priority in order to shape the execution workflow
• The ability to replace the default routing and dispatch listeners with custom listeners.

This last point allowed me to prototype a ZF1-emulation layer in the new ZF2 paradigm. This effort was surprisingly easy, and helped illustrate how flexible the prototype can be.

Additional work on the MVC centered around error handling, and providing a simple mechanism for discovering and handling errors. The zf-quickstart example showed that this largely eliminates the need for an ErrorController.

At this time, we're quickly closing in on what the MVC will likely look like for ZF2, and hope to merge the ZendMvc and ZendModule modules into the library very soon.

DI Annotation Support

Ralph has been refactoring the Reflection, CodeGenerator, and Code\Scanner components to follow a consistent API, and to live under a common tree, Zend\Code. Part of this work is to also provide a parser/tokenizer for PHP docblocks, with the goal of providing annotation support to components that need it. In particular, this could assist the Dependency Injection component, allowing more intelligent hinting as to what setters are required and/or the specific arguments to inject. Another potential use might be with modules, to indicate what they provide and/or methods that should be called at initialization.

This work should hit master this week, and will be compatible with the docblock extension.

Cloud Infrastructure

Enrico has been working on updating the Amazon, Rackspace, and GoGrid services to use the new HTTP functionality. In doing so, he's discovered areas where the HTTP component needed improvement, as well as places he could better test. At this time, all changes he's done are incorporated in the master branch, with the exception of some tests for GoGrid.

This work has helped round out a new offering in Zend Framework, as well as to test recent development work and ideas such as the HTTP component and the Options proposal.

The Future

There are new RFCs and discussions erupting regularly on the mailing list and in the #zftalk.2 IRC channel on Freenode; I encourage you to subscribe to the former and join in the latter so that you can participate.

Also, we have an IRC meeting this week, 28 September 2011 at 17:00 UTC. The agenda is online, but could potentially use some more topics and votes. Talk to you Wednesday!

2011-08-31 IRC Meeting

First, we held our second IRC meeting on Wednesday, 31 August 2011. The intended purpose of the meeting was to discuss and vote on two RFCs, Modules and Distribution. Discussion was heated for much of the meeting, but a number of ideas were clarified and ratified during the process. In particular, we gained consensus surrounding the difference between components and modules, and started a conversation surrounding what we may include in modules in the future. Visit the meeting log for more details.

MVC Prototyping

Following the meeting, I created and published the first "official" MVC prototype in a branch of my repository. The prototype was created as a module (under "modules/Zf2Mvc") in order to also prototype one suggested format for developing modules under ZF2. We had two threads in the mailing list detailing and discussing the prototype. At the time of this writing, all major feedback has been incorporated.

Building on top of the MVC prototype, I then created a new branch of the zf-quickstart project that utilizes the new prototype, which also resulted in a fair bit of discussion.

In IRC, Rob Allen and Evan Coury took the prototype and quickstart as a starting point for a "Module Manager" component that could discover module configuration, autoloading, etc. Evan quickly developed a new module, "Zf2Module," for exactly this purpose (code is on GitHub. After a few revisions, he created a "sandbox" project that illustrates how one might start a project and gradually add modules to it in order to enable new features. Included in the project is a basic homepage and error page as a discrete module, based on the quickstart; a "user" module for simple user authentication and registration; and the guest book from the quickstart.

The tl;dr: Lots of momentum on the MVC front, with viable MVC and module system prototypes.

Options, configuration, and what? Oh, My!

Early last week, Ralph wrote up a proposal for configuration in ZF2, and opened a thread in the mailing list. The response was fairly heated, and resulted in a counter-proposal within an hour or two by Artur Bodera, followed by more discussion on the list, and then even more discussion.

After the dust settled, the basic consensus appears to be:

• Denote hard dependencies in the constructor (if no sane default is likely)
• Aggregate "soft" dependencies (i.e., optional configuration) as component-specific "configuration objects", which will allow:
• Moving option validation into configuration objects
• Resulting in fewer necessary internal variables (pull these options from the config object)
• Re-use of configuration objects with many instances
• Ability to create config object extensions with application-specific defaults
• Better hinting for IDEs
• Potentially easier to document options

However, we still need to vote on this topic. (Hint: I'll be proposing it for this week's IRC meeting.)

Pull Requests, Sweet Pull Requests

I managed to merge in something like 50 new pull requests in the past week. Keep 'em coming!

The Future

We've been reviewing options for distributing ZF and potentially modules. At this time, candidates include PEAR, Pyrus, Composer, or going home-grown. We've been reviewing our options, and doing some prototyping, and hope to have a recommendation this week.

I've been working on some proposals surrounding the View layer, and getting some initial feedback from interested parties before posting some RFCs; they should be posted early this week, however.

There are new RFCs and discussions erupting daily on the mailing list and in the #zftalk.2 IRC channel on Freenode; I encourage you to subscribe to the former and join in the latter so that you can participate.

Specifically, we discussed:

• Modules - defining what "module" means, and differentiating it from "component", as well as defining these terms in relation to "library" and "application".
• Distribution categories - what broad categories we'll define as "buckets" for components, and which categories will be considered necessary for the "standard distribution" -- which defines what needs to be done to be considered stable.
• Timeframes for potential releases.

The full transcript, as well as a summary of decisions, can be found on the ZF2 wiki.

First, completion of the initial HTTP component development took a bit longer than anticipated. As a team we felt the need to ensure that we had at least the basic documentation covered, and in doing so, uncovered additional use cases that needed fixing. We felt this was time well-invested however, as most code currently using Zend\Http\Client should work with little to no modification from the original --- while sporting a much better design that better separates concerns between a request object, response object, and the client invoking them.

This allows us to announce a new developer snapshot, 2.0.0dev4:

• Zip: http://framework.zend.com/releases/ZendFramework-2.0.0dev4/ZendFramework-2.0.0dev4.zip
• Tar: http://framework.zend.com/releases/ZendFramework-2.0.0dev4/ZendFramework-2.0.0dev4.tar.gz

Also in this release, we were able to convert documentation to DocBook 5, Zend\Dojo was brought up-to-date with changes in ZF1, and much, much more due to the efforts of a large number of contributors who have submitted an unprecedented number of pull requests in the past several weeks.

Second, we also had a number of infrastructure issues. Our mailing list went black for 3-4 days, and no real solution was found. However, the pipes appear to be fully open at this point, and we've had some great discussion over the weekend and early this week.

RFCs

A couple of RFCs have been posted:

• RFC - What will the ZF2 distribution include?
• Mailing list discussion
• RFC - ZF2 Modules
  • Mailing list discussion

If you have any input, we'd appreciate having it ASAP, so that we can finalize these and move on to defining discrete development tasks.

IRC Meeting this week

We have another IRC meeting at 17:00 UTC on 31 Aug 2011. The agenda is on the wiki, and we invite you to add/comment/vote on topics prior to the meeting. Votes will be closed approximately 1 hour prior to the meeting.

Current development

We're planning on working on a few items in the next week or so, roughly in order of priority:

• Creation of a dedicated branch for the MVC prototype currently in the zf-quickstart project.
• Investigation of Pyrus to see if it can meet the requirements set forth by the community on both distribution of the framework as well as potentially modules.
• Investigation of phar as a foil to the above (but more particularly for module distribution).
• Continued collaboration on the Router.

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

• 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 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

    $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
    }
    

    $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
    }
    

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