photo credit: Or Hiltch

This took a whole day for me. Hopefully I can save you the pain. I added quite a few possible search terms here for maximum coverage, so the text may get a bit repetitive. I mean – when I tried to look for a solution, I didn’t even know what to look for – so I tried googling for every symptom I saw, to no avail.
The deal was this: my page has a very large form, which is logically separated to 3 parts.
One part is mandatory, and the user must fill in all the fields on it. However, the other two parts are completely optional, and it is quite possible that some users won’t even bother with one or both of them (See the uber useful diagram below)

Form with mandatory and optional parts

Normally, you’ll split this form into a wizard type of thing, but again – some users may not use the optional parts at all, and anyway – we don’t do wizards.

Because of the form’s size, I didn’t want the optional parts to appear alongside the main part on the page. This would have made the page huge. So, I came up with the brilliant idea to have them hidden (wrapped with a <div> element with style=”display:none”) and display them with fancybox. (See the next beautifully decorated diagram!)

Form with hidden div

So the idea is pretty simple. The user interacts with the mandatory part, and if they need one (or both) of the optional parts, they can click the links that read ‘Open optional part…’. These links have inline hrefs to the optional form parts which are inside the hidden div. (Each of these optional parts is contained in a div of its own, to make it easier for fancybox).

In document.ready() – I fancybox both these links. Which means that when they are clicked, their reference will open inside fancybox. This actually worked quite well and I was very happy.
Until I tried to save the data, and it wasn’t there. At least not all of it.

First issue: Form fields missing when submitted

Since I knew I wasn’t getting all of the form fields in my controller, I wanted to see what the browser was sending back on submit. Using firebug’s net tab, I got a little surprise.
if the user clicked on one of the links to display an optional part, the entire set of fields contained in the optional part was missing from the POST request.
The mandatory fields were always sent. But with regards to the optional parts – only the fields that were a part of an optional part that was not displayed (using fancybox) were sent back on submit.

Now, this is an outrageous behaviour. Theoretically, only disabled fields should be omitted from a submitted form, but none of my fields was being disabled.

Just to make sure, I changed the visibility of the containing <div> element, so that my optional parts showed all the time, and tried to submit the form. Everything was fine. But when I clicked on one of the links to display them (with fancybox) – I got the same behaviour.

Using jquery’s serailizeArray() showed that the fields were all there on page load, but disappeared right after the optional parts were fancybox’d.

Second issue: Fancybox ignores custom configuration

Alongside the issue of the missing fields, I wanted to manually control the size of fancybox’s overlay for one of the optional parts. This is normally quite easy:

The only thing you have to remember is that if you want to manually set height and width, you have to give both height and width. Also, you have to set both autoScale and autoDimensions to false.
However, fancybox didn’t care too much about my directives and refused to change its default rendering. I should have taken this as a warning, but since my form fields were disappearing on submit – I decided I have more urgent things to solve.

A middle-of-the-road moral here:

When Fancybox doesn’t do what you know it should do – there’s something wrong. Fix this first.

I was on a role with my form-issues, and disregarded this warning. Oh well.
Now, at this point, I could have just decided to go for a workaround: Use a wizard, make each of the optional parts a form unto itself, or just decide to display the entire form on one page (there are other visual tricks to use, but this is in the next post).

But no. I was on a mission to find out why fancybox removes my fields away. Seriously. Workarounds are good, but if I have the time – I’d rather get down to the bottom of it.

Could fancybox have changed my DOM?

A friend suggested that fancybox may have changed the DOM somehow. So I console.log’d document.body.innerHTML before fancybox and after fancybox (without changing any of the optional form fields).
Copied them into a couple of variables and compared:

Both were the same. So no visible mucking around (still, there could be issues with the DOM being manipulated, but it’s not that simple).

Third issue: Fancybox ignores custom configuration (I know… again)

To try and see what’s going on, I thought I’d hook on to fancybox’s onCleanup event. The onCleanup event gets called just before fancybox closes. I wanted to use it to display my form’s content- but as happened before, fancybox ignored me completely.
Now, second time you get the same warning – this is time to pay some serious attention.

First thing to try – ensure I’m on the latest version of fancybox (note – I know that there are no compatibility issues, because fancybox works perfectly on another page, where the entire form is contained within it).

Indeed, I had v1.3.1 and 1.3.4 was out. (fancybox v2 is great, but the license has changed so I can’t use it).

But upgrading did not change behaviour, so I downgraded back (this is important, I think. While it is usually good to upgrade, don’t blindly do it if it didn’t solve your issue. If a library upgrade did not affect the defect at hand – might as well reverse it and try solving the issue first – then go with the upgrade. Any upgrade can introduce new bugs that may obscure your initial problem).

Just to make sure I wasn’t losing my mind, I changed the default configuration options inside fancybox’s javascript (you can do it too – they are right at the bottom of the file).
This worked – I could hook onto the onComplete event or change the width and height. This meant to me that the issues I was having of fancybox ignoring my configuration or my form fields disappearing weren’t likely to stem from fancybox, but rather from my code.

When all else fails – RTFM

So, it’s off to the how-to page on fancybox’s website.
Now, here’s where I failed…

Fancybox requires a valid doctype

See, the problem is that while my document indeed had a valid DOCTYPE, it did not validate accordingly.
Sifting through the generated code, I found that the end </form> tag was badly placed. In essence I had the following structure:

See the problem? my form closed before a contained div element closed. While this works well (and has been for at least a year’s worth of browsers upgrade), when Fancybox was thrown into the mix it simply refused to accept this sorry state of affairs.

Fix your pages…

To confirm my suspicion and mock my HTML abilities, the issue was gone once the page validated completely, and I am now the proud owner of a form that has hidden optional parts that appear inside a fancybox wrapper when you click on links. Hooray!!

Form with hidden div

photo credit: Mr. Theklan

Double submit is when a user submits a form on your web page twice (well, technically they can do it more than twice, but you can’t call it a double submit…)
It usually happens when your user double-clicks your Submit button instead of clicking it, but may also happen in two other popular scenarios: your buttons do not provide the user with a visual feedback of being clicked (e.g. when you use an image as your submit button), or when your application takes too long to process the submitted form, and the user impatiently submits it again.

Looking around the web you can find quite a lot of discussions around double submission handling and prevention.

One of the most popular ways of preventing double-submit is to disable the submit button in its onclick event, and then submit the form:

This works for most cases, and because the button is disabled, your user can’t click it a second time.

The back button issue

