2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 Announced at first ZendCon.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 First public preview release. Code repository opened. Fall of 2006, rewrite of MVC performed to lead towards stable release.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 First stable release. Basic MVC system, with plugins, action helpers, automated view rendering etc. Many web service API consumers. Server classes for XML-RPC, REST, etc.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 First minor release. Zend_Form introduced. Zend_Layout introduced. Layout-aware view helper system introduced.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 Dojo integration. PHPUnit scaffolding for testing controllers. Introduction of the ContextSwitch action helper.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 Introduction of Zend_Tool. Introduction of Zend_Application. First widely usable release of ZF.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 Addition of Zend_Feed_Reader. PHP 5.3 support/compatibility. Primarily community-led additions. Beginning of monthly bug hunts in October.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 Integration of ControllerTestCase with Zend_Application. Addition of Zend_Feed_Writer, marking completion of Zend_Feed refactoring. Documentation changes: adoption of PhD to render end-user manual, introduction of comment system, and new “Learning Zend Framework” section. Primarily community-led additions.
2005: Announcement Mar 2006: 0.1.0 Jul 2007: 1.0.0 Mar 2008: 1.5.0 Sep 2008: 1.6.0 Nov 2008: 1.7.0 Apr 2009: 1.8.0 Aug 2009: 1.9.0 Jan 2010: 1.10.0 Nov 2011: 1.11.0 Mobile support via Zend_Http_UserAgent. SimpleCloud API via Zend_Cloud.
file declares a namespace One namespace per file Any class used that is not in the current namespace (or a subnamespace) is imported and typically aliased
file declares a namespace One namespace per file Any class used that is not in the current namespace (or a subnamespace) is imported and typically aliased Global resolution is discouraged, except in the case of classes referenced in strings
namespace Zend\Mvc; use Zend\Stdlib\Dispatchable , Zend\Di\ServiceLocator as Locator; class FrontController implements Dispatchable { public function __construct(Locator $locator) { $this ->serviceLocator = $locator; } }
§ use Zend_Controller_Action as Controller; class FooController extends Controller {} // Later, this might become: use Zend\Controller\Action as Controller; class FooController extends Controller {}
What is the extension API for component “x”? Burgeoning feature requests == Maintenance nightmare The Solution Use PHP interfaces to mark the public API.
What is the extension API for component “x”? Burgeoning feature requests == Maintenance nightmare The Solution Use PHP interfaces to mark the public API. Limit the features in the core framework, and point developers to interfaces for custom features.
interface MailMessage { public function setTo($to); public function setSubject($subject); public function setHeaders(MailHeaders $headers); public function setBody($body); public function getTo(); public function getSubject(); public function getHeaders(); public function getBody(); }
All exceptions derived from a common class Inability to extend semantic exception types offered in the SPL The Solution Eliminate Zend_Exception Each component defines a marker Exception interface
All exceptions derived from a common class Inability to extend semantic exception types offered in the SPL The Solution Eliminate Zend_Exception Each component defines a marker Exception interface Concrete exceptions live in an Exception subnamespace, and extend SPL exceptions
No more require_once calls! Provide fallback autoloading for rapid application development Map namespaces to specific directories to increase performance
No more require_once calls! Provide fallback autoloading for rapid application development Map namespaces to specific directories to increase performance Use class maps when possible
No more require_once calls! Provide fallback autoloading for rapid application development Map namespaces to specific directories to increase performance Use class maps when possible Provide tools for generating class maps
/ 70 Yes, they will. But we already have a tool, bin/classmap_generator.php. Usage is trivial: § prompt > cd your/library prompt > php /path/to/classmap_generator.php -w # Class-Map now exists in .classmap.php
multiple strategies comes the need for a factory Choose several strategies Class-Map for fastest lookup Namespace/prefix paths for common code ZF1/PSR0-style fallback autoloader for development
Problem Varying approaches to dynamically discovering plugin classes Paths relative to the calling class Prefix-path stacks (most common) Setters to indicate classes
Problem Varying approaches to dynamically discovering plugin classes Paths relative to the calling class Prefix-path stacks (most common) Setters to indicate classes Most common approach is terrible
Problem Varying approaches to dynamically discovering plugin classes Paths relative to the calling class Prefix-path stacks (most common) Setters to indicate classes Most common approach is terrible Bad performance Hard to debug No caching of discovered plugins
do we introduce logging/debug points in framework code? How do we allow users to introduce caching without needing to extend framework code? How do we allow users to introduce validation, filtering, ACL checks, etc., without needing to extend framework code?
do we introduce logging/debug points in framework code? How do we allow users to introduce caching without needing to extend framework code? How do we allow users to introduce validation, filtering, ACL checks, etc., without needing to extend framework code? How do we allow users to manipulate the order in which plugins, intercepting filters, events, etc., trigger?
do we introduce logging/debug points in framework code? How do we allow users to introduce caching without needing to extend framework code? How do we allow users to introduce validation, filtering, ACL checks, etc., without needing to extend framework code? How do we allow users to manipulate the order in which plugins, intercepting filters, events, etc., trigger? How can we provide tools for userland code to benefit from the above?
Oriented Programming Code defines various “aspects” that may be interesting to observe and/or attach to from a consumer. Other code executes when the aspect is triggered.
EventManager Cherry-picks from each of PubSub, SignalSlot, and Intercepting Filters to provide a comprehensive solution. Prioritization of handlers Interrupting event propagation
EventManager Cherry-picks from each of PubSub, SignalSlot, and Intercepting Filters to provide a comprehensive solution. Prioritization of handlers Interrupting event propagation Aggregation and introspection of handler results
EventManager Cherry-picks from each of PubSub, SignalSlot, and Intercepting Filters to provide a comprehensive solution. Prioritization of handlers Interrupting event propagation Aggregation and introspection of handler results Static connection using named managers
namespace Zend\EventManager; use Zend\Stdlib\CallbackHandler; interface EventCollection { public function trigger($event , $context , $argv = array()); public function triggerUntil($event , $context , $argv , $callback); public function attach($event , $callback , $priority = 1); public function detach(CallbackHandler $handle); public function getEvents(); public function getHandlers($event); public function clearHandlers($event); }
use Zend\EventManager\EventManager; $events = new EventManager(); $events ->trigger($eventName , $object , $params); /* Where: * - $eventName is the name of the event; usually the current * method name * - $object is the object triggering the event * - $params are the parameters the handler might need to access, * usually the method arguments */
do controllers get dependencies? How do we accommodate different controller patterns? What if we want to fine-tune action selection after routing, based on other data in the request environment?
do controllers get dependencies? How do we accommodate different controller patterns? What if we want to fine-tune action selection after routing, based on other data in the request environment? What if we want to pass arguments to action names, or prevalidate arguments?
do controllers get dependencies? How do we accommodate different controller patterns? What if we want to fine-tune action selection after routing, based on other data in the request environment? What if we want to pass arguments to action names, or prevalidate arguments? What if we don’t like the “Action” suffix in action methods?
do controllers get dependencies? How do we accommodate different controller patterns? What if we want to fine-tune action selection after routing, based on other data in the request environment? What if we want to pass arguments to action names, or prevalidate arguments? What if we don’t like the “Action” suffix in action methods? What if . . . ?
do controllers get dependencies? How do we accommodate different controller patterns? What if we want to fine-tune action selection after routing, based on other data in the request environment? What if we want to pass arguments to action names, or prevalidate arguments? What if we don’t like the “Action” suffix in action methods? What if . . . ? How can we better use server components within the MVC?
do controllers get dependencies? How do we accommodate different controller patterns? What if we want to fine-tune action selection after routing, based on other data in the request environment? What if we want to pass arguments to action names, or prevalidate arguments? What if we don’t like the “Action” suffix in action methods? What if . . . ? How can we better use server components within the MVC? How can we make the MVC more performant?
Git guide: http://bit.ly/zf2gitguide GitHub: http://github.com/zendframework/zf2 Official repo: git://git.zendframework.com/zf.git http://git.zendframework.com/ You still need to sign a CLA!
Framework: http://framework.zend.com/ Feedback: http://joind.in/3407 My Twitter: http://twitter.com/weierophinney My Blog: http://weierophinney.net/matthew