Nothing Too Serious

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>
     Home
   </a>

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?

Continue reading

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!

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.

Continue reading

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.

Continue reading

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.

Continue reading