#zendframework2

Module Manager di Zend Framework 2 adalah cara yang ampuh untuk membuat kode program yang re-usable yang dapat digunakan kembali di project yang lain dengan mudah.

Di Zend Framework 2, Module adalah sebuah group dari kode program yang biasanya ditujukan untuk menghandle bagian tertentu dari sebuah aplikasi. Module ini bisa berisi Service, Konfigurasi, Controller dan View Script. Karena Module ini bisa berisi konfigurasi, maka Module juga bisa digunakan untuk membuat Route, memuat Service ke dalam Service Manager dan memasang Listener untuk sebuah Event.

Module Manager

Module Manager adalah salah satu komponen yang sangat penting dalam Zend Framework 2 yang berfungsi untuk memuat Module yang sudah didaftarkan, dan men-trigger event - event yang ada di dalam Module . Seringnya developer tidak menggunakan Module Manager ini secara langsung. Untuk itu di sini saya membahas bagaimana sebenarnya sebuah Module bisa dimuat pada Zend Framework 2.

Zend\ModuleManager\ModuleManager adalah implementasi dari Zend\ModuleManager\Interface yang bertanggung jawab untuk memuat module dan membuat Namespace dari Module tersebut bisa digunakan di dalam aplikasi. Module Manager menggunakan array sebagai konfigurasi, yang kemudian dijadikan parameter untuk Constructor. Konfigurasi bisa berisi daftar Module yang akan dimuat, lokasi dari Module, dan lokasi dari konfigurasi file Autoload.

$moduleManager = new ModuleManager([     'modules' => [          'Application',          'Blog',          'Catalog',          'Cart',          'Checkout',     ],     'module_listener_options' => [          'module_paths' => [               'config/autoload/{,*.}{global,local}.php',          ]

    ] ]); $moduleManager->loadModules();

Atau biasanya dibuat sebagai konfigurasi di file config/application.config.php yang akan dimasukkan ke dalam Module Manager sewaktu instansiasi.

Class Module.php

Syarat minimal dari sebuah Module di Zend Framework 2 adalah harus memiliki sebuah file yang diberi nama Module.php. Module.php ini adalah Class yang sangat simpel yang hanya cukup diberi nama Module yang diletakkan di dalam Namespace Module tersebut. Di dalamnya kita bisa membuat array yang mendefenisikan konfigurasi dari module (method getConfig()) dan lokasi dari Class yang digunakan sebagai Autoloaded pada Module ini (method getAutoloaderConfig()).

Dan ketika module dimuat maka yang pertama kali dipanggil adalah method onBootstrap(). Ini merupakan method yang cukup ampuh dan kita bisa menggunakannya untuk memasang Listener dari Event. Ataupun mendefenisikan Routing yang baru dan menambahkan kode yang akan diproses pada setiap request.

Sedangkan method init() dipanggil sebelum Module di-bootstrap, dan bisa digunakan untuk membuat konfigurasi yang dibutuhkan Module tersebut sewaktu proses Bootstrap.

<?php namespace Order;

class Module { }

Zend Framework 2 menyediakan beberapa Interface yang bisa digunakan oleh Class Module yang di dalamnya tersedia fitur - fitur yang bisa digunakan oleh Module tersebut. Interface tersebut mendeskripsikan method - method yang diimplementasikan, walaupun begitu Interface tersebut tidak perlu sepenuhnya diimplementasikan (cukup menuliskan nama Method saja).

Penggabungan Konfigurasi

Konfigurasi dapat diletakkan di beberapa tempat, namun semua konfigurasi itu digabunggakn secara rekursif ke dalam sebuah konfigurasi oleh Zend\Stdlib\ArrayUtils::merge(). Karena konfigurasi digabungkan secara rekursif, urutan penggabungan konfigurasi tersebut harus dipahami untuk menghindari overwriting yang tidak diinginkan.

Konfigurasi digabungkan dengan urutan berikut ini.