Let’s pretend that after the user submitted your form, they are redirected to a new page, that displays some information related to the submitted form. The user reviews the information and decides to go back to the form and submit it again. Your user clicks the browser’s back button, and resubmits the form with new data. Good?

Yes, unless your user is on Firefox.

In Firefox, the disabled button will remain disabled after you go back, and your user won’t be able to click it. They’ll have to refresh the page in order to do so, but then they’ll lose everything they’ve already entered in the form, and that’s lame.

The reason this happens, and it is important to understand that, is that Firefox just reloads the page from its cache, and in the cache, the button is in a disabled state.

See this or this for the open bugs on Firefox’s Jira (there are others, even one when the developers say this is the intended behavior)

What can I do on Firefox?

There are a few suggestions out there:

1. Tell the browser to not cache your page using META cache directives.
   While this works – it is a huge overkill (especially where the other, innocent browsers, are concerned…)




2. Add autocomplete=”off” to your form element.
   While this works too, it has the added problem of clearing out the values of fields in your form, which is not very nice to your users.




3. Use Jquery’s ready() function to enable the button.
   This “should work”. But remember – Firefox loads the page from the cache. The ready() event will not be fired (try it with the following code on Firefox and chrome to see the difference. Note that you’ll also need to create success.php or a similar file for the action url)
   <!DOCTYPE html>
   <html>
      <head>
         <title>Duck vs Firefox round 1</title>
         <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js"></script>
         <script type="text/javascript">
            $(document).ready(function(){
             alert('ready');
            });
         </script>
      </head>
      <body>
       <h1>Round 1!!!</h1>
       <form name="myform" method="post" action="success.php">
            <input type="text" name="textInput"/>
            <button type="submit" id="nono" onclick="this.disabled=true;document.myform.submit();">Submit</button>
       </form>
   </body>
   </html>
4. Use the body’s tag onload=”" attribute.
   This doesn’t work for the same reason as the previous issue – the load event is never fired when the page is read from Firefox’s cache.

Solution, part I

So, the problem is that Firefox loads the page from its cache, and doesn’t process it the way a normal page is processed, and therefore – the onload/ready events are not raised.
There is, however, one event that does get raised: this is the pageshow event.

The pageshow event is raised by Firefox whenever a page is shown, regardless of whether it is loaded from the cache or not.
You could use it like this:

You don’t have to add a selector to Firefox, because other browsers (Except Safari which uses it in the same way) will just ignore it, as they never raise the event.

If you want to make sure that the code only runs when it is indeed a page loaded from the cache (and not when the user actually accessed your server), then you could add the following condition:

event.persisted will only be true when the page was loaded from persistent storage (the browser’s cache).

But I am using a page template!

In most frameworks, you use some sort of a page template. This has two implications on using onpageshow:

1. Adding onpageshow to your body tag will add it to all pages, and most of them will not have a button with the relevant id.
2. You may not know in advance what are the ids of the disabled elements you wish to re-enable.

There is a possible solution to this problem as well:

In here, I defined two javascript functions. The first one, disableMe() is used to disable an element like so:

The disableMe() function sets disabled=true on the element, and also sets ‘markDisabled’ to true. Note that markDisabled isn’t a real attribute name, and we just add it to the element as a marker. The reason is that you might not want to willy-nilly enable all of the disabled button elements when the user clicks the back-button, as some of them may be disabled because of other reasons (e.g. because the user hasn’t checked a specific checkbox).

The last thing disableMe() does is register the pageShowHandler function as an event listener for the pageshow event. This way, the event is only handeled when it is actually needed. Neat, eh? only pages that require pageshow handling because we manually disabled a button, actually receive it. (If you wanted to, you could test for Firefox here, and not do anything if the user’s browser is different).

Now, pageShowHandler is called by Firefox when the pageshow event is fired. Note that you have to define event as a parameter to the function, otherwise you won’t have it.
If the handler is called when the page is loaded from cache, pageShowHandler will locate all button elements on the page.
This is where the marker attribute comes into play. Note that the function tests for its existence and value – so it only enables buttons that were disabled by the disableMe() function.

The last thing pageShowHandler does is to remove itself from the page. It will get re-attached by disableMe() if needs be.

That’s it!

photo credit: johnb/Derbys/uk

In one of my projects, I have several customers all served from the same CakePHP application. This is by no means unique, and is a very well understood pattern of maintaining co-exiting websites. In my set up, each of the customers has their own website, with their own data and design, but there is only one copy of the actual application behind all those websites. This is, of course, a fundamental attribute of selling SaaS.

From a database point of view, there are three options of managing such a set up:

1. Add a customer identifier column to all your tables
2. Store a separate set of tables for each customer (normally using a table prefix)
3. Use a separate database for each customer

Each of these options require that your application can identify the relevant customer (not necessarily the user!)  on each request. This is very naturally achieved by using the domain name in the request.
So say we have the following layout, where all the following domains map to my application:

• mygreatcustomer.com.au
• anothergoodone.co.nz
• someoneelse.org.ag

In PHP, I can easily identify what domain was requested, using $_SERVER['SERVER_NAME']
When I can identify the domain (that is – the relevant customer) it is very easy to use option (1) above – just use the domain as the customer identifier column.
But what if you don’t want to use this option? What if you want to use option (2)?

CakePHP v1.2 let you do that. You could set the table prefix on the fly (in database.php):

//in database.php
var $default = array(
 'driver' => 'mysql',
 'persistent' => false,
 'host' => 'kiwihost',
 'login' => 'mate',
 'password' => 'secure_as',
 'database' => 'mydatabase',
 'prefix' => '',
);

function __construct() {
   $host = $_SERVER['SERVER_NAME'];
   $host = str_replace("www.", "", $host);   //remove www part
   $host = str_replace(".", "_", $host);     //a period is illegal in mysql table names
   $this->default["prefix"] = $host."_";     //so www.anothergoodone.co.nz translates into the prefix anothergoodone_co_nz_
}

But – the ability to do this dynamically has been removed in Cake 1.3, as table prefixes are now stored in the temporary model files. To fix this, you’d need to refresh those files on each new request, which makes the whole point of using those files moot. If you used option (1) to begin with – you’re in luck. But, if not, you might want to consider moving to option (3) – separate databases for separate customers.

From a maintenance point of view, there are many reasons why this isn’t necessarily the best choice, and I had a long discussion with Scalebase‘s Liran Zelkha about it – a discussion that I’ll post here at a later stage.
Anyway, say you decided you want to split your SQL data along the customer boundary using this method – let’s see how you do it in Cake.

