I wanted to get both PHP 5.2 and PHP 5.3 installed on my MacBook Pro for development. Since Zend Server CE offers both of them conveniently package, this was a start, however by default you can only install and use one. The instructions below are for installing both however you can only one run one version at a time. This is perfect for my own purpose as I wanted to switch between php versions when necessary. In addition by using this method, Zend Server will not automatically start up on boot, but this is primary due to my own goals (I will include additional instructions for how to keep automatic boot also).

How this will work

The ending goal is to do have this:

Zend Server CE PHP 5.2 installed at /usr/local/zend-5.2.

Zend Server CE PHP 5.3 installed at /usr/local/zend-5.3.

//symbolic link
/usr/local/zend pointing to either /usr/local/zend-5.2 or /usr/local/zend-5.3.

The idea is to contain each installation completely so we can switch by making a simple symbolic link at /usr/local/zend. Many components of Zend Server is pointed at the base path /usr/local/zend so the easiest way is to keep this path working to avoid problems.

Installation

If you have one version of Zend Server CE already installed you will have to jump to the appropriate section and alter as needed. This installation guide will assume you have not installed Zend Server CE.

Install Zend Server CE PHP 5.2

1. Install normally. The installation package will install to /usr/local/zend.

2. Zend installs a start up include file at /etc/zce.rc. We need to copy this to the current 5.2 installation path. Were going to move the current /etc/zce.rc file inside to /usr/local/zend/etc/zce.rc to localize it to that installation path and the 5.2 version.

sudo mv /etc/zce.rc /usr/local/zend/etc/

3. Move /usr/local/zend to /usr/local/zend-5.2.

sudo mv /usr/local/zend /usr/local/zend-5.2

We are now finished with installing Zend Server CE PHP 5.2.

Install Zend Server CE PHP 5.3
(These steps are literally a copy of the above steps except this is for the 5.3 specific directory)

1. Install normally. The installation package will install to /usr/local/zend.

2. Zend installs a start up include file at /etc/zce.rc. We need to copy this to the current 5.3 installation path. Were going to move the /etc/zce.rc file inside to /usr/local/zend/etc/zce.rc to localize it to that installation path.

sudo mv /etc/zce.rc /usr/local/zend/etc/

3. Move /usr/local/zend to /usr/local/zend-5.3.

sudo mv /usr/local/zend /usr/local/zend-5.3

We are now finished with installing Zend Server CE PHP 5.3.

Finishing

1. At this time /usr/local/zend directory still does not exist. Let’s create it by adding the symbolic link to point it to the version we want.

Switch to 5.2

sudo ln -s /usr/local/zend-5.2 /usr/local/zend

Switch to 5.3

sudo ln -s /usr/local/zend-5.3 /usr/local/zend

2. If you remember from above there was a start up include file at /etc/zce.rc. We need to add this back. We will add a symbolic link to point /etc/zce.rc to /usr/local/zend/etc/zce.rc.

sudo ln -s /usr/local/zend/etc/zce.rc /etc/zce.rc

Note the awesomeness here. The zce.rc file is now pointing to the appropriate PHP version installation path now as we have a symbolic link for the main /usr/local/zend directory pointing to the specific version already!

3. I do not like Zend Server starting up at boot so I am going to remove the start up scripts at /Library/StartupItems/ZendServer_init. Note you can skip this step if you do want to leave the automatic boot feature on. At this current time of writing the start up scripts are the same for both PHP 5.2 and PHP 5.3, but that may change in the future.

sudo rm -rf /Library/StartupItems/ZendServer_init

You are now done with the installation!

How to start /stop / switch Zend Server CE

Starting Zend Server CE

sudo /usr/local/zend/bin/zendctl.sh start

Stopping Zend Server CE

sudo /usr/local/zend/bin/zendctl.sh stop

Restarting Zend Server CE

sudo /usr/local/zend/bin/zendctl.sh restart

Switching between Zend Server CE 5.2 & 5.3

1. If a current Zend Server instance has started already, STOP it first! Very important!

sudo /usr/local/zend/bin/zendctl.sh stop

2. Remove the current /usr/local/zend link.

sudo rm /usr/local/zend

3. Add the link back on and point to the version you want.

Switch to 5.2

sudo ln -s /usr/local/zend-5.2 /usr/local/zend

Switch to 5.3

sudo ln -s /usr/local/zend-5.3 /usr/local/zend

4. Start Zend Server again

sudo /usr/local/zend/bin/zendctl.sh start

Other Considerations

* I wrote this guide with Zend Server CE 4.0.6. I can’t guarantee for future or past versions.