Array yang dikembalikan oleh method getConfig() yang ada pada Class Module

config/autoload/global.*.php File Autoload Global

config/autoload/local.*.php  File Autoload Lokal

Method - method yang dideskripsikan di dalam Interface yang sudah disediakan get*Config()

Ketika point A - C selesai, maka konfigurasi gabungan yang belum sempurna ini dapat di-cache oleh Module Manager. Jadi, jika ingin menggunakan konfigurasi menggunakan Closure, seharusnya diletakkan di method - method (point D) konfigurasi kustom, bukan di method getConfig() (point A).

Event di Dalam Module

Agar membuat Module se-fleksibel mungkin, ModuleManager men-trigger sejumlah Event selama proses memuat Module. Pada awalnya, event loadModules di-trigger, kemudian event - event lainnya. Sejumlah event tersebut di-trigger setiap Module dimuat. Adapun urutan dari event - event tersebut

loadModules             (ModuleEvent::EVENT_LOAD_MODULES)

loadModule.resolve (ModuleEvent::EVENT_LOAD_MODULE_RESOLVE)

loadModule               (ModuleEvent::EVENT_LOAD_MODULE)

mergeConfig             (ModuleEvent::EVENT_MERGE_CONFIG)

loadModules.post     (ModuleEvent::EVENT_LOAD_MODULES_POST)

Untuk lebih detail dari tujuan event - event tersebut di atas, bisa melihat dokumentasi Zend Framework di sini 

Referensi:

Zend Framework 2 Certification Study Guide

Event Manager sangat banyak sekali digunakan di dalam Zend Framework 2 (karena itu Zend Framework dapat dikatakan Event-Driven Framework). Dengan begitu sangat bertentangan dengan Zend Framework 1. Di sini sebagian besar element MVC (routing, dispatching, view) tidak dipanggil satu demi satu, melainkan Framework men-trigger Event (dispatch, route, dll). Link yang saya share di sini, sudah yang sangat lengkap membahas Event Manager di Zend Framework 2 dan juga memberikan contoh yang sangat mudah dipahami.

Mengapa Menggunakan Event Manager

Service Manager di Zend Framework 2 digunakan untuk menemukan dan mendapatkan instansi dari sebuah service (class), termasuk juga memenuhi segala dependensi yang dibutuhkan dari sebuah service.

Zend Framework 2 menggunakan Service Manager sebagai kerangka dari framework, dengan Service Manager khusus yang digunakan untuk menemukan service - service tertentu, seperti:

Controllers

Plugins

View Helpers

Input Filters

Validators

Form Elements

Hydrators

Application Service

Service Locators

Service Locator design pattern menggambarkan sebuah method dari dari sebuah abstraction layer. Service Managers di Zend Framework 2, merupakan implementasi dari ServiceLocatorInterface interface yang memberikan dua method, yaitu has() untuk menentukan apakah sebuah service sudah didaftarkan di dalam Service Manager, dan get() untuk mengembalikan sebuah instansi dari service tersebut.

Plugin Manager

Banyak sekali implementasi dari ServiceLocatorInterface yang mempunyai tugas dengan letak yang berbeda dan plugin yang berbeda pula.

Abstract Plugin Manager

AbstractPluginManager adalah sebuah implementasi Service Manager untuk mengatur plugins. Abstract class memberikan method untuk mendefenisikan dan memanggil plugin, selama service tersebut dibuat melalui class invokable, factories, dan object yang dapat dipanggil seperti closure.

Controller Manager

Zend\Mvc\Controller\ControllerManager meng-extend AbstractPluginManager, dan juga merupakan Plugin Manager yang mencari dan memanggil Controller class. Ini digunakan pada internal MVC Router untuk menentukan dan memanggil berdasarkan route url yang sesuai. ControllerManager ini memang sengaja dibuat terpisah untuk alasan kecepatan dan keamanan. Karena jika digabung bersama plugin manager yang lainnya, sangat mudah untuk melakukan dispatch terhadap controller dengan membuat route url untuk mengakses service tertentu yang sebenarnya tidak ditujukan untuk menjadi controller.

