Thanks to Filip Forrez for the inspiration for this post.

As developers, we are often presented with UI choices. Some create subtle differences, others larger ones.

One of them is the way we present the possibility to select multiple items from a set (list) of predefined items. Traditionally this is realized by 2 select-lists with the multiple attribute.

In an (advanced) Sencha Ext Js implementation, you get this:
http://dev.sencha.com/deploy/dev/examples/multiselect/multiselect-demo.html

This offers a lot of features and while we as developers see this as the default way to offer this functionality, there are other options too.

In the spirit of mobile development, a list with check-boxes offers the same basic functionality:
http://demo.superdit.com/ext_listview_dataview/

You would also never be able to present the first solution on a small mobile screen. Another option to meet the same basic requirement is the way Google Calendar lets you add multiple invitees to an appointment.

Depending on the features you need, one option may be preferred over the other. Think of features like:

• Sorting: you may need to offer the possibility to sort the result.
• Quantity of predefined options: too much data may require a way to search.
• Linkability: list-items may also need to be clickable and link to detailed information.

In some cases, a more creative approach can really have your site or app pop out.

After trying to do something as simple as replacing an HTML element in the dom with a string (HTML in this case) with Ext JS for about 3 hours without finding a proper answer on Google, I thought someone else might also benefit from my (sub-optimal) solution.

In my case, the string was a HTML fragment returned from an AJAX call. It needed to replace a HTML element already in place in the dom.

Ext.DomHelper.overwrite() works, but only replaces the contents of an existing element, not the element itself (and since the parent of that element contained other elements too, a higher level selection didn’t solve it either).

You would expect Ext.DomHelper.insertHtml(‘beforeBegin’, oldElement, html) and deleting the oldElement afterwards to work, but it generated an error message which (if I’m correct) told that the html string is not linked to the dom already (which is of course not the case).

Since I could not find a proper working solution, I tried to use the Ext.DomHelper.createTemplate() method to create an Ext.Template and to use template.insertBefore() with an empty values array to get it into the dom before removing the old element. This does not look optimal, but at least it works…

When optimizing queries, you don’t need to be reminded that indexes play an important role.

Something to remember though: in real-world examples a multi-column index often outperforms multiple indexes.
So it can be worth changing something like:

INDEX `index1`(`column1`),
INDEX `index2`(`column2`)

to

INDEX `index1`(`column1`, `column2`)

MySQL 5.0 introduced an internal method called “Index Merge” which merges multiple indexes when querying a table (if applicable) but I haven’t seen this being used that often. On the contrarry, MySQL often picks one of the indexes and in these scenario’s it is especcialy usefull to have one multi-column index.

As always: use EXPLAIN to see what can be improved.

While working with Zend Framework, you must have asked yourself “Is there an easy way to redirect to another controller/action?”

Well, there is. When redirecting inside a controller, the first method we think about will probably be $this->_redirect(). This is quick, but it only accepts a URL. This means you have to create a URL to a specific route yourself. Either with the $this->view->url() URL view helper (which is not a pretty sight) or by assembling a route.

Yes, there is also $this->_forward() which sends your request to another controller/action, but it also goes through all init() logic again and forwarding isn’t suited for every situation (e.g. after a form POST).

But there is a far more flexible way: the less known Redirector action helper. Actually, $this->_redirect() uses it, but it provides easier ways to redirect to a specific route:

$redirector = $this->getHelper('Redirector');
$params = array(
	'controller' => 'my-controller',
	'action' => 'my-action',
	'other-param' => 'value'
);
$redirector->gotoRoute($params, 'my-route', true);

Its usage will be self explanatory (actually the parameters are the same as the URL view helper), but I want to add a little note about the last parameter (which the URL view helper also accepts): if true, it “resets” your route, meaning all other parameters currently in your Request object are removed. This implies that when setting it to false (which is the default) parameters you have in your “current URL” will be reused (unless overwritten).
This can be particularly useful when passing search query, paging,… parameters from one page to another.

So, next time you need to redirect: pull out the Redirector action helper.

When developing with Zend Framework, it is difficult to keep track of new versions, new components, changes to components, roadmaps,…

After “Beginning Zend Framework“, you’ll need to stay current too. You can of course read everything on the wiki, but if you use a RSS reader (if not, you really need to) add this feed.

It provides a great overview of all proposals and discussions concerning components. Even if you don’t have time to follow up on this each day (there can be a lot of comments), by looking at the titles of the posts you can have an idea of what is going on.

One of the consequences of the huge popularity of Zend Framework is that everyone who is using PHP in one way or another has at least thought about using it (because it all sounds so good and, possibly, easy).

But different people need different approaches to start developing with Zend Framework. And the publishing companies that published the first books about Zend Framework (and apparently also the second wave of books) tend to forget about some groups of users. A little summary (in no way meant to offend):

Developers with a different background (another programming language)

Depending on the background, migration will not be that hard. I can imagine a .NET or Java developer easily gets the principles of a framework (and hopefully also understands OO programming). Ruby or Python will be even easier (but why on earth would they migrate?).

The average PHP developer (not already using Zend Framework of course)