First, you’ll want to split your data up into multiple databases. I suggest you name your databases to the domain name, replacing ‘.’ with ‘_’. This way – the change in the __construct() functionis very elegant.

Second, take the __construct() function shown above, and make this simple change:

function __construct() {
   $host = $_SERVER['SERVER_NAME'];
   $host = str_replace("www.", "", $host);  
   $host = str_replace(".", "_", $host);    
   $this->default["database"] = $host."_";  
}

That’s it, really. Your application now selects the database on the fly, based on the domain part of the HTTP request coming in.

But what if I don’t have an HTTP request?

Sometimes, you don’t have an HTTP request. In my scenario, this happens with cron jobs.
When you have a large number of customers, each with their own domain, you don’t always want to duplicate cron jobs just because they need to use a separate database.
Using table prefix – this was easy. Your cron job (well, a shell in Cake) just needed to cycle through the prefixes one by one. However, this is not as easy when you have
to switch to a different database with every customer, as you don’t have a request (so no $__SERVER) and database.php isn’t exposed.

In the old world of Cake 1.2, you might have stored a table of sites in your database (the only one with no prefix!) and used it like so:

//This is inside a cake shell
function main() {
    $sites = $this->Site->find('all',array('conditions' => array('Site.active' => '1') ));
    foreach ($sites as $site) {
        $table_prefix = $site["Site"]["table_prefix"];
        $this->setTablePrefix($table_prefix);
        //In the loop body - perform the cron-run for each of the customer websites
    }
}

function setTablePrefix($prefix) {
    //set the prefix on each of the models you use
    $this->Country->tablePrefix = $prefix;
    $this->City->tablePrefix = $prefix;
    //etc
}

However – this doesn’t work any more. In Cake 1.3 we are not using the table prefixes but rather a different database, so we have to use a different method:

//This is inside a cake shell
function main() {
    $sites = //whichever way you want to store your sites
    foreach ($sites as $site) {
        $newDbConfig = $this->dbConnect(array('database'=>$site,'datasource'=>'default'));
        $this->setConnection($newDbConfig);
        //In the loop body - perform the cron-run for each of the customer websites
    }
}

function setConnection($newDbConfig) {
    //set the DB config on each of the models you use
    $this->Country->useDbConfig = $newConfig['name'];
    $this->Country->cacheQueries = false;
    $this->City->useDbConfig = $newConfig['name'];
    $this->City->cacheQueries = false;
    //etc
}

photo credit: Free114

If you followed part 2 of this tutorial, you have an appengine application that displays a Google map in your browser, and lets you click the map to add markers to it.
While extremely useful on long, cold Winter nights, you probably want more from your application. For example, you’d probably like to be able to save those markers somewhere, so you can share them with your users.
This part of the tutorial will focus on this task. When you finish here, you’ll be able to add markers to your map, give your marker a title and a description, and save it to the appengine’s datastore.

This is what your application’s main page is going to look like:

You’ll notice a few changes from the page you developed in part II. Mainly – the map is now half the size of the screen, and there’s something that looks suspiciously like a data-entry form on the right side.
You are absolutely correct. The map on the left half of the page is the same map – only smaller in size, and I’ve added a form on the right to capture information about the markers you place on it.

First thing to do is to change the jsp file (DuckMain.jsp) to resemble the changes in the screenshot:

There are two main things to note here. First – I’ve added a CSS file:

This is not strictly necessary, but it’s good practice. the href is relative to your WAR’s file root, and now would be a good time to create this css file.
Under your war directory in Eclipse, create a css folder, and inside create a new file and name it main.css.

Granted, this is a very simple stylesheet, but you are free to play with it and change it as you like.
The #map_canvas style changes the size of the map so that it doesn’t take up the entire paeg anymore, and let’s you add the form on the right.

The following code inside DuckMain.jsp takes care of displaying the form itself:

This form doesn’t do anything yet, but that’s alright. All you care about right now is that your application’s main page displays something similar to the screenshot above.
Right-click your project and run-as a Google web application to verify that it works on your http://localhost:8888/ (or whatever port you use).

Populating the form

Now that you have your page set up nicely, you can move on to the next task – populating the form. Specifically, what you want to do is get the application to auto-populate the longitude and latitude fields when you add a marker to the map.

Why would you want to do that? Well – that’s the best way to save a marker’s data to the data store, and it’s not something you should expect your users to provide themselves. Additionally, just to be nice (and give your user some sort of feedback that they placed the marker at the right spot on your map) – we’ll auto-populate the address field as well, with the address corresponding to the marker just placed.

Doing all this is actually quite simple. There are two changes to make. One to the init() function, and one to the placeMarker() function.

Let’s look at the changes introduced here.

1. Adding jQuery
   This line loads jQuery on your page. While not completely necessary, using jQuery allows us to dynamically modify the input fields in the form and populate them with the details of the newly added marker. This is further explained in (3) below.
2. Geocoder is a Google Maps API v3 class that lets you find a physical address corresponding to a LatLng (latitude and Longitude) object. 2b is where you initialize it so you can later use it at point (3)
3. Ok, this is where the magic happens.
   As you may recall from part 2 of this tutorial, the placeMarker() function is called when the user clicks the map to add a location-marker on it.
   While inside this function, the position of the marker is known. It is passed as the location argument to the function.
   The following lines use jQuery to write the values of the location’s latitude and longitude values into the fields on the form.
   $("#longitude").val(location.lng());
   $("#latitude").val(location.lat());

   They do this by locating the HTML elements with the ids of longitude and latitude and changing their values to be the longitude and latitude values from the location argument respectively.
   These ids correspond to the longitude and latitude input elements in the form.

   This leaves us with the Geocoder code:

   geocoder.geocode( { 'latLng': location}, function(results, status) {
       if (status == google.maps.GeocoderStatus.OK) {
           $("#markerAddress").val(results[0].formatted_address);
       } else {
           alert("Geocode was not successful for the following reason: " + status);
       }
   });

   This piece of code uses the Geocoder mentioned before, to find the physical address corresponding to the latitude and longitude of the marker just placed on the map.
   Geocoder’s geocode method takes the location argument (which is a LatLng object), and a function definition. The function is called by the broswer on Geocode’s return from service, and takes two arguments: the results (which is an array) and a status code.
   Inside the function, it’s a good idea to first check the status code. If Geocode succeeded, you’ll get an OK status. In this case, using jQuery again, the function places the formatted_address returned into the input field whose id is markerAddress.
   If for some reason Geocoder failed to return an address – an alert is displayed to the user.