Plugin Manager Lainnya

Ada beberapa kelompok Plugin Manager lainnya yang ditugaskan untuk membuat dan memanggil service dan plugin tertentu. Plugin - Plugin Manager tersebut juga meng-extend AbstractPluginManager.

ControllerPluginManager membuat dan memanggil controller plugin

ViewHelperPluginManager membuat dan memanggil view helper

InputFilterPluginManager membuat dan memanggil input filter

FilterPluginManager membuat dan memanggil filter

ValidatorPluginManager membuat dan memanggil validator

FormElementManager membuat dan memanggil form element

HydratorPluginManager membuat dan memanggil hydrator

Plugin - Plugin Manager ini akan menggunakan validatePlugin() untuk memastikan bahwa plugin - plugin yang terdapat dalam kelompok Plugin Manager tersebut sesuai dengan kriteria yang sudah ditentukan oleh Plugin Manager-nya.

Shared Service Manager

Meskipun Plugin Manager sudah dikelompokkan, tidak tertutup kemungkinan juga bagi kita membutuhkan service lainnya yang berada di luar kelompok Plugin Manager tersebut. Maka dari itu dibuatlah Shared Service Manager. Zend\ServiceManager\ServiceManager adalah implementasi dari ServiceLocatorInterface yang digunakan untuk Custom Service. Yang biasanya digunakan unutk menyimpan Service yang dibuat oleh developer. Shared Service Manager ini bisa didapatkan dari getServiceLocator() yang ada pada AbstractPluginManager().

Perlu diingat, "Service Manager" yang dibahas di sini merujuk kepada Service Manager dan juga Plugin Manager

Configuration

Service Manager dan Plugin Manager keduanya dapat dikonfigurasi dengan menggunakan Class yang merupakan implement dari Zend\ServiceManager\ConfigInterface sebagai parameter di constructor. Zend\ServiceManager\Config adalah salah satu bentuk implementasi yang sudah built-in dari Zend Framework 2, yang bisa digunakan untuk mengkonfigurasi Service Manager.

Sedangkan Zend\ServiceManager\Config menggunakan array sebagai constructor parameter. Dan menggunakan array tersebut untuk mengkonfigurasi Service Manager dengan factories, abstract factories, invokables, services, aliases dan initializers. Array tersebut dalam bentuk "key-value pairs", yang mana "key" adalah nama unik dari Service sebagai tanda pengenal Service, dan "value" akan mengembalikan sebuah Service.

Untuk diketahui, nama unik dari Service akan dinormalisasi. Spasi dan karakter - karakter khusus akan dihapus, dan karakter yang tersisa akan diubah ke "huruf kecil". Jadi "user-service" akan sama dengan "User\Service" yang akan dinormalisasi menjadi "userservice".

Invokables Cara yang paling simple untuk membuat service melalui Service Manager adalah dengan menggunakan Invokable. Hanya berisi sebuah Class yang dapat menghasilkan object (instantiasi) tanpa menggunakan dependensi (ataupun dengan dependensi yang bisa dihandle oleh initializer). Untuk mendefenisikannya, gunakan "invokables" key pada array konfigurasi yang digunakan sebagai parameter Zend\ServiceManager\Config object

$config = new Config([    'invokables' => [        'hydrator' => 'Zend\Stdlib\Hydrator\ClassMethods'     ] ]);

Maka untuk memanggil Service "hydrator" menggunakan Service Manager, bisa langsung seperti ini

$serviceManager = new ServiceManager($config); $serviceManager->get('hydrator');

Factories Factories merupakan sebuah Class ataupun Closure/Anonymous Function yang dapat mengembalikan sebuah object yang sudah dikonfigurasi pada saat Service tersebut dipanggil. Untuk penggunaan Class, harus meng-implement FactoryInterface. Kemudian Service dikonfigurasi di dalam method "createService()".