* Make sure you always work with the /usr/local/zend path only and never to the specific /usr/local/zend. e.g. /usr/local/zend/bin/pear

* It has been working for me great so far with no issues including PEAR, but may not be so smooth for you. Use at your own risk! Backup! Backup! Backup!

Final Words

Please let me know if this guide was helpful to you or not. Let me know if there are any issues / errors with this guide in the comments. Have Fun!

I think it is obvious the issue at hand. I am suprisised to see the lack of attention this “weakness” of an HTML / Javascript Air application has. I am thinking more in terms of commercial applications. What happens if you have some activation code for your application? It looks like someone can remove it fairly easily…

In addition all your neat source code is 100% out in the open. I know nothing is 100% and in many other scenarios the source code can be decompiled…etc, but there is no attempt at all here and is pretty bad if I can edit the application instantly. Very cool for open source applications, WTF for commercial ones.

This component was originally proposed by Luke Crouch, but has been somewhat idle for a while. I’ve talked to Luke about helping out and have contacted Matthew Weier O’Phinney for approval of my addition. I have gotten thumbs up from both parties! I will be re-proposing the Zend_Service_Digg component to support the full Digg API and will put it back up for community review soon!

Proposal Link

Zend_Entity & Zend_Db_Mapper

I will be trying my best to help out on this proposal. It is already in heavy and deep development by Benjamin Eberlei. I am trying to pick up as much as possible and will be diverting the majority of my attention here as I would really like to see this to be released. I am starting out a bit slow, but am aiming to knock out some real work soon.

Proposal Link

Zend_Service_Tumblr

Still churning away on this! Nothing major to report yet.

Proposal Link

I would like to see the “standard” Zend Framework bootstrapping method to be supported in Zend_Test_PHPUnit_ControllerTestCase. It is confusing and not obvious on how to reuse your Zend_Application_Bootstrap when using the ControllerTestCase.

There are 2 ways that this can be done.

—— First Method ——

Document with code examples on how to use Zend_Application_Bootstrap_* in the Zend_Test_PHPUnit_ControllerTestCase manual. However one issue is that it feels a bit weird as you have to overwrite $this->_frontController manually yourself.

— One Current Example —

public function setUp()
{
    $this->bootstrap = array($this, 'appBootstrap');
    parent::setUp();
}
 
public function appBootstrap()
{
    $this->frontController
         ->registerPlugin(new Bugapp_Plugin_Initialize('development'));
}

— Using Zend_Application_Bootstrap Example —

public function setUp()
{
    $this->bootstrap = array($this, 'appBootstrap');
    parent::setUp();
}
 
public function appBootstrap()
{   
    // Create application, bootstrap, but don't RUN!
    $application = new Zend_Application(
        APPLICATION_ENV,
        APPLICATION_PATH . '/configs/application.ini'
    );
    $bootstrap = $application->getBootstrap();
    $bootstrap->bootstrap(); //note run() is not called!
    //front controller now bootstrapped using whatever method you used (config, resource plugin...etc)
    //Having $this->frontController and $this->_frontController may be hard to explain
    $this->_frontController = $bootstrap->getResource('frontController');
}

As you can see this is quite simple, but as I noted in the comment it may be confusing to explain that you have to overwrite $this->_frontController not $this->frontController.

—— Second Method ——

Actually supporting Zend_Application_Bootstrap in ControllerTestCase.

public function setUp()
{
    $this->bootstrap = new Zend_Application(
        APPLICATION_ENV,
        APPLICATION_PATH . '/configs/application.ini'
    );
    parent::setUp();
}

if $this->bootstrap is set to an instance of Zend_Application then have the ControllerTestCase automatically call $bootstrap->bootstrap() for you. Future calls to $this->getFrontController() will retrieve the frontController from the bootstrap instead.

This is a simplified example obviously and I may have missed some details, but it seems obvious for some kind of support of the “standard” bootstrapping method. Bootstrapping can be very lengthy/complex and since the main goal is re-usability why would we want to have a completely different bootstrap method (or duplicated) for controller testing. I think this improvement will “sync” Zend_Test_PHPUnit_ControllerTestCase with the encouraged bootstrap method. This also puts to great use the separate production , development, testing ini settings document in the Zend_Application quick start. It becomes even more important with all the plugins with preDispatch details…etc. I think you get the point .

Thoughts, suggestions, hate messages are welcomed

What am I excited about?

New Entity definition approach

/**
 * @DoctrineEntity
 * @DoctrineTable(name="user")
 */
class User
{
    /**
     * @DoctrineId
     * @DoctrineColumn(type="integer")
     * @DoctrineGeneratedValue(strategy="auto")
     */
    public $id;
    /**
     * @DoctrineColumn(type="varchar", length=255)
     */
    public $username;
}

