Wednesday, December 30, 2009

REST-style URLs for older Java web applications using UrlRewriteFilter

Say you have an old old Java Web application that uses URLs like this:


You want your URLs to be pretty and more RESTful like so:


Well, you have two options. You can re-write your web application to use newer web frameworks that supports REST-style URLs such as Spring MVC 3.0, which will probably take months to do. Or you can use UrlRewriteFilter which should take no more than 30 minutes and will work with any existing Java web application.

UrlRewriteFilter very easy to use. You basically:
  1. Add UrlRewriteFilter as a servlet filter in your WEB-INF/web.xml
  2. Populate WEB-INF/urlrewrite.xml with mappings of REST-style URLs to the corresponding URLs of your legacy web application (with query params and what not).
 That's pretty much it.

UrlRewriteFilter is extremely powerful. It supports regular expression pattern matching, allowing you to perform pretty complex mapping. Check out the manual page for details.

Monday, December 14, 2009

Remove ifs/switches from your JSPs through feature labeling

In this post, I outline a technique I call "feature labeling" as a means of organizing your web application's HTML views into features that can be selectively enabled and disabled without unmaintainable if/switch statements. I will use JSP and Spring in my example though this technique can be generalized to any view technology that allows for custom tags and any dependency injection container.

Say we are writing a prototypical blogging web application. All blogging applications give authors the ability to edit a blog entry. One straightforward way to implement this is to check if logged user is the author of the blog and then displaying the edit link to the user like so:

<c:if test="${user ==}">
  <a href="/blog/233/edit">Edit Blog</a>
Months later, say we decide that the administrator should also have the ability to edit blogs. We can add an 'or' condition to the if statement like so:
<c:if test="${user == || user.role == 'admin'}">
  <a href="/blog/233/edit">Edit Blog</a>
The good developer, however, should see that we are going down the path of littering our JSP/HTML view with too much logic, which will ultimately become harder to test and less maintainable. The "right thing" to do is to push this logic to a middle tier.

First, remove the if logic and replace it with the custom JSP tag "dm:feature" (to be created) like so:
<dm:feature name="blogEditing">
  <a href="/blog/233/edit">Edit Blog</a>
Note the attribute name="blogEditing" which will effectively label the inside body as the blogEditing feature.

Second, create a custom JSP tag that will:
  1. Get a FeatureService object from your Spring web application context.
  2. Do a featureService.isEnabled(featureName) to determine whether the body should be evaluated or skipped.
Here is a tutorial that covers the topic of creating custom JSP tag. Hint: Extend TagSupport instead of creating it from scratch. Then to get the Spring web application context, do:
context = (ApplicationContext)pageContext.getAttribute(

Third, create your FeatureService interface and implementation. In this example, the implementation would need to be aware of the current user and the current blog so you can do the check "if current user is the blog author." Leave a comment if you want more details.

This should dramatically reduce unnecessary logic in your view and make it more testable because you are pushing the logic into a middle-tier.

Keep in mind that this only eliminates blog editing from the view. You still need to disable the controllers/services for blog editing as well. This is where Spring's Aspect Oriented Programming comes in. Here's a brief outline of what you need to do:
  1. Create an @Feature annotation that requires feature name (e.g., @Feature("blogEditing"). This annotation will basically label methods as being part of a feature.
  2. Create a FeatureAspect bean with FeatureService as a dependency.
  3. Create an around advice (method in the FeatureAspect bean annotated with @Around). This advice should check if the feature specified in the @Feature is enabled. If enabled, execute the method. Otherwise, throw a runtime FeatureNotEnabledException and add top-level handlers to redirect user to a 403 unauthorized page.
Note that the FeatureAspect uses the same logic (i.e., FeatureService) that is responsible for determining whether a feature should be enabled. There's no need to duplicate logic both in the view and middle tier.

Helpful? Let me know.

Wednesday, December 9, 2009

Usability findings: You look where they look -- False!

I came across this article on 10 Useful Usability Findings and Guidelines. Points listed are not too surprising. However, I disagree with #2. Essentially, the author is concluding that you can increase people's attention if you have a picture with a face looking at the target text. I think the "study" lacks the proper control to warrant such conclusion.

It could be that a frontward face draws attention away from the text. In other words, the frontward face has a negative affect on attention as opposed to directional face having a positive affect. A simple control stimulus with a face looking in the opposite direction of the text would have revealed whether a directional face actually increases attention. There should have also been a control stimulus of no face or a non-face image to establish a baseline.

The author is also concluding that glances directly translates into attention. The peer-reviewed eye tracking literature have shown that while this is generally true, there are many levels of attention that must be considered. The level of attention desired by content providers is one where the user is reading and comprehending the text, in other words, a high level of attentional processing. It could be the case that a significant number of the glances are accidental or reflexive glances as a result of being steered by the directional face. One way to tease out these accidental glances is to subtract the data from the first few glances across all the images. The glances remaining would be the more intentional ones, the ones that reflect higher level processing.

This is a demonstration of the lack of rigor in non-peer reviewed studies.