So far so good?

It is time to test the application, to ensure that all is working correctly.
Run your application again, and navigate to http://localhost:8888 (or wherever it is your application gets deployed to). It’s probably a good idea to zoom the map in a little bit, but you don’t absolutely have to do it.
Click somewhere on the map, and if everything works as expected, you should have a new marker added, and the three form fields (latitude, longitude and address) should get populated with the data corresponding to your marker. For example – say you placed your marker on 56 Brownston Street, Wanaka (the location of the fantastic Matterhorn South in New Zealand). You should get something similar to the following screenshot:

Saving data to the data store

Placing markers on the map and finding their location and address is all very well. But you probably want to do a little bit more with the markers you place. This is where the appengine’s datastore comes into the game.
This post is not about the datastore, and there’s a lot to write about it. For the purpose of this simple application, it’s enough to show how to easily save the markers data there.

I’ll use the JPA flavor of access, just because it is quite straight-forward. There are only a few files you need to add to the application in order to persist and read your data.

There are a lot of sources on the web for how to do this, I personally like Lars Vogel’s blog, and used his suggestions here.

First – create persistence.xml under src/META-INF in your project:

This will tell appengine to use JPA for your application. Note – when using the local version of appengine (that is – when you deploy your application locally rather than to appengine itself) – your data store is found in your Eclipse’s workspace, under WEB-INF, in a folder called appengine-generated. This is good to know, because when you make changes to your models and nothing works anymore – you need to remember to delete the files under this folder, to let your local appengine environment re-generate the data store with the new models structure.

After you sorted persistence.xml out, you need to add a way to hook into the EntityManager, and a model too:

EntityManagerService

The EntityManagerService class is a simple Singleton, that lets you (via the get() method) acquire a handle to an EntityManagerFactory. The factory will be used later to getn EntityManager instance – where all the good things happen (well, at least as far as the data store is concerned).

Now – the model. We’ll name our model class Duck, as the application is really about spotting ducks in the wild (if you haven’t figured it out yet…)

Duck.java

There’s not much to this class. It’s only worth noting that the @Entity annotation tells the appengine that this class is an entity worth persisting, and the duckId plus its annotations – which designate this field as the primary key for the Duck entity, and tell appengine to generate it itself.

To actually save your ducks (or, the markers we place on the map…) – you’ll need to create one more class: a servlet that listens for the form-submission on DuckMain.jsp, and persists the data to the data store.

NewDuck servlet

As promised, this is a very simple servlet, which only has the doPost() method. This is important, because we only expect the servlet to receive an HTTP POST method (via the form submission on DuckMain.jsp)

The servlet acquires an EntityManager instance using our EntityManagerService class. It then creates a new Duck object, and sets its values based on the request parameters it received. (Note that there’s no validation made on these parameters, you are welcome to add it if you want).

After the new Duck is ready, the servlet tries to save it to the datastore using EntityManager’s persist() method. After all is done – the servlet redirects the user back to DuckMain.jsp.

There’s only one more thing to do in order to tie it all together, and that’s mapping the NewDuck servlet in web.xml.

The first snippet you add to web.xml define a new servlet in the system: NewDuck. Note the servlet-class definition – it may be different for your code if you used a different package.

The second snippet maps the NewDuck servlet to serve the /new URL requests. If you look back at DuckMain.jsp, you’ll see the following line:

This defines the target of the form (that is – the URL it will try to submit to) as /new. Working together, web.xml and DuckMain.jsp tell appengine that when the form on DuckMain.jsp is submitted, it should send the HTTP POST request to the NewDuck servlet.

Verify that it works

Try and redeploy your application. Before the last batch of changes, you saw that when you add a marker on the map, the application populates the latitude, longitude and address fields. Do it now, and add a title and description. Click on Save, and if everything works – you should be redirected to the (empty, and centered on the Wanaka Bakpaka) DuckMain.jsp page.

Seeing your saved ducks

If you did this, then it probably all works, but you’re wondering – did my application really save the marker’s data?
Well, let’s verify that!

To verify that your ducks are saved, you’ll add one more servlet to your application – a list servlet:

ListDucks servlet

Quite the simple servlet this one.

Note that, unlike what you did in the NewDuck servlet, in ListDucks you are providing a doGet() method. This makes sense, because this servlet only lists data – it doesn’t create or change data on the server.

Inside the try block, the servlet tries to retrieve all Ducks from the data store into a local ArrayList object.
After that, if the query returned actual Ducks – the servlet iterates over the Duck objects, and prints out the title and address the user entered for each Duck.

To see this servlet in action, you’ll need to go back to web.xml and register it with the application:

As before – you define the servlet itself, and give it a servlet mapping. Unlike the case of the NewDuck sevlet, the url-pattern for this servlet-mapping does not depend on anything. I chose to define it as /list but you can change it to a different mapping if you like.

When you redeploy your application and point your browser at http://localhost:8888/list – you should see the ducks that are already registered in your application. (Something like the following screenshot)

And that’s it for this part of the tutorial. In the next part – you’ll see how to load the Ducks from the data store so that you can display them on the map, and add those nice little baloons to them as well.

photo credit: pedrosimoes7

In this part, I’ll show how to get started with STS (SpringSource Tool Suite) and Spring MVC. We’ll only use the default project that STS generates, but it’s a good start to any development effort with Spring MVC you might get into.
STS is the easiest IDE to use when developing Spring, mainly because it bundles together almost everything you need to get started, and knows where to get the rest.
If you don’t have STS installed, just download it from SpringSource’s website here and install it on your machine.

When you get STS up and running for the first time, it will ask you (as all Eclipse distributions do) which workspace to use, and then open the welcome screen. You don’t need the welcome screen. What you want is the dashboard.

From the dashboard screen choose Spring Template Project. This will open the following view:

Choose a Spring MVC project.
The first time you do it, STS might ask you to download some extra elements from the Internet. Let it download – it will not bother you again.
You’ll need to give your project a name and a top-level package:

Click on finish – and STS will create the project for you. You can run the project by right-clicking it and selecting ‘run on server’. This will open the following dialog:

The Fabric tc server was created for you with STS. Later you might want to change it to Tomcat or another server – but for now this is alright.

Choose the server and click on next – you’ll see the following:

This dialogue lets you choose which projects you want to deploy on the server. As GoodProject is the only project in the workspace – it will be the only one here, and automatically selected for deployment because you selected it to run on the server.
Click on “Finish” to launch the server runtime. STS will ask you if you want to use Spring Insight. You can activate it if you like, but most of the times I tried that – you get an error and the server fails to start. To fix this error you’ll need to delete the server in STS and create a new one – so you might as well not activate it.

If everything went smooth, STS will open the home page for GoodProject, Which displays an hello world message with the current server time.

Ok, so at this point – you know that you have everything working. Granted – you didn’t really have to do much – all you did is create a default Spring MVC project in STS and run it.

The New Spring MVC project template created all the things you need to have a Spring MVC project running. This comprises a few files, and the rest of this tutorial is dedicated to reviewing them.

home.jsp

The first file I want to discuss is the home.jsp file. This file is the default view generated by the new Spring MVC project wizard. Currently, this is the only thing a user will see when they access your application on the server, so it is a good place to start.

home.jsp is a JSP file. In Spring MVC, you don’t have to use JSP as your view technology. Most projects I worked on actually use JSF, but it doesn’t matter much as far as the Spring framework is concerned.

This is what home.jsp contains:

On the left side of the screenshot you can see the code in the JSP file. On the right side – you see how this code is displayed in a browser.

The first two lines of the generated JSP page are general JSP declarations: setting up the standard tag library, and declaring that the page does not use the HTTP session. Those lines are not important for us right now.

In fact, the entire JSP page is just some plain HTML which should be quite straight-forward to read. The only piece that’s interesting is the part that reads ${serverTime}.

As you can see on the right, Spring replaces the ${serverTime} phrase with a date and time string. Don’t go looking for it through the JSTL reference though – it’s not a tag. We’ll touch more on this when we talk about the controller, but for the completeness of the home.jsp discussion – it’s enough to say that serverTime is a property set by the controller and used by the view. (Just like CakePHP and other MVC frameworks, Spring MVC lets your controllers pass values to use in your views).

That’s it really for home.jsp. The only other thing worth noting at this point is that it doesn’t have a link to a css file. That’s alright.

Ok, so now you know what the home.jsp file contains. It is a simple view, that uses a value given to it by the controller. It is now time to look at this controller and see what it does.

HomeController.java

The first thing to note about the Controller is that it is really just a simple class. In Spring MVC 3 – you don’t need to make the controller extend or implement anything. However, you have to annotate it with the @Controller annotation. (line 17)

This annotation lets Spring know that this class is actually a controller, and set it up correctly at deployment time.
Line 20 shows you how to acquire a handle to a logger. This is a normal slf4j logger that Spring provides you with. Don’t fret about it.

Line 26 is where the interesting part begins. The generated controller has only one method – the home() method. There’s no mandated relationship between the name of the controller (HomeController) and the name of the method, or its return value (which we’ll get to soon) – Inside this class – all of them are more or less arbitrary. The return value could be any other String (however – you need to make sure it can be matched to a view. We’ll see in a bit how the “home” return value is mapped to the home.jsp).

The method home() is annotated with a @RequestMapping annotation. This tells Spring that this method handles requests coming in from the user. The @RequestMapping tells Spring that this method should be used to serve requests coming in to the ‘/’ context (or the home/root context for the application), but – it is restricted to HTTP GET requests only.
This restriction isn’t very important for the default home.jsp page, as there’s no way to change the server’s data status with this page. However, sometimes you’ll want to restrict specific methods to server only POST requests (so, for example, to make sure the user fills out a form rather than craft a GET request to your website) – and that’s where this option comes in handy.

The home method generated by the template takes two arguments: A locale and a Model. Note that this is not set in stone. Just as the name of the method is flexible – so are the arguments and even the access modifier (it’s true. Try removing the Locale argument or changing the method to be private – your application will still deploy).

To understand why this works – we need to delve deep into the way Spring-MVC does things, and it’s probably a good subject for a different blog post altogether. For now it is enough to understand that because we don’t actually call this method directly (the container calls it for us when the relevant request comes in) – then it is the container’s responsibility to match the call it makes to the method’s signature. If we define a locale – the container (using the DispatcherServlet and its adapters) will find the locale sent by the HTTP headers, and pass the home() method a matching Locale object. If we were to change the method signature to only take a model – well, the Spring container will not do that (you’ll still be able to find the Locale, by the way, but if you need it inside the method – might as well add it to the signature).

So, that’s settled then, for now. Let’s agree that there are a multitude of possible method signatures that are able to serve as controller methods.
The first thing the home() method does (line 27) is log the Locale it discovered. You should be able to see this logged in the server’s console window inside STS:

As you can see, the last line in the server log is the INFO log message, detailing the locale I used to access the home() method.
Lines 29-32 create a formatted date String. This String is actually what the home.jsp page displays using the ${serverTime} directive we saw before. How does it do that?
Well – line 34 actually takes care of that:

Spring-MCV is (surprise?) an MVC framework. We’ve already seen the view (home.jsp) and the controller (HomeController.java) – surely you’d expect Spring-MVC to provide a model as well.

Remember home()’s method signature – it had a Model object inside it. This Model is supplied by the container to the controller method. The method uses this model to communicate with the view.
Model is a Spring interface:

As you can see, the Model interface as far as the code is concerned, is a Map of attributes. The home() method uses the Model in line 34 and adds an attribute to it, using “serverName” as the key, and the formatted date string as the value.
This model is available to the home.jsp view we discussed earlier. In the view, you can use the ${…} notation to ask Spring to replace the attribute’s key with its value.

The JSP is processed on the server side before being sent to the client’s browser. During this processing, the server finds the ${serverTime} directive, and replaces it with the Model value corresponding to the serverTime key.
You can verify that this is what actually happens by trying to change the key to a non-existent one. You don’t have to redeploy the application if you only change a JSP. Just refresh the page, and see for yourself:

If you change ${serverTime} to something else – e.g. ${noTime} – the JSP processor will not find the key in the Model, and will silently fail – the time string is still there on the Model, but it isn’t found, and isn’t displayed on the page. Now change the bad value back to ${serverTime} and refresh the page – the time String should re-appear.

The last line in the home() method (line 36) returns a String to the caller: “home”. This String is used by the
container to decide which view it is supposed to render for the user, using the model.

So, to sum up so far: you define a controller using the @Controller annotation, and inside this controller you define a method that handles a specific request (an HTTP GET of the ‘/’ context).
Because of these annotations, when a request comes in to this URL, the Spring container knows that it needs to serve it using this controller and the specific method inside it.

