Earlier today I posted about creating a DateTime Picker in SugarCRM. A second problem I had was creating an auto increment field. This turned out to be slightly more difficult than the datetime picker. Again you need to edit your vardefs.php but this time you add the following to your field.

'auto_increment' => true,

You then need to manually alter the table structure so the id field is a unique index instead of a primary key then add your new column to the database as an auto_increment field and the tables primary key. I also found that if you try to install the module on another system it will fail because it can’t create the table properly. You can solve that by creating the table then installing the module.

Recently I needed to add a date/time field to a custom SugarCRM module. Sadly the module builder doesn’t include support this and the documentation is pretty bad. Eventually I managed to solve my problem and the solution is suprisingly simple.

After adding a date field to the form I edited my vardefs.php file. You’ll find the file in custom/modulebuilder/packages/package_name/modules/module_name/. Find the field and change it’s type to datetime.

Next you need to change your views. They’re located in custom/modulebuilder/packages/package_name/modules/module_name/metadata. In my case I wanted to the edit view to show a datepicker plus a time combo. I found the field and added

'type' => 'Datetimecombo'

After that I deployed the package and my module was now saving as a date/time and in the edit view I could set both the date (using a date picker) and time (using drop down lists).

As a developer it’s all too easy to blame a framework for your applications bad performance. Before you do you might like to ask if you’re contributing to the problem. Most developers don’t think about what they’re really doing or how they could improve performance. I’ve seen a lot of code where every request results in at least one database query even though the database rarely changes.

Below are some stats for an application using the Zend Framework:

PHP – 36 requests/second

PHP + APC – 111 requests/second

PHP + APC + Memcache – 2,048 requests/second

By spending around 3 minutes to add code so the pages output is cached I’ve been able to improve performance 56 times without needing to throw out the framework. Of course this is an extreme example but it applies to most CMS, blogs, etc…

Lately I’ve been looking at a number of SaaS providers covering a range of areas. It amazes me how many of them have no API or only a reporting API. If you’re thinking of building a SaaS start-up then you should be thinking about creating an API that allows your customers to do everything they can with your user interface.

Service providers with this API have an obvious advantage when it comes to migration and integration but they also have a more subtle and more important advantage. When reviewing potential providers I looked at those with an API before those without. Your SaaS may be the best but without this API are potential customers even considering you?

I don’t usually blog about work but I think this may interest some people. Late last year we trialled the Zend Framework in a small application. A few months ago we begun the process of converting our main PHP application to it. The migration is still in the early stages so some of this may change rapidly.

We decided on the Zend Framework because it was component based. This was important because we have an existing code base with a regular release schedule. Stopping development while we converted the application wasn’t an option so we needed something that could be integrated slowly.

So how are we doing this?

The first task was to replace the applications module structure with auto loading. While this reduced the number of files that needed to be included to process a request the biggest advantage was making the code more visible to the developers. Prior to this classes were hidden 2, 3 or 4 levels deep in modules. The immediate impact was finding a number of classes that were no longer required.

Next I was expecting to replace some of the more discrete components like logging but it didn’t turn out this way. Because of the applications development schedule work instead focused on migrating from our custom MVC to the Zend Framework MVC.

After writing a bootstrap file  we created controllers and actions. The release cycle wasn’t long enough to completely convert the old MVC so the new actions simply call the old code. This approach allowed us convert the front controller (without session management and authentication) in about a day and means that new code can be written using the Zend Framework instead of our old framework.  Custom routing was required to emulate some of the old URLs.

The session management and authentication took about to day to sort out on its own. All of the controllers share a common base class. It’s init() function provides some common functionality:

1. Initialize the view
2. Initialize the session (except the API or AJAX controllers)
3. Set all actions as requiring authentication

Starting sessions is done in the controllers init() function instead of the bootstrap file so we can prevent sessions from being started for API calls. This is important because we get a large number of API calls and none of them requires a session. The other important task for init() is to mark some actions as not requiring authentication.

Authentication itself takes place in the controllers preDispatch() function. This provided backwards compatibility with the way the application previously worked.

More recently we’ve begun removing static methods from business logic so that we can use dependency injection to make testing easier. I’ll post about this next time.

While most forms contain fixed fields there are occasions when you need a form to be dynamic and adjust itself based on user input. The adjustment could be as simple as altering the options in a drop down list or as complex as adding/removing fields. In this post I’m going to cover how to create a dynamic form using Zend_Form and jQuery. I’ll use the example of a registration form that prompts the user for their country and state. The requirements are pretty simple:

1. It should only prompt for a state if the country has states.
2. The state list should only show states for the selected country.
3. The form should degrade gracefully so it works without Javascript

To start I’m going to create a World class. This class has two functions. The first returns a list of countries. The second returns a list of states for a specified country or a list of all countries that have states plus the states in those countries. You might like to retrieve this information from a database but for simplicity I’ll hard code the information into the class.

class World
{
    static private $_countries = array(
                       "AU" => "Australia",
                       "NZ" => "New Zealand");

    static private $_states = array(
		        "AU" => array(
		            "ACT" => "Australian Capital Territory",
		            "NSW" => "New South Wales",
		            "NT" => "Northern Territory",
		            "QLD" => "Queensland",
		            "SA" => "South Australia",
		            "TAS" => "Tasmania",
		            "VIC" => "Victoria"));

    public function getCountries()
    {
        return self::$_countries;
    }

    public function getStates($country = null)
    {
        if ($country === null) {
            return self::$_states;
        }
        if (array_key_exists($country, self::$_states)) {
            return self::$_states[$country];
        }
        return null;
    }
}

Next I’ll create a class for the form (RegForm) by extending Zend_Form. This gives our registration form all of the advantages you get from Zend_Form including input filtering and validation. The form elements will be added in the constructor so that creating a new form is all you need to do to use it.

As our form needs to adapt based on user input the constructor needs to accept the user input as one of its parameters. This allows us to adjust the form elements based on the user input. All code using these parameters needs to be extremely careful as the user input has not been filtered or validated yet.

class RegForm extends Zend_Form
{
    public function __construct($world, $params)
    {
        parent::__construct();

        $countries = $world->getCountries();
        $countryKeys = array_keys($countries);
        $thisCountry = isset($params['country']) ? $params['country'] : $countryKeys[0];
        $states = $world->getStates($thisCountry);

        $country = new Zend_Form_Element_Select('country');
        $country->setLabel('Country')
                ->setMultiOptions($countries)
                ->setValue($thisCountry)
                ->setRequired(true);
        $this->addElement($country);

        $state = new Zend_Form_Element_Select('state');
        $state->setLabel('State');
        if ($states !== null) {
            $state->setMultiOptions($states)
                  ->setRequired(true);
        } else {
            $state->setRegisterInArrayValidator(false);

        }
        $this->addElement($state);

        $submit = new Zend_Form_Element_Submit('submit');
        $submit->setValue('Add User')
               ->setRequired(false);
        $this->addElement($submit);
    }
}

There are two important things that RegForm does:

1. The state options are adjusted to match the selected country.
2. The state is not validated if the country does not contain states.

This means that our form will work exactly the way you expect Zend_Form to work. Without Javascript if you select a country and submit the form then the state list will adjust and display an error that the previously selected state was invalid. After you select a valid country and state the form will validate. If the selected country does not have states then the form with validate regardless of the selected state (providing there are no other errors).

I then need to create the controller.

class AccountController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $params = $this->_getAllParams();
        $world = new World();
        $form = new RegForm($world, $params);

        if ($this->_request->isPost() && $form->isValid($params)) {
            // The form was valid!!
        }
        $this->view = $form;
    }
}

Finally we can add Javascript to alter the form in browser. If you’re using the forms render() function then the Javascript will look something like this.

    var countries = <?php echo json_encode($this->world->getCountries()); ?>;

    var states = <?php echo json_encode($this->world->getStates()); ?>

    function updateStates() {
        var state = $("#state");
        var country = $("#country");
        var hasStates = false;
        jQuery.each(states, function (cc, slist) {
            if (cc == country.val()) {
                hasStates = true;
                state.html('');
                jQuery.each(slist, function (code, name) {
                    state.append('<option value="' +  code + '">' + name + '</option>');
                });
            }
        });
        if (hasStates) {
            $("#state-label").css("display", "block");
            $("#state-element").css("display", "block");
        } else {
            $("#state-label").css("display", "none");
            $("#state-element").css("display", "none");
        }
    }

    $().ready(function () {
        $("#country").change(function () {
            updateStates();
        });
        var state = $("#state");
        if (state.val() == null) {
            $("#state-label").css("display", "none");
            $("#state-element").css("display", "none");
        }
    });

This code takes care of hiding the states if they are not required and adjusting the states based on the selected country without needing to submit the form. With minimal effort I’ve been able to create a dynamic form using Zend_Form to do most of the hard work. Users with Javascript enabled get an A grade experience while those without Javascript can still use the form.

If you’re a PHP Architect reader (or thinking of becoming one) then you may be interested in this:

@mtabini I feel like celebrating for no reason. 50% off everything at php|a (except #tek09) with this coupon code: LVQ0-Q1XN-AV6C (24hrs only!)

I was lucky enough to attend the Yahoo!7 Open Session this evening. While talking to some staff I discovered that they have the tiles with street maps for Australia, which are available on maps.yahoo.com.au, but they aren’t yet available via the maps API. Hopefully they’ll be available soon.

Over the last two days I’ve found a couple of hours to play with both Yahoo maps and Google maps. It’s my first attempt at building an application that plots data on a map. After starting with Yahoo I quickly moved to Google. The main reason for switching was because the Yahoo (API) maps don’t include street maps for Australia. This seemed kind of strange as maps.yahoo.com.au does include them. A quick check of some US cities and London showed that they did have street maps so I think I set it up correctly.

Currently it displays a marker on the map for every data point. The next challange is:

1. Only include markers that will be rendered on the current map,
2. Combining markers as the user zooms out.

We’ve just cancelled the April SydPHP Group meeting. For more information check out http://www.sydphp.org/