I didn’t find a good solution to the problem when searching and had to resort to my own, hacking away on Google Maps. As I was feeling really good about myself when I had it working really well I just remembered that Google Maps Javascript API V3 has been released in Google Labs… And of course there it was. The Marker class has a new method, setZIndex(zIndex:number).

Well, version 3 of the API is still only released by Google Labs which is “home to developer products that are still in their formative stages“. So for anyone not inclined to use version 3 just yet, I’ll write down how I did it here.

As I use JQuery in this particular project the example is also using JQuery. If used in production I suggest using try/catch wherever appropriate as the solution depends on a specific dom structure.

I have the below HTML which is the container for the Google map.

<div id="indexmap"></div>

The map is created as below (you’ll have to add the lat/lng variable values yourselves.

var map = new GMap2($('#indexamp'));
var point = new GLatLng(lat, lng);
map.setCenter(point, zoom);

This, as most know, creates the actual map. Then it is time to add the markers. In my case I have a list of locations with the latitude/longitude in the actual html. JQuery helps me loop over these locations and dynamically add markers in the correct spots. This HTML looks like below. Note how each definition list have an id no with “mm_” as prefix. (Never mind any objections you have on having many definition lists like this… Never mind that these coordinates are fiction…)

<dl id="mm_0">
  <dt>...</dt>
  <dd>
    <span class="lat">61.333</span><span class="lng">31.1324</span>
    Random text
  </dd>
</dl>
<dl id="mm_1">
  <dt>...</dt>
  <dd>
    <span class="lat">61.333</span><span class="lng">31.1324</span>
    Random text
  </dd>
</dl>

What I want is the markers to be highlighted with a different icon every time I hover over a definition list element (dl). However, both have the same coordinates and one of the markers will be hidden behind the other.

So to prepare we need to make sure the actual images in the Google generated map can be connected to these defintion list id:s. The Google map have many different layers on top of each other. One layer contain the foreground images, another the shadows, mouse map definitions and so on. Each of these layers (normal div elements) have their own z-index.

In these different layers the images used have their own z-index. However, the z-index for the marker foreground image is the same as for the transparent clickable marker image. This makes it possible to use the transparent image z-index to restore the foreground image z-index. This is important as not to confuse the user when he later click on a marker…

So let’s loop over these images and give them appropriate id values as well as put the markers on the map. (No – Google does not give them id’s). This is, stripped to the bare essentials, the complete code with some comments.

// Create the map
var map = new GMap2($('#indexamp'));
var point = new GLatLng(lat, lng);
map.setCenter(point, zoom);

// Loop over the definition lists picking up coordinates
var n = 0;
$('dl').each(function() {
	var lat = parseFloat($('span.lat', this).text());
	var lng = parseFloat($('span.lng', this).text());
	var point = new GLatLng(lat, lng);

	// Create the marker with custom images
	var markerIcon = new GIcon(G_DEFAULT_ICON);
	markerIcon.image = 'marker_default.png';
	markerIcon.iconSize = new GSize(23, 30);
	markerIcon.shadow = "marker_shadow.png";
	markerIcon.shadowSize = new GSize(50, 30);
	markerIcon.iconAnchor = new GPoint(11, 29);
	markerIcon.infoWindowAnchor = new GPoint(11, 14);

	var marker = new GMarker(point, {icon: markerIcon});

	// Change the foreground image when hovering over a definition list
	// Note that the actual id's have not been created yet.
	var no = this.id.substring(3); // Exclude the prefix
	$(this).hover(
		function() {
			marker.setImage('marker_selected.png');
			// Bring this image to foreground
			$('#mf_' + no)[0].style.zIndex = 1;
		},
		function() {
			marker.setImage('marker_default.png');
			// Reset the z-index based on the transparent image
			// that has the same z-index
			$('#mf_' + no)[0].style.zIndex = $('#mt_' + no)[0].style.zIndex;
		}
	);
}

// Add id values to the foreground images, based on the
// dom structure created beneath the #indexmap div element used
// as the place holder for the map
n = 0;
$('#indexmap div > div > div:eq(6) img').each(function() {
	this.id = 'mf_' + n++;
});

// Add id values to the shadow images the same way
n = 0;
$('#indexmap div > div > div:eq(8) img').each(function() {
	this.id = 'mt_' + n++;
});

You might have to amend the code to get it working for you as I have cut’n pasted different parts. In the real code there is a lot of other things going on that would’ve made the example above hard to read. I do think however that you should be able to understand how it works.

After a trip to Dublin I finally launched the beginning of a new social tourist Dublin guide. It is exactly the same site as both the Swedish Fuengirola guide as well as the English Fuengirola guide I launched after living there for five months. The functionality is somewhat basic as of yet but every now and then I’ll add something more.

Basing three different sites, even though they are very similar, using two different languages gives me the possibility to try out several parts of Zend Framework. It also requires a good design both in the backend and frontend to keep it maintainable. I thought maybe some people would be interested in a basic overview of the different parts needed to put everything together.

Backend

The sites aren’t really that complicated. On a basic level there is a MySQL database and a database layer using Zend_Db/Zend_Db_Table, there is a Zend Framework MVC architecture using models, controllers, views, layouts with Zend_Layout as well as a few view helpers and some HTML, CSS as well as Javascript. All commonly needed. There is more needed to make it a sitethough.

I want as little configuration per site as possible but I naturally still use Zend_Config_Ini for settings. Zend_Registry is needed to keep the global scope clean and is used to store instantiated objects that need to be available throughtout the website logic.

I have been a bit particular on using ZF as often as possible on these sites. With few exceptions. Thus I also use Zend_Form, Zend_Locale, Zend_Translate, Zend_Cache and more. Zend_Cache is really a no brainer and mainly used to speed up translations. This is extremely easy as Zend_Translate and Zend_Locale both are connected to the cache with one simple method call each. It is not complete but how simple this is to setup is illustrated by the below code.

$configuration = new Zend_Config_Ini(
    APPLICATION_PATH .'/config/app.ini',
    APPLICATION_ENVIRONMENT
);
$frontendOptions = array(
    'lifetime' => $config->cache->lifetime,
    'automatic_serialization' => true
);
$backendOptions = array('cache_dir' => $config->cache->dir);
$cache = Zend_Cache::factory(
    'Core',
    'File',
    $frontendOptions,
    $backendOptions
);

$conf_locale = $configuration->locale;
$locale = new Zend_Locale($conf_locale);
$locale->setCache($cache);

Zend_Translate::setCache($cache);
$translate = new Zend_Translate(
    'array',
    APPLICATION_PATH .'/config/translation-' . $conf_locale . '.php',
    $conf_locale
);
$translate->setLocale($conf_locale);

Zend_Form have had a few problems in many versions of ZF. In my opinion it is also a bit bloated and limiting to be used all the way. (Even though I like the automatic connection to the translation functionality in Zend_Translate and the validation through Zend_Validate) So I have settled for a simpler way where I use Zend_Form fully for validation (with Zend_Validate) and then give the view access to the form through a Zend_Form subclass to be able to print the fields individually. I think this is easier to handle than all the overloading and coding needed to fully make Zend_Form create forms as I want them. Another good thing with the form classes is that they too are locale aware and are translated automatically by connecting them to Zend_Translate through the simple line Zend_Form::setDefaultTranslator($translate);. The sub classed Form utility class looks like below. The generated elements are translated automatically. Very convenient.

class Custom_Form extends Zend_Form  {
    /**
     * Render a field
     * @param string $name The name of the form element
     */
    public function _e($name) {
        $e = $this->getElement($name);
        return ($e) ? $e->render() : "<dt>Error</dt><dd>Missing <$name> field element</dd>";
    }
}

Another thing needed for these sites are to keep the urls understandable and thus translated into the language used on the site. For this the routes, or paths, are kept in the translation file as well. The translated paths are then registered to the router through the use of Zend_Controller_Router_Route and Zend_Controller_Router_Route_Regex objects.

$frontController = Zend_Controller_Front::getInstance();
$router = $frontController->getRouter();
$router->addRoute(
    'route_review',
    new Zend_Controller_Router_Route(
        $translate->translate('route_review'),
        array('controller' => 'review', 'action' => 'index')
    )
);

For image manipulation I haven’t looked further than ImageMagick. After a bit of tweaking you get very good quality when producing different image sizes.

Search

Last but not least, on the backend that is, there’s the search engine. ZF have an implementation of Lucene through Zend_Search_Lucene (derived from the Apache Lucene project). This is the one time I haven’t gone with ZF as I very much like the open source Sphinx search engine as it is so easy to integrate with MySQL. So Sphinx get to power the search.

This is convenient for several reasons. MySQL is not a great full text search engine, Sphinx give you better weighted results. The main reason though is the performance. Sphinx is very fast in itself but for a site with heavier traffic it is as simple as moving the search backend to it’s own machine to get a performance increase.

Frontend

On the frontend there is as clean html as possible to make it easy to change the design with only CSS as well as manipulate the client side with JQuery. If it wouldn’t be for the Google map the site would actually be pretty useful even without no css style at all.

A good practice I learned just recently (remember I’m mostly a backend developer) is to base all javascript functionality on modules that are instantiated depending on element ids present in the html. This makes it a lot simpler to split the javascript functionality into manageble pieces and also makes it a lot easier to maintain.

There are functionality in the client side javascript used to display error messages and information. This makes it necessary to create one javascript file with translation stirngs for each language. The correct javascript translation file is chosen in the layout (template/view file) depending on the current locale.

The map used is (are there any alternatives) Google Maps API. I chose to completely initiate the map by scanning the actual data displayed on the page. This is possible through clean html markup and also means that if I choose to list ten reviews on a page instead of five nothing need to be changed at all in the frontend. Only a loop limit on the backend.

Conclusion

Well. No conclusion. This was just a very basic walkthrough of most of the different pieces needed to create a fairly simple Zend Framework based website. Mostly it was a walkthrough of the bootstrap… I still hope it is useful or at least interesting.

I know I find it interesting to read about other sites and the architecture and design behind them.