The method does some work, and then returns a String. This String (“home”) lets the container know where to go to after the controller finished processing the request. In the case of the generated code, the container will use this String to decide which view (JSP file) to render back to the client.
Let’s see how this works then – the servlet-context.xml file.

servlet-context.xml

servlet-context.xml is used by Spring-MVC to configure navigation, beans and view resolvers. The file name does not have to be servlet-context, but this is the default configuration and it’s good enough for this tutorial.
The full picture is this: Spring-MVC uses a special servlet called DispatcherServlet to control and serve all requests to your application. To integrate with the servlet container, this DispatcherServlet is configured in the normal web.xml file like so:

As you can see, the servlet is configured very much like any other servlet you’d configure in a normal web application. It is given a default name: appServlet, and it is configured to serve all requests coming to the ‘/’ (root) context.
The org.springframework.web.servlet.DispatcherServlet is configured with an init-param that points to the location of its configuration file. This file Is the servlet-context.xml.

When the application is deployed, your servlet container scans web.xml for (among other things) servlets to load. It finds the DispatcherServlet with the highest priority for load-on-startup (load-on-startup tells the server container in what order it should initialize the servlets it encounters. The lower the number – the earlier the initialization will happen. The lowest meaningful value here is 1).

When the DispatcherServlet is initialized by the servlet container, it looks at its init-param, and finds its contextConfigLocation, which points to the servlet-context.xml file. As I mentioned before – you may change the name (or the location) of this file. As long as you configure it correctly in your web.xml – you should be fine.
Ok, back to servlet-context.xml:

There are a few important things to note in this configuration file:

1. The <annotation-driven /> element.
   
   This element tells the DispatcherServlet that it shouldn’t expect controllers to be configured in XML, rather – it will get its components via another method. This method can be found further down the file: <context:component-scan base-package=”com.duckranger.goodproject” />
2. <context:component-scan base-package=”com.duckranger.goodproject” /> tells the Spring container where it can find components. In this case, the directive tells Spring to look for components in the com.duckranger.goodproject package. Spring will scan this package and will register as a component any class it finds annotated with the relevant annotations (e.g. @Controller).
   So, together with <annotation-driven/> – these two directives ensure that Spring finds the HomeController class and registers it as a controller in the Spring-MVC application.
3. The final element worth noticing in this file is the definition of a ViewResolver:
   
   <!-- Resolves views selected for rendering by @Controllers to .jsp resources in the /WEB-INF/views directory -->
   <beans:bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
       <beans:property name="prefix" value="/WEB-INF/views/" />
       <beans:property name="suffix" value=".jsp" />
   </beans:bean>

   A ViewResolver is another Spring interface, which is responsible for directing a client to the right view in the application.

A bit about view resolvers

Generally, a controller method should not return just a String. It should actually return a ModelAndView object, which contains both the model we discussed earlier, and the view to resolve (or rather – a way to find the view).
However, as you can see, in our generated Spring-MVC project, the controller method returns only a String, which contains the view name. This is alright, as long as we tell the container how it should resolve the view and serve the correct page to the client.

The InternalResourceViewResolver does exactly that. It is configured as a bean, and since it is the only view resolver configured, the Spring container knows that this is the one it should use. In essence, the InternalResourceViewResolver receives the result of the controller method (the String returned) – and is then in charge of mapping this result to an actual view.

In the definition above, we define two properties on this resolver bean: a prefix and a suffix. The InternalResourceViewResolver concatenates the prefix, controller-return-value and suffix to come up with the actual view name to display. In our case, this will be /WEB-INF/views/home.jsp.

Using this information, it finds the right JSP page to load, processes it using the model object (same Model object in the home() method) – and sends a response back to the client.
You can verify that this is the way the InternalResourceViewResolver works by changing a few values and watching the result. Try the following:

Change the return value of the home() method to be “duckranger”, save the HomeController class, wait a few seconds until you see the server has redeployed (It will echo INFO: Reloading Context with name [/GoodProject] is completed in the console) – and refresh the STS browser page – it should show the error:

Which makes sense, as there’s no duckranger.jsp page.

You can also try and change the prefix or suffix in servlet-context.xml (you may have to manually redeploy for this change to take effect, though). If you change the suffix from value=”.jsp” to value=”.duck” and try to access your application, you’ll find that the server complains.
In the server log (STS console) you’ll see the following:
WARN : org.springframework.web.servlet.PageNotFound – No mapping found for HTTP request with URI [/GoodProject/WEB-INF/views/home.duck] in DispatcherServlet with name ‘appServlet’

So, now that we’re satisfied that the view resolver indeed resolves view – there are only a couple of files left in the project – the log4j.xml and pom.xml configuration files. These are your maven build and log4j configuration files, which are not strictly a part of the Spring-MVC and are beyond the scope of this tutorial. We don’t care much for them right now.

Part I Summary

In this part youjust went through the real basics of Spring MVC 3.0. Set up the STS development environment, created the template Spring MVC project, and investigated the files that got created.
Generally speaking, the control structure of a Spring-MVC application is quite simple:

1. You start by hooking up Spring’s DispatcherServlet as the main entry point to your servlet container. This is done in web.xml, like you define any other servlet, with the exception of specifying a configuration file in DispatcherServlet’s init-param.
2. The DispatcherServlet’s configuration file tells the Spring container where it can find its controllers, and configures a view resolver to handle the values returned from the controller methods, and resolve them into the right views to display.
3. Once you have this sorted, all that’s left to get a simple application up and running is to create a simple controller and a simple view.
4. The DispatcherServlet finds the controller by its @Controller annotation, and by its being part of the relevant package configured with the component-scan element in its configuration file.
5. Using the @RequestMapping annotation, the DispatcherServlet known which controller method it needs to call when a request comes in to the ‘/’ context.
   The DispatcherServlet calls this method – home() – and gives it a Model to use for passing data to the view.
6. The home() method then returns a String – “home” – that’s used by the view resolver to resolve into a JSP page to render and return to the client.

That’s it for today… In the next part of the tutorial, I’ll talk about some more things we can do with Spring MVC.

photo credit: pasma

Google’s appengine is the Google cloud offering. It is highly scalable, and provides a free entry level cloud application platform. However, it is not very trivial to develop for and deploy on.
Google maps API version 3 is the current (June 2011) officially supported version of integrating with Google maps. The API allows you to display and manipulate maps in may ways.

The full tutorial provides an introduction to developing and deploying a simple maps application to the appengine using Eclipse. Part 2 walks you through creating a simple project displaying a clickable map using the googlemaps API v3.