In Doctrine 1.x you had to extend a base class Doctrine_Record. This new method does not impose on your existing entities.

New Entity Manager

$user = new CmsUser;
$user->name = 'Guilherme';
$user->status = 'Slave';
$user->username = 'gblanco';
//EntityManager
$em->persist($user);

This is much cleaner than the previous approach and is now leaning towards an ORM that can be paired with a Domain Driven Design “style” of coding. I’ve been leaning towards this style and haven’t seen any ORM’s in PHP that can accomplish this well. This should make testing easier also!

In conclusion Doctrine 2.0 + Zend Framework = Awesome. I’m been working on a project that could really use Doctrine 2.0 NOW…

Side Note

There is another ORM called Outlet that also implements the non imposing Entity definitions and a has an Entity Manager, but I can’t vouch for them personally. In addition I don’t know how well the code base is…

While I was working on the Zend_Service_Tumblr component, I’ve ran into some implementation specifics I wasn’t 100% sure of or if Zend had a suggested approach for the specific case already. I’ve used what I believe would be best for ZF when planning, but maybe it could be documented to help others.

Some examples:

Validation

Should the ZF client validate or let the web service do the validation? Maybe a mix?

Validating everything locally could be very time consuming and sometimes not possible if the validation rules aren’t stated in the web service documentation. At the same time validating everything remotely may not be acceptable under certain circumstances. Validating a number, length of a string..etc is easy, but validating an file upload may not be or even possible. I wanted to be somewhat consistent so which way should I go?

Testability

While there are tests for every Zend_Service component, there isn’t a normal guideline to on what approach to use or how testable it is. For example, if the component required a Zend_Http_Client instance, should the component be injected (optionally usually) in the constructor or using setters? If the Zend_Http_Client is instantiated inside the component, where should it happen?

Constructor
(Zend_Service_Simpy)

public function __construct($username, $password)
{
        /**
         * @see Zend_Service_Rest
         */
        require_once 'Zend/Rest/Client.php';
        $this->http = new Zend_Http_Client;
        $this->http->setAuth($username, $password);
}

Lazy loading
(Zend_Service_Amazon)

public function getRestClient()
{
        if($this->_rest === null) {
            $this->_rest = new Zend_Rest_Client();
        }
        return $this->_rest;
}

In addition some of the ZF client’s don’t allow a setRestClient() or a setHttpClient method (this may be for good reason though) so you can’t override the normal instances without extending the class and having your own implementation. This is more nit picky, but it’d be nice if you were using many Zend_Service components to know offhand as it is consistent. This is also important when writing tests for your own application. You may want to inject a test Http adapter. Right now certain components require mock objects to do so while others have a simple injection method.

How much of the API should be implemented?

Should there be some guidelines on how “full” an API needs to be implemented? For example Zend_Service_Flickr only supports “fetching” methods and no creating or updating methods. I know this was created in the early days, but should partial implementations be accepted in cases like Flickr where it seems obvious to support more?

Thanks for reading and let me know if you agree or have any suggestions.

This proposal is accepted for immediate development in the standard incubator.The proposal is very well written, and shows plentiful use cases; I have absolutely no doubts on reading it that you have fully considered the Tumblr API and will be fully exposing it for users. Thank you for taking the time to provide such good detail!

Finishing the proposal should be a great learning experience on contributing to the Zend Framework and open source in general. Look for this component soon!

It is by far my favorite DI implementation and it’s built for PHP 5.3 (Note: FLOW3 is still in alpha stage). While not impossible (as far as I know) I wish I could use the Object Framework independently into existing projects especially with the Zend Framework “efficiently”, kind of like how the Symfony dependency injection implementation is.

Link: FLOW3 – Object Framework

Check it out now if your interested and you haven’t seen it.

Proposal Link

So I used this:
$checkbox->setLabel('I agree to the <a href="/i/copyright">Copyright</a>');

Problem with this is that it outputs the escaped version:

What I needed was:

This was a suprisingly lengthy find. After some time I stumbled upon a post by Stefan Koopmanschap here.

His solution was to use:
$element->setDecorators(array(array('Label', array('escape' => false))));

This worked for the HTML part as my link now appeared, but I didn’t see my checkbox, just the label. So looking at the method name I assumed it overwrote the default decorators and found out that I was correct. The easy way to get the link in while maintaining the default decorators is to simply add the decorator.

Example
$checkbox->addDecorator('Label', array('escape' => false));

As simple as this is it took some time to figure out. While the Zend Framework documentation is pretty awesome it doesn’t cover all use cases. Hope this helps someone.