Archive for the ‘Web Applications’ Category


Ikea’s Thin Client Woes

Lots of people tout the benefits of web applications over old fashioned fat clients or desktop applications. Yes, I agree that it solves the problem of rolling out software upgrades and requires little or no installation effort because the user just needs a web browser. People do tend to ignore the disadvantages of thin clients however. With the advent of software as a service it might be worth looking at those disadvantages before jumping on the bandwagon.


Getting The Context Path (Without a HttpRequest)

Web programmers know that they shouldn’t go writing JSPs with the Context Path hard coded in them.

If you do the following:

<a href="/MyApp/path/to/controller/home.htm> Home </a>

You’ll notice that as soon as you decide to deploy your web application using a different name than “MyApp” then none of your links will work anymore.
To avoid this you need to get the context path from the HttpRequest object as follows:

<a href="<%=request.getContextPath() %>/path/to/controller/home.htm>

or by using a JSTL tag:

<a href="<c:url value="/path/to/controller/home.htm"/>"> Home </a>

What happens when you are rendering HTML in your Java code and you don’t have access to a HttpRequest object for whatever reason?



Detecting HTML5 Features in Javascript

How can you detect if your browser supports HTML5 features in javascript?  Here’s how:

function isHTML5CanvasSupported() {
    return (typeof HTMLCanvasElement != 'undefined');

function isHTML5VideoSupported() {
    return (typeof HTMLVideoElement != 'undefined');

function isHTMLClientSideDBSupported() {
    return (window.openDatabase);

Have fun!


Using EasyMock to Create Stub Objects

There are two competing philosophies with regard to unit testing strategies; state based testing and behavior based testing. In state based testing we configure a starting state, execute a test method, and then examine the resultant state/returned result. In behavior driven testing we ensure that our test object collaborates with its dependencies in an expected way.



How Anaemic Domain Models Cause Bad Software

Using an anaemic domain model is often considered an anti-pattern.  The reason for this is that it encourages coders to duplicate code needlessly.  This is going to be a fairly short (and fairly trivial) post explaining one of the mechanisms by which this occurs (with an example).  The mechanism can be avoided with careful planning and strict coding discipline but it is quite a lot easier to apply good encapsulation.  The difficulty with avoiding the pit falls of an anaemic domain increases exponentially as more team members work on the project.
None of this will be new for anybody with a moderate understanding of OOP, but it is interesting to see how a small number of fairly innocent steps can lead to a real mess.



Domain Driven Design with Spring and Hibernate

I’ve been playing around with Domain Driven Design (DDD) and trying to write a small web application without implementing an anemic domain model.  I have found that it is more difficult than it ought to be and I want to share some of my experiences.

An anaemic domain is something that happens in an enterprise application when your domain objects don’t really contain any real logic.  Instead the logic nearly all resides in a secondary “service” component.  This is an example of badly encapsulated code and will lead to messy, difficult to maintain applications.