In the previous part of this tutorial, we set up Eclipse to work with a local appengine-like environment. In this part, we’ll create a small application that displays a map on the screen, and lets the user interact with it by clicking the map and adding data to it.

Start with a fresh project

If you followed the first part of the tutorial, you have a working appengine project. We used it to verify that everything works. However, we are not going to use it in this second part. Close the project and create a new one (Using File->New->Web application project). Give your project a name and package – but do not select to use GWT or generate any code.

Plain vanilla appengine project

This should generate a plain vanilla project that’s appengine ready, but has only a little bit of code in it. The following Project explorer screenshot should resemble yours:

Project Explorer - default project/

What did the plugin generate?

The plugin generated for you the blueprint required for an appengine project. You can actually run the project you just created (right click the project and select Run as->Web application). If you followed the previous part of the tutorial you’ll notice a small difference: this time Eclipse does not open an Development mode view. All you see is the console telling you it started a local server:

Appengine console view

Open a browser and point it at http://localhost:8888 (your console might show a different url) – and you should see an Hello App Engine! page that lists one available servlet. Click it, and you’ll see the default application:

Default servlet

What’s in my generated code?

If you look into the code generated for you, it isn’t very interesting. The Duckranger_MapsServlet class (the actual name depends on the project name you entered when you created the project) – contains the following code:

All it really is a simple Servlet that doesn’t do anything (except serve the request).

The other simple file the plugin generated is your WEB-INF/web.xml:

Again, nothing too complex. Just a servlet definition and mapping for your servlet.

Clean up and add a map

For the sake of our little demo application, we’ll make things simpler. You noticed that when you open your local appengine environment, the server greets you with a little menu – telling you which applications are available. This is nice when you are developing a few apps concurrently, but to be honest, it gets old quite quickly. Let’s remove it.
Open your WEB-INF/web.xml file, delete the servlet and servlet-mapping elements. This will remove the reference to the automatically generated servlet (Duckranger_maps). Delete that servlet as well from your src folder.

All that you should have left now is the welcome-file-list element. Let’s change the welcome-file to something else:

This tells the appengine to find the DuckMain.jsp file and serve it when the user navigates to your root context.
Important: don’t forget the .jsp suffix here, otherwise you’ll get a 403 error when you try to access your application..
You’ll also need to create this file, in the root of your war folder. The following jsp contains a special div with the map_canvas id. You will use this div to display the Google map.