Closure dan Class keduanya akan menggunakan Service Manager object sebagai parameter. Ini ditujukan agar factory dapat memenuhi dependensi dari Service yang akan dikonfigurasi dengan memanggil dependensi tersebut dengan menggunakan Service Manager ataupun Shared Service Manager (menggunakan getServiceLocator())

Factories didefenisikan menggunakan "factories" key

$config = new Config([        'factories' => [             'mailTransport' => 'Aqilix\User\Factory\MailTransport',             'user' => function (ServiceLocatorInterface $serviceManager) {                  $service = $serviceManager->get('UserService');                  $user = new User($service); // $service digunakan sebagai dependency                  return $user;             }         ] ]);

Contoh Class yang digunakan sebagai factory

Ketika service diakses melalui Service Manager, maka service tersebut sudah berisi dependencies yang dibutuhkan.

$serviceManager = new ServiceManager($config); $serviceManager->get('mailTransport');

Abstract Factories Abstract Factories adalah factories yang dapat digunakan untuk membuat multiple services. Abstract Factories dibuat dengan sebuah Class yang meng-implement AbstractFactoryInterface. AbstractFactoryInterface mempunyai dua method yaitu canCreateServiceWithName() dan createServiceWithName().

Abstract Factories dipanggil setelah "factories" dan "invokables". Ketika sebuah service tidak ditemukan pada factories atau invokable, maka kemudian service manager akan mencek canCreateServiceWithName() method. Jika method tersebut mengembalikan true, maka service tersebut akan dipanggil melalui createServiceWithName() method. Berikut contoh sebuah class Abstract Factory

Kemudian Abstract Factory ini didefenisikan dengan menggunakan key "abstract_factories"

$config = new Config([     'abstract_factories' => [          'Aqilix\Common\Session\Service\AbstractContainerFactory'     ] ]);

Class Abstract Factory di atas ditujukan untuk membuat Session Container baru yang bisa diakses melalui Service Manager. Untuk mengaksesnya dengan cara berikut ini:

$serviceManager = new ServiceManager($config); $serviceManager->get('aqilix.common.session.container.user'); // Membuat Session Container User

Aliases Aliases digunakan sebagai aliasing sebuah service yang sudah didefenisikan sebelumnya. Aliases didefenisikan dengan menggunakan key "aliases"

$config = new Config([    'aliases' => [         'user' => 'UserService'     ] ]);

Memanggil user service melalui Service Manager

$serviceManager = new ServiceManager($config); $serviceManager->get('user');

Initializers Initializers digunakan untuk menjalankan inisialisasi tambahan setelah service dibuat. Service yang baru dibuat tersebut diberikan ke seluruh Initializers. Ini sangat berguna untuk menemukan dependensi menggunakan "setter injection". Initializers melakukan pengecekan dengan menggunakan "Aware" interface untuk memastikan bahwa service menemukan dependensi yang tepat.

Initializers didefenisikan menggunakan “initializers” key, dan memiliki value yang bisa berupa Closure ataupun "Class" yang meng-implement "InitializerInterface". Dan proses initialize tersebut ada pada method "initialize()". Berikut ini contoh Class yang digunakan sebagai initializer

Setter pada class berikut ini akan dipanggil oleh Initializer

interface UserServiceAwareInterface {      public function setUserService(UserService $userService); }

interface DbAdapterAwareInterface {     public function setDbAdapter(DbAdapterInterface $dbAdapter); }

Konfigurasi Initializer yang akan digunakan oleh Service Manager

$config = new Config([      'initializers' => [           'Aqilix\User\Initializer\Db',           'userService' => function ($service, ServiceLocatorInterface $serviceManager) {                if ($service instanceof UserServiceAwareInterface) {                     $userService = $serviceManager->get('UserService);                     $service->setUserService($userService);                }           }       ] ]);

Dengan defenisi di atas, maka semua Service yang meng-implement UserServiceAwareInterface akan mempunyai UserService karena sudah diset melalui Initializers. Begitu juga dengan Service yang mengimplement DbAdapterAwareInterface  

Shared Service Shared Service berbeda dengan Shared Service Manager yang dibahas sebelumnya. Yang dimaksud dengan Shared Service di sini adalah tentang sebuah Service akan menggunakan object yang sama setiap kali dipanggil. Secara default, semua Service adalah shared.

Dalam artian Service Manager akan memberikan object yang sama dari sebuah Service ketika Service tersebut dipanggil melalui Service Manager. Namun adakalanya kita menginginkan sebuah Service, yang ketika dipanggil melalui Service Manager dia akan membuat object yang baru.

Untuk kebutuhan object seperti ini, maka harus didefnisikan di konfigurasi Service Manager dengan "shared" key.

'service_manager' => array(       'factories' => array(            'crypto' => 'Aqilix\User\Crypto\Service\Factory'        ),        'shared' => array(            'crypto' => false,        ), );

Maka setiap kali Service crypto dipanggil, akan membuat object yang baru

$serviceManager = new ServiceManager($config); $crypto         = $serviceManager->get(’crypto’); $newCrypto  = $serviceManager->get(’crypto’); assert($crypto !== $newCrypto, 'Each crypto object should not be same’);

Tips

Pada contoh - contoh di atas kita sudah menggunakan Class dan  Closure/Anonymous function untuk membuat sebuah Service. Tapi perlu diingat, penggunaan Closure hanya ditujukan untuk mempercepat development dan pengujian dari konsep sebuah aplikasi. Jangan pernah gunakan Closure untuk kode rilis, karena akan menimbulkan beberapa masalah di antaranya:

Cache konfigurasi akan rusak. Karena PHP tidak bisa men-serialize dan men-deserialize Closure. Oleh karena itu, jika ke depannya kita ingin melakukan cache untuk konfigurasi, maka cache ini tidak bisa bekerja.

Autoloading tidak akan bekerja seperti yang diharapkan. Kode yang ada pada Closure bisa jadi bergantung pada Class yang ada pada Modul berikutnya. Ini berarti Class tersebut belum diproses Autoloader, dan kode di Closure akan berhenti. Bahkan lebih buruk lagi, Autoloading dari Modul berikutnya bisa jadi meng-override autoloading dari Class di Modul sekarang. Sedangkan Aplikasi mengharapkan Class yang di-override, tapi yang terjadi yang diproses adalah Class sekarang yang belum di-override. Tentu saja ini akan memicu masalah baru yang akan sulit ditelusuri.

Performa akan menurun

Ketika sebuah Service didefenisikan menggunakan Closure pada file konfigurasi, maka PHP akan memakan waktu untuk mengevaluasinya. Jika ada Modul lain yang meng-overwrite Service tersebut maka waktu yang sudah dihabiskan tersebut akan terbuang percuma. Oleh sebab itu, pikirkan kembali jika ingin menggunakan Closure.

Sampai saat ini, banyak source code Zend Framework 2 beredar di Internet yang menggunakan Closure.

Berikut ini contoh konfigurasi Service Manager pada aplikasi Zend Framework 2

Referensi:

Zend Framework 2 Learn By Example, Slavey Karadzhov

If you've been struggling with Zend Framework 2 Translations, specifically trying to work out how to translate form labels and flash messages using poedit then I might have an answer (I'm still optimistic there is a better way but I am all Googled out!).

In short the problem is that poedit is excellent at finding fixed strings for translation. i.e. in your view using $this->translate('My String'); works a treat. Poedit automatically finds these translations.

The Zend Framework 2 docs brag about automatic translation in form labels etc. As far as I can see poedit can't handle this and you shouldn't manually add strings to a poedit file?