Overview

One of PHP's misconceptions is that in order to write portable code, the DIRECTORY_SEPARATOR constant is needed for all folder paths. An example of this is in require's.

require_once(MY_PATH . DIRECTORY_SEPARATOR . 'foo' . DIRECTORY_SEPARATOR . 'my.php');

The alternative

PHP is smart enough to handle all paths that use a forward slash '/' on all platforms (that means windows). Using a forward slash instead of the directory separator constant where possible will make your code more readable. Zend Framework uses this method on all of its require's.

/**
 * @see Zend_Controller_Front
 */
require_once('Zend/Controller/Front.php');

After running a few tests and speaking to several people, it seems that it is perfectly fine to take this alternative. For most code, as long as you are using the forward slash '/' not the windows back slash '\' portability is guaranteed.

Why have a constant? 

The constant is particularly useful because paths given by php use the native system's directory separator. The constant is particularly useful if you need to do some path mangling or exploding etc..

That's all 

While I am just giving out my opinion here as I find that the DIRECTORY_SEPARATOR use can go out of hand, it is up to you to decide. Please provide feedback on what you think ;).

References

• http://old.alanhogan.com/tips/php/directory-separator-not-necessary
• http://us2.php.net/manual/en/ref.filesystem.php#73954 

Whoo!

With the release of Zend Framework 1.5PR, the feel of the framework moving forward starts to come back. Some things to look for in this release are Zend_Form, Zend_Db and Zend_Layout as they play an important role in the framework. This release should be completely backwards compatible for those who wanted to know. (I mean to say that 1.5 should be backwards compatiable with the 1.0.x seriers).

Listed below are some additional features posted by Wil Sinclair :

• Zend_Auth_Adapter_Ldap
• Zend_Build/Zend_Console
• Zend_Controller additional action helpers
• ContextSwitch and AjaxContext
• Json
• AutoComplete
• Zend_Form
• Zend_InfoCard
• Zend_Layout
• Zend_OpenId
• Zend_Search_Lucene improvements:
• wildcard search
• date range search
• fuzzy search
• Lucene 2.1 index file format support
• Zend_View enhancements:
• actions
• partials
• placeholders
• Zend_Pdf UTF8 support
• New Zend_Service consumables (final list TBD)
• A whole lotta bug fixes and documentation improvements

Note for Naneau : It's been 4 months since you've posted... :(

Overview

There have been quite a lot of requests about how to extend Zend_Controller_Action in #zftalk lately, so I figured I'd post something to reference to. So what's so hard about extending Zend_Controller_Action? Nothing, it is just that for some odd reason people resort to overriding init() or calling parent::init() (I assume your too lazy to open up Action.php to grab the __construct() params ;) ). Basically the benefit of doing it the correct way allows you to use init() in your extended controller without calling parent::*. Yes, I am that lazy...

Library Directory Structure

One of the other things people have asked about when creating custom classes for ZF that are reusable is where to put them. While they can be put anywhere and there is not a specified convention, I usually put them in my own namespace in a directory layout similar to Zend Framework. It is also simpler because extended classes mirror the ZF structure which make it easier for other developers to find.

• libraries/
• Zend/
• Controller/
• Action.php
• SpotSec/
• Controller/
• Action.php
  

The Code

require_once('Zend/Controller/Action.php');
// Stored in libraries/[Zend, SpotSec]/Controller/Action.php just for those who are wondering
abstract class SpotSec_Controller_Action extends Zend_Controller_Action
{
    /**
     * Class constructor
     *
     * The request and response objects should be registered with the
     * controller, as should be any additional optional arguments; these will be
     * available via {@link getRequest()}, {@link getResponse()}, and
     * {@link getInvokeArgs()}, respectively.
     *
     * When overriding the constructor, please consider this usage as a best
     * practice and ensure that each is registered appropriately; the easiest
     * way to do so is to simply call parent::__construct($request, $response,
     * $invokeArgs).
     *
     * After the request, response, and invokeArgs are set, the
     * {@link $_helper helper broker} is initialized.
     *
     * Finally, {@link init()} is called as the final action of
     * instantiation, and may be safely overridden to perform initialization
     * tasks; as a general rule, override {@link init()} instead of the
     * constructor to customize an action controller's instantiation.
     *
     * @param Zend_Controller_Request_Abstract $request
     * @param Zend_Controller_Response_Abstract $response
     * @param array $invokeArgs Any additional invocation arguments
     * @return void
     */
    public function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array())
    {
        // Your stuff here to run before init()
        // Note: $this->getRequest, $this->getResponse() and $this->getInvokeArgs() (also action helpers) 
        // are not available until after the construct is run, but you can use $request, $response and $invokeArgs.
        parent::__construct($request, $response, $invokeArgs);
        // Your stuff below here... to run after init(), but before self::preDispatch()
    }
}

Done!

Simple eh? and all you had to really do is open up Action.php to read or the API docs to find out how (but I assumed you googled.... cheater).