If you run this code on your server and browse to the application (normally http://localhost:8888) – you’ll see a huge google map centred on Wanaka, New Zealand, more specifically, on the cozy Wanaka Bakapaka.

Let’s go over the comments in the source above:

1. This line tells your page to load scripts and other resources associated with Google maps (api v3). Notice the ?sensor=false parameter. This tells the Google javascript code that your device will not provide its location. On some devices that have GPS abilities (e.g. an Android phone) – you could have this parameter set to true. In v3 of the Google maps API this parameter is mandatory.
2. As we don’t use a sensor to provide a location, we’ll supply a default starting location ourselves.
   The location is a google.maps.LatLng object, which holds information about the latitude and longitude values of a point on the map. In the example above, the initialLocation object is created to point to 117 Lakeside Road, Wanaka, on New Zealand’s South island – which is the address for Wanaka Bakpaka.
3. duckOptions is a javaScript variable we use to hold the map options. We define the zoom level (higher is more detailed), the map’s center location, and the type of map. Note that you must define the map type in v3 of the API (you didn’t have to in v2).
4. We create a new map, and tell it to load itself in the div with the map_canvas id. We also pass the duckOptions variable we created earlier, to tell the map how to create itself.
5. Using a google.maps.Marker object, we place a default marker on Wanaka Bakapaka. Later in this tutorial we’ll see how to change the icon for the marker, add information pop-ups, and place markers ourselves.
6. This is how we tell the browser to run the init() function when it loads our web page. If we don’t specify this – our map won’t load (of course there are other ways to achieve this, e.g. jQuery’s ready() function, but this is not the case here).
7. Remember in (4) we told the map to load itself in a div with the id map_canvas? well – here it is.

Click to add a marker

The last thing we’ll do in part 2 of the tutorial, is let the user add a marker on the map.
To accomplish this, the map needs to be able to listen to mouse click events. Add the following code to the end of the init() method in DuckMain.jsp:

The last three lines create a listener. The listener needs three parameters: the object to add itself to (in this case, the map), the trigger to listen to (in this case, this is a mouse click), and a function to execute when the listener is triggered.
The function will receive an event object, which contains the data exposed by the event.

In our code, we told the listener to execute the placeMarker function. We need to add it now.
Note: add the function outside the scope of the init() function.

Redeploy your application and navigate to it in the browser. The map should load as usual, centred on Wanaka Bakpaka. Now try clicking anywhere, and if you got everything correctly – you should see a new marker appear on the map.
The last line in the placeMarker function re-centers the map on your new marker. You can comment it out if you are not interested in this behavior.

Map with two markers

photo credit: -mrsraggle-

Google’s appengine is the Google cloud offering. It is highly scalable, and provides a free entry level cloud application platform. However, it is not very trivial to develop for and deploy on.
Google maps API version 3 is the current (June 2011) officially supported version of integrating with Google maps. The API allows you to display and manipulate maps in many ways.

The full tutorial provides an introduction to developing and deploying a simple maps application to the appengine using Eclipse. Part 1 walked you through setting up the development environment and testing that everything works.

Register to appengine

If you aren’t already registered to the appengine, do it before anything else. Registration is very simple – all you need is a Google (Gmail) email address and a cell phone. Log in to the appengine and follow the instructions for registration.
Note that you don’t actually have to register with the appengine to develop an application. The Eclipse plugin contains a local deployment environment you can use. But, since it’s free and easy – you might as well do it now.

Set up Eclipse

The easiest way to develop a Java application for appengine is with Eclipse. You’ll need the right version – The Eclipse IDE for Java EE developers.
Once you’ve installed it, you need to install the Google appengine plugin. Installing a new plugin is slightly different on different Eclipse releases, but if you’re using a new-ish Eclipse release (e.g. Helios) – you can do it by selecting Help -> Install new software… from the top menu.
You should see the following dialog:

Eclipse Install new software dialog

Once you’ve restarted Eclipse, you should see the appengine’s plugin buttons in your toolbar:

Appengine plugin buttons

Create your first appengine project

To verify that everything works, we’ll first create and test a default appengine project.
Create a new appengine project by selecting File -> New -> Web application project (The Web application project should have the little google icon next to it). Alternatively, you can create a new web project from the appengine button drop-down on the toolbar.
Give your project a name and specify a package. Leave everything else to its default values, and click Finish.

Eclipse new project dialog

Eclipse Development Mode view

Google Webkit development plugin

Once you’ve sorted all that, you should see the following page (well, unless Google changes the plugin’s default generated application code).

Web application successful deployment

Try and enter your name and click on Send. If everything is alright – you should receive some notification from the server telling you which browser it thinks you are using.

photo credit: Express Monorail

Coding a login screen is pretty simple in Android, and there’s quite extensive documentation on how to do screen development. However, there’s one neat little trick I wanted to use: the ‘next’ and ‘go’ buttons on the soft keyboard. These buttons are actions that let you move automatically from the login text input to the password text input, and then from the password text input, you can ‘click the login button’.
This is documented, but it isn’t very easy to find how to implement, so I thought I’d write it down.

The following shows what I mean. On the left, you see the soft keyboard with the Next button. Clicking it will move the cursor and focus to the password field.
on the right, the screen focus is in the password screen. Clicking on the soft keyboard’s Go button will mimic the action of the user clicking on the login button.

The login screen definition

This is the loginscreen.xml file I use under /layout

The two important things to notice are the android:imeOptions declarations on the user name and password fields.

On the user name EditText element, I define android:imeOptions=”actionNext”. This tells the keyboard that it should show a Next button, which then knows to move on to the next input field on the screen (namely, the password EditText).

On the password EditText element, I define android:imeOptions=”actionGo”. This instructs the keyboard to show a Go button.

The first IME option declaration works without further tinkering. However, the actionGo does not automatically knows what to do (It really only fires an ‘Enter’ KeyEvent).

There are two things you need to do in order for the Go action to ‘click the login button’.

The first thing is that the password EditText element needs to be configured as a single-line input. Otherwise, the ‘Enter’ key event will behave as a new-line. This is configured in the xml above with the android:singleLine=”true” attribute.

The second thing to do is to tell the LoginScreen Activity what it needs to do when the user clicked the Go button on the soft keyboard. This we do in code:

Everything here is pretty normal for an activity.
Note that it is not best-practice-ish to have the activity implement the OnClickListener interface, but for brevity sake – I did it here, and I attach the activity itself as the listener to the login button’s onclick.
When the login button is clicked, the activity creates a login service and calls its execute() method to test the login credentials supplied.

The important piece of code is the the line that sets an onClickListener on the passwordText element.
Inside the listener’s onKey method, we test for the key the user pressed. Remember that the Go button generates an Enter keypress. This corresponds to the KeyEvent.KEYCODE_ENTER constant.

When the listener identifies that the Enter key was pressed, it fires the activity’s onClick() method – as if the login button itself was clicked.

That’s it, really.

photo credit: ViaMoi

Working on a new project, I had a few chats to people and realized that many developers assume that to work with JAXB you need to have an XML schema.
This is not true. If you have the schema, go ahead and use it, but if you only have the XML files you want to parse, JAXB is perfectly capable of unmarshalling your XML into objects without the schema and the binding.
The only problem is – you’ll have to code the binding classes yourself. However – this isn’t always a bad thing. Coding the classes yourself lets you take some good shortcuts, disregard elements you are not interested in, and control behavior better.
I would like to add that you usually end up manually editing the generated classes anyway – so if your XML files are relatively simple – might as well do it the old fashioned way.

An example

Let’s consider the following XML document:

A very simple XML file. right?
To parse it using JAXB, we need to tell the unmarshaller which classes are present. The rule of thumb is simple: If an element contains other elements – it is a class. However, if it is a leaf-element – it will be a member of the containing class.

Following this rule, it is obvious that User is a class. It contains everything else. However, name is not a class – it will be a member of the User class.

So how will it look like in code?

Program.java

The inner-most class describes the program element.

There’s really not much to this class. It is the inner-most level we are getting to inside the sample XML document. Let’s move on to the next class:

Programs.java

Programs is just a container class for Program elements.

The Programs.java class is a container – it holds a list of Program objects. This is not absolutely necessary (You could have the User class hold the list of Program objects directly) – but it is clearer this way.
Note that in the getter annotation I use the name “program”. This tells JAXB that the list used here maps to elements
with the name “program”.

User.java

The User class contains the attributes that are leafs inside the xml file. It also contains a reference to a Programs object, which provides a list of programs.

With all the classes set, all that’s left is to create a driver – something to unmarshall the XML file:

Unmarshal.java

In the simple code above, there are 3 points to notice:

1. The first thing you need to do is create a JAXB context. The simplest way to create it is using the base class for the XML file (as shown above). You can also create it more generic by pointing it to the package.
2. I then create a User object from the file.
3. Using the sophisticated toString() methods on all classes shown above, the final line in the main method will print the following (for the XML file provided) :

photo credit: shoothead

This teknoid blog post describes an excellent method of refining Cake’s default error handling.
Quick reminder: by default, if your debug level is set to 0, cake will always redirect your user to the error404.ctp under app/views/errors).

Edit Jan 5, 2011: The information in this post is for Cake 1.2/1.3. See COTP’s comment below if you’re using Cake 2.0 or newer.

I recently had an issue with the 404 error page in an application I’m coding.
The application let’s a user log in to the system, and after a user logs in, there’s a box at the top right of the screen that displays the user’s name like this:

My application's login information box

When I go to a non-existing URL, CakePHP redirects me to the error404.ctp page, as expected. However, as none of my controllers is involved (and especially not my app_controller which sets the logged in user name for default.ctp) – the login information does not exist, and my 404 page looks like this:

My application with no login information

This saddened me to no end. Actually, it saddened my Business Analyst, and I do not like it when he’s unhappy. I therefore read and re-read the aforementioned teknoid’s post, until I found a silly hack that does the trick:

All app_error.php does is take control of error handling from Cake’s default. All I do in it is redirect the incoming request to the /error404 path.
In routes.php, I connect /error404 to a specific controller/action pair:

And in bulls_controller.php – just add an empty error function:

Last – add the error.ctp view:

And that’s it! Now, when the user enters a non-existing URL, Cake is going to redirect it to the bulls controller. Because of this, I regain the user’s context in my error page!

(Note, there’s probably an easier way to do it, but the point is, you can use this technique whenever you set up some data for your default template that you wish was available for your error page as well).