Willing wheels

(apply to ZF v1.10)

You have two types of resources:

- class resources (those methods that you define in your Bootstrap class and that starts with ‘_init’)
- plugin resources (those that you define externally and can trigger via application.ini file)

How do you automatically load an external resource from application.ini file?
This is pretty simple indeed. You only have to declare your resource in your config file as follow: “resource.<resource_name> = true”
note: we added ” = true” because otherwise our line would have been ignored since no value was defined to our <resource_name> variable. In next section, we will add some parameters therefore making explicit use of ” = true” useless.

How do you provide options to  your own external plugin resource?
Anything that will come after ‘resources.<resource_name>’ in your application.ini file will be considered an option and provided to your external resource upon instanciation.
If I write

resources.myplugin.option1 = 1
resources.myplugin.option2 = 2

Then ‘myplugin’ is automatically registered and will be instanciated with following options array ['option1' => 1, 'option2' => 2, 'bootstrap' => Object]
note: ‘bootstrap’ entry is automatically created by ZF (Zend_Application_Bootstrap_BootstrapAbstract) and therefore available to all plugins. It contains an instance of the bootstrap object.

Example:

in my application.ini, I have:

resources.db.adapter = “PDO_MYSQL”
resources.db.params.host = “localhost”
resources.db.params.username = “user”
resources.db.params.password = “pwd”
resources.db.params.dbname = “mydb”

Then what’s going to happen is:

• Zend_Application_Resource_Db plugin will automatically get registered and bootstrapped
• Options passed to Db plugin upon instanciation is an array:

  [
  'adapter' => 'PDO_MYSQL',
  'params' => [
    'host' => 'localhost',
    'username' => 'user',
    'password' => 'pwd',
    'dbname' => 'mydb'],
  'bootstrap' => Object
  ]

  note: for bootstrap entry, see above comment

How do you use Router resource?

ZF online documentation still contains example for old routing (ie. as it was performed prior to introduction of Zend_Application and external resources). Now it’s better to call external resource plugin rather than configure your Zend_Controller_Front as done previously.

To do this, it’s pretty simple. You can rely on examples provided in online documentation (http://framework.zend.com/manual/en/zend.controller.router.html), the only change that you have to do is to prefix all ‘routes’ entry in your application.ini file with ‘resources.router.’.

Thus,

routes.login.type = “Zend_Controller_Router_Route_Static”
routes.login.route = “login”
routes.login.defaults.controller = auth
routes.login.defaults.action = login

becomes

resources.router.routes.login.type = “Zend_Controller_Router_Route_Static”
resources.router.routes.login.route = “login”
resources.router.routes.login.defaults.controller = auth
resources.router.routes.login.defaults.action = login

That’s it. You don’t have to worry about anything else, a router instance is automatically created and your routes should be active now.

How do you use Log resource via .ini configuration?

In my case, I defined it this way:
resources.log.stream.writerName = “Stream”
resources.log.stream.writerParams.stream = APPLICATION_PATH “/../logs/app.log”
resources.log.stream.filterName = “Priority”
resources.log.stream.filterParams.priority = Zend_Log::WARN

Where can you access all instances used by external resource plugins?
Db plugin instanciates a Zend_Db_Adapter object, Log plugin instanciates a Zend_Log object, and so on…
Everytime a ->init() method of a resource plugin returns a value, this value is store in a container currently being a Zend_Registry instance (but not singleton).
As a consequence, once Db resource has been bootstrapped, you can access create db adapter instance in $bootstrap->getResource(‘db’); (and $boostrap->getResource(‘log’) for Log instance!)

How do you write your own external plugins?

1. create your class extending Zend_Application_Resource_ResourceAbstract
2. ensure your class implement ->init() method, which should perform all your bootstrapping and might return an instance to a shared object
3. declare your plugin prefix and plugin path into application.ini:

   pluginPaths.My_Plugin_Prefix = APPLICATION_PATH "/path/to/my/resource/plugin/directory"

4. call your plugin resource from application.ini:

   resources.myResource = true

   note: you can add parameters to this call (as explained above) that will be available in your resource plugin class via ->getOptions() method

Warning

• execution order: by default, class resources get executed first
• name overlapping: if your class resource has the same name as your external plugin resources, only your class resource will get executed
  example: in my Boostrap class, I have a method name ::_initDb() and in my application.ini file I initialize external Db resource (via ‘resources.db.xxx’ call), only my _initDb() will get executed. External plugin will simply be ignored
  => make sure you do NOT use the same name for your class resources and external plugin resources

sources

• http://framework.zend.com/manual/en/zend.application.html
• http://blog.madarco.net/327/how-to-make-your-own-zend-framework-resource-plugin/

When using Zend_Rest_Client & Zend_Rest_Server with ZF v1.10.2, to quickly build a Rest webservice, performing simple restDelete() queries ended up with following error message:

Unexpected error: No Method Specified

In fact, current implementation of Zend_Rest_Client::restDelete() does not provide any request parameter to queried url.
On server side, Zend_Rest_Server expects the ‘method’ argument to be provided => above error is generated.

To avoid this problem, I had to update Zend_Rest_Client with following updated method:

/**
* Performs an HTTP DELETE request to $path.
*
* @param string $path
* @param array $query Array of GET parameters
* @throws Zend_Http_Client_Exception
* @return Zend_Http_Response
*/
final public function restDelete($path, $query = null)
{
$this->_prepareRest($path);
$client = self::getHttpClient();
$client->setParameterGet($query);
return $client->request('DELETE');
}

note: subclassing the class was not an option since most of its methods are ‘final’! Grrrr…

For more information, look at corresponding tickets (see links below)

sources

• http://framework.zend.com/issues/browse/ZF-9316
• http://framework.zend.com/issues/browse/ZF-9317
• http://framework.zend.com/issues/browse/ZF-9318