Surprise

I was washing the dishes after dinner tonight. I was going to put the cuttlery away when I got surprised.

I love you son!

Sokoban

My wife and I were having dinner tonight. As it usually happens out little son finished quickly and was getting restless. So we put him down from his chair and carried on with our meals. Soon after he pulled his chair from the table and pushed it to the door that leads to our backyard. I kept an eye on him, just like any parents would do with a boy who is always up to something. So he pulled this chair to the door, climbed on top of it and the victoriously stood on it, giving me the biggest smile he could. His eye were saying "Look dad! I did it!"

Then I realized what he was up to. He put his little hand up and tried to reach for the air-conditioning unit above him. Near the ceiling. I was impressed with the little guy’s thinking. He used the same logic we (big guys) would use to reach to places that we naturally cannot reach as our bodies do not extend that far. He just underestimated the distance. He is only two. Almost. I praised him for his effort and I told him that he’s done well and he will get there but it may take a few years until he is big enough.

At that very moment I realized that for these little ones with no limits, no boundaries pre-set in their minds the sky is the true limit.

After I asked him to come down (just to be safe) he started pushing that chair around. He maneuvered with it around the kitchen and eventually made it to the very spot he took this chair from. Sokoban! The only movement my son decided to use was to push the chair. It was fun for him, as well as for me watching him. When he made it do the destination, it dawned on me. He just performed a real-life version of Sokoban. Wow! The kiddo is smart and I wish I was back in 80-ties to re-invent the popular computer game :-)

Don’t limit your kids. Let them explore, invent and make up their own rules for this world they live in.

404! Why? Where from?

Alright, so you got 404'd! Things aren't that bad because you handled it nicely, but the real question you have on the tip of your tongue is "What URL caused this 404?"

The request could receive the following attributes that can indicate what caused the error

Where did it come from?

To get the original URL of the request that is in trouble, look at javax.servlet.error.request_uri request attribute.

String uri = (String) request.getAttribute("javax.servlet.error.request_uri");

What caused it?

To cause of the error can be a HTTP error or an exception that was not handled by the web application and propagated all the way up. The three attributes that will give you more insight are:

• javax.servlet.error.status_code:
  An Integer telling the error status code, if any
• javax.servlet.error.exception_type:
  A Class instance indicating the type of exception that caused the error, if any
• javax.servlet.error.message:
  A String telling the exception message, passed to the exception constructor
• javax.servlet.error.exception:
  A Throwable object that is the actual exception thrown

Handling HTTP 404 - Page Not Found

If you develop web applications, you are most likely familiar with Java Servlets and Java Server Pages (JSP). JSPs can be accessed by a path that directly relates to their relative location to the web app's content root directory. Servlets however are typically accessed via path that match URL patterns defined for each servlet in the servlet mapping element of the deployment descriptor (web.xml).

What happens if a user types in a URL that will reach your web application, but does not map to to any of your servlets nor JSPs? Most likely this occurrence will be handler by the servlet container itself by sending HTTP 404 code back to the user's browser. A 404 page will be displayed. 404 is a HTTP response status code that indicates that a resource could not be found but may be available again in the future. Most of the servlet containers do not serve user-friendly 404 pages.

You are better off handling 404 by the web application itself. The content of the 404 page can be then customized to suit your web application's needs. You could take a funny approach or present something more helpful, e.g. a sitemap.

Example from YOU & I tee - couple t-shirts:

So how do we do this?

Step 1 - Create error page description

Add an error-page element to your web applications deployment descriptor. Open web.xml file and add a section like the following:

<error-page>
 <error-code>404</error-code>
 <location>/error404.jsp</location>
</error-page>

Step 2 - Create error JSP

At the location as specified in step 1 create a new JSP file that will serve the content you desire. And that's it really.

Handling exceptions

In a similar fashion you can handle uncaught exceptions that would otherwise end up in the user's browser. For example:

<error-page>
 <exception-type>java.lang.RuntimeException</exception-type>
 <location>/exception.jsp</location>
</error-page>

JavaZone Trailer: Java 4-ever

This is an absolutely awesome movie trailer!

...from the director of JAVATAR and .NOT

How to wire a constant in Spring

Spring is a great framework for dependency injection. It helps creating new instances and inject them with references to other objects via constructor arguments or setter methods.

To create a new instance of a class one simply declares a new bean

<bean id="firstDay" class="com.mypackage.Day">
    <constructor-arg type="java.lang.Integer" value="1" />
</bean>

But what if you do not want to create a new instance. Perhaps you already have a class with instances declared as publicly accessible constants (public static) and you just want to access them in the wiring process.

It's easy to get a hold of a constant. Simply use the following

<util:constant id="firstDay" static-field="com.mypackage.Day.MONDAY"/>

For this to work you'll need to include the following

<beans
    xmlns="http://www.springframework.org/schema/beans"
    ...
    xmlns:util="http://www.springframework.org/schema/util"
    xsi:schemaLocation="http://www.springframework.org/schema/util ..."
>

So there you go, now you have constants wired.

Xmas Party 2009

HotHouse had a great Christmas party at Peats Bite restaurant last year.

See the rest of the photos in my photo set.

jQuery and checkboxes

Let's start with a simple checkbox like this:

<input type="checkbox" name="foo" value="bar" />

To check whether this checkbox is checked you can do either of the following two alternatives:

$('input[name=foo]').is(':checked')
$('input[name=foo]').attr('checked')

To check the checkbox we can use the attr() function

$('input[name=foo]').attr('checked', true);

And likewise to uncheck it

$('input[name=foo]').attr('checked', false);

Leveraging Google to build your business

I read a nice post this morning about building business with Google by Eric at 過労死 Death by Overcoding.

It covers many aspects that may be involved in administering your business needs, such as:

• Domain registration/host/email/office apps
• Phone Management
• Blog
• The Application
• Payments
• AdWords
• Analytics
• Integration/Optimization

I recommend reading it to anyone who is starting up a web business. Following the steps mentioned in that blog post can be a real timesaver. And you do not need to hire an admin to do it all.

Detect an AJAX request

Many web applications use AJAX nowadays. In a typical scenario, one fills out a form, which is then submitted to the server. If you don't use AJAX or JavaScript is disabled, your form should still submit with no problems. And you receive a new page. If you use unobtrusive enhancement via JavaScript, the form is submitted to the server and the page is updated with the result without a full page reload.

While developing with Grails writing Java and Groovy code, I noticed that a typical pattern is to create two actions in a controller. One to handle normal HTTP POST (e.g. save action) and one to handle HTTP POST coming from an AJAX request (e.g. saveAjax action). The two actions are almost identical. They perform the same business logic. The only difference is what is returned from each action. A normal action renders a new page. An AJAX one returns whatever your flavor is: XML, JSON, HTML, plain text.

So is there a way to tell the requests (ordinary and AJAX) apart?

You guessed it, there is. AJAX request comes with a special header - X-Requested-With. I usually have my controllers to extend my BaseController, which has a couple of useful methods that I use. isAjax(request) is one of them. And this is what it looks like.

public static boolean isAjax(request) {
   return "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));
}

I hope you'll find it useful. The all you need to do in your action is this:

def save = {

    // business logic
    // ...

    if (isAjax(request)) {
        render([ /* data */ ] as JSON)
    }
    else {
        // render or redirect here
        render(view: 'save', model: [ /* model data */ ])
    }
}