John Coggeshall

Hi! I’m John!

• Involved in PHP since circa 1996

• Sr. Architect, Zend Global Services

• PHP Core Contributor

•ZF Contributor

Getting Started

The easiest way to get started in ZF2 is to start with the skeleton application:

https://github.com/zendframework/zendskeletonapplication

$ composer create-project \

-sdev \

-repository-url=“https://packages.zendframework.com” \

zendframework/skeleton-application \

/path/to/install

ZF2 Modules

In ZF2 modules are a core concept when developing applications. Everything including the application is a module.

Modules can be application-specific or can be written generically and then loaded into the application via composer

How are modules structured?

How do Modules work?

Every ZF2 module starts with a Module class which describes the module and the things it provides to the application

Services

Event Handlers

Controllers

Routes

Etc.

How do Modules work?

Modules also have their own configuration files which can setup default values that are later over-written by the application’s configurations.

Useful for creating module-specific routes, or module-specific configurations, etc.

config/module.config.php

How do Modules work?

The module class can implement a number of useful methods

getAutoLoaderConfig() – configure the way classes are autoloaded through this module

getServiceConfig() – set up the way services this module provides can be created and accessed

getModuleDependencies() – Define module dependencies

onBootstrap() – Executed when module is fired up

Service Manager

ZF2 applications in general rely heavily on something called the Service Manager to deal with application dependencies

Examples: The DB adapter used by the application is created by the Service Manager

Service Manager

Implementing dependencies and components as services allows modules to be completely decoupled from each other

Services are identified by unique ID, which is referenced when the service is required

Customization (i.e. a different DB adapter) can be done simply by over-writing the factory associated with that unique ID

Service Manager

In a module services can be defined in various locations

module.config.php (the ‘service_manager’ key)

Module::getServiceConfig() (the programaticapproach)

Service Manager

How services can be defined

By factory – identify the key to either a class that implements a Factory interface or other callable which returns the instance

By invokable – Simply identify the class associated with this service

Aliases – Services can have an alias for complicated dependency scenarios

Using Events

All events are managed through the event manager class(es)

Can be automatically injected into your objects via the Service Locator

Implement the EventManagerAwareInterface

Event Managers

The ZF2 Event manager is the primary way modules should communicate with each other

Optionally, also internally

Broadcast Events for others to react to

I.e. “Dispatch”

ZF2 Baked in Events

ZF2 uses events throughout its core functionality

Module Manager

Application

Bootstrap, etc.

MVC Events

Routing

Dispatching

Rendering

http://akrabat.com/zend-framework-2/a-list-of-zf2-events/

Event Scoping

Events are by default scoped to the local object

Each Event Manger is by default unique to that object

If you want to have events of a different scope you have a few options

Provide a way to get your event manager

Use the more global SharedEventManager

Summary

This is a very surface-level exploration into the complex possibilities of ZF2 modules and events, but enough to get started.

Get to know Service Manager and Event Manager very well and they will serve you fantastically, allowing you to write powerful reusable components

Any questions?

Tell me what you think: http://joind.in/11875

Slides will be available at http://www.slideshare.net/coogle