If the Zend Framework manual is not sufficient for this group, there certainly are a lot of books available that eliminate all barriers. Of course look for the most recent books, since a lot of versions have been announced the last 2 years and, to be honest, some of the early books were published in a hurry to benefit from being among the first.

Dreamweaver users (often called “webdesigners“)

Yes, this group is also (willingly or unwillingly) pushed to, at least, have a look at Zend Framework. And to be honest, at the moment, I wouldn’t know how they can prevent themselves from creating something that isn’t maintainable in the years to come.
Zend Framework (or any other framework in this case) promises a lot of good things (which may lack in the current PHP snippets, Smarty templates, open source CMS,… now being used). Starting with the manual certainly is tricky. Getting a thorough grip of PHP/OO concepts may sound boring, but you need it.
As a suggestion: don’t set too high expectations and take your time. It may be useful to force yourself to get a PHP certification. Not because you need it, but because it forces you to learn/refresh the PHP basics.

Also: be honest to yourself. If you notice OO concepts don’t interest you, think about it and maybe try something else. Another lightweight framework like CodeIgniter (there is no such thing as “the best framework”) or no PHP development at all may better suit you. No one has ever been happy forcing themselves in a position doing something they don’t like to do!

Dummies

Belonging to this group is no disadvantage. Ok, you don’t have the experience of someone who has been using PHP since before the dot-com bubble burst, but at least you acknowledge this. Starting from scratch (and knowing it) can eliminate a lot of barriers.
Start by learning PHP and fairly early start with a decent PHP OO book and, again, take your time. In my opinion you don’t have to finish 5 courses and 3 books to start with Zend Framework. When learning Zend Framework (e.g. from the manual) you’ll also learn OO principles and best practices, but you need a basic knowledge first.
Also don’t expect that you can add new Zend Framework components on day 2, it will take time.

Did I forget about someone? I certainly hope this post can help as a starting point for new Zend Framework developers (or people thinking about becoming one).

Working with gettext as your translation engine your project? In need of a rough translation of your application for a mockup/preview/…?

Paul Dixon offeres a free service that automatically translates a gettext PO file with Google Translate. I personally use gettext a lot because of its speed and ease of use (with poEdit) and this will certainly be of use.

Of course the results should not be used in a production application.

Although I must admit I didn’t notice it, less than 2 months after it was decided to create a new version for Propel, it was actually released.

Last week, on the 8th of November, the new 1.4.0 version has been released for production use. Additionally they also set up a blog to prove Propel is still very much alive.

Propel 1.4 is a backwards compatible evolution of Propel 1.3. It offers lots of bug fixes, some very interesting new features, speed enhancements, and a very simple upgrade path: rebuild your model after updating Propel, and your application works as always. Except it works better…

It all sounds to good to be true!

A first migration of a project to this new version went smoothly: remember to remove the *-classmap.php file that was generated by 1.3.0 because it has been integrated in the main config file. It’s also recommendable to delete the /map sub-folder in your models folder because 1.4.0 generates newly named *TableMap.php files.

Also good to have: full query logging (Propel 1.3 switched to PDO and lost this feature but it’s back!).

I must also admit I have never actually implemented Doctrine, but that’s also because I haven’t found a reason while using Propel.

I’ve been looking for this for a while: how to add Apache’s build tool Ant to Eclipse when it is not available to add as a view.

When you download and run the standard PDT for example, it is not available.

The answer seems to be: install the Eclipse Java Development Tools.

This may not be the ideal way but if you want to do this through the “Install New Software…” menu, it seems to be the only one.

Just select “Work with: Galileo” (or whatever your Eclipse version is) expand “Programming Languages” and select “Eclipse Java Development”.

After the installation completes you can add Ant as a view.

I finally tried Zend Server Community Edition as a replacement of WampServer (or XAMPP) for local development.

While Zend Server proposes to be the perfect solution for any environment, I specifically tried it as a development stack on Windows machines. The use and usefulness of course completely differ in any other scenario.

First of all (and of great importance if you ask me): it is clean, simple and easy to use from A to Z. The installer provides the right options but not too many, the dashboard (control panel) is slick and provides quick access to settings you don’t often find in any other “server packages” and last but not least it performs much better due to the use of FastCGI on Windows.

2 less-frequently used features I missed though:

• A way to set up VirtualHosts in the dashboard.
• A WampServer-like way to switch between PHP (and in a lesser extend Apache) versions.

In total, the fine packaging almost got me convinced to replace WampServer.

Almost… because the choice for FastCGI on Windows also has one major disadvantage: you cannot use php_value settings inside your Apache/VirtualHost configuration. I especially like this since it avoids setting include_path, display_errors, upload_max_filesize and the like inside your scripts or .htaccess (which in some setups causes it to be parsed at every request).
Doing this in Zend Server on another platform isn’t a problem, since they use the PHP Apache module instead of CGI but that means you do not have similar environments and that is the complete opposite of what we want.

So it ended with a deinstallation. On the other hand: I can really see the benefit of this package for live/production environments. With it’s included optimization tools it takes a lot of configuration hassle away.