I’ve always promoted a “standards” oriented approach to web development, meaning, a server side app that produces pure XHTML, styled with CSS, with Ajax added where appropriate. I’ve worked with GWT for some time and feel, while it is a tremendous product, it is essentially VB (ok maybe closer to Swing) for the web/JavaScript. It excels at building a desktop application look and feel. Contrast this with a more “web” look and feel, especially some of the sites associated with web 2.0.

I haven’t written a post for some time. I’ve been debating what client tool to use on quiz application. I originally planned on using Flex, figuring I could do a nifty interface and still integrate with Spring and Java on the back end. I also did some quick prototyping of CRUD screens in Spring MVC. It is amazing how easy it is to get simple HTML forms and data entry working  with that framework. I really like it and the philosophy behind it.

However, whenever I do HTML based apps, there is always the missing piece which is graphic design. I will admin that is not my strong point. I can do a passable job (see Domuswap.com archive), but it is not something that comes quick and easy to me. I would sure love to spend time learning photoshop, etc. I have no doubt that there are some nice approaches to easily styling HTML, I just haven’t stumbled across one that works for me yet.

So far, I can really get into Flex. I felt I was jury rigging the thing to get it to speak to Java/Spring. I wish Springsource would release an integration layer with GWT. I am sure it is coming. Not that is was that much work, but it is much more involved that what I’ve been doing for the past year with GWT. The client and server integration is so tight, you sometimes don’t realize on what side of the app you are.

The final blow came when I explored the excellent GWT add on library/framework, Ext GWT. The Web Desktop demo really blew me away. It is really just some nice CSS, but that is really important. The look of an application is the majority of it’s appeal.

I’ve always held that a major benefit of GWT is that it lets graphics impaired developers put together a good looking application. I think I may go down that path, or should I say, towards the dark side.

Originally published Wednesday, July 15th, 2009

I began a new project today. We’ll really last weekend; I am just getting to write about it now.

The projects not in relation to my current full time consulting gig (which is a GTW project for the insurance industry). The new project will be an education testing program for a local community college, essentially online quizzes. I am also using this project as an opportunity to explore new tools and frameworks.

When we think education application, Flex comes to mind, and it is certainly a frontrunner, especially for the interface/testing component and if multimedia is incorporated.

For the back end, I am moving away from the XX Framework. While I think the framework is awesome, I need to get additional experience on more industry standard tools. Of course, XX is built on Spring MVC. But I want to get some additional experience in pure Spring apps.

Spring Web Flow is another possibility. The more I read about Spring MVC and Spring web flow, the more in common I see with what is in the XX Framework. Regarding Web Flow, I don’t know if I want to write so much in their XML/Expression based DSL. I don’t mind specifying this stuff for control reasons (like what XX does) but getting into defining variables doesn’t seem the place for XML based grammars.

Spring web flow does lend itself to a graphical editor. I haven’t tried Spring IDE, but since they were a recent SunJug sponsor, I took a quick spin in Skyway Builder , an eclipse based GUI for generating Spring MVC/Spring Web Flow apps. It is really an impressive product. However, being impressive doesn’t mean it is useful (sort of how I feel about GWT most of the time). Why try to graft a GUI over what is a perfectly capable and expressive language (Java / XML). In some cases, this will make sense, but in many or most, just writing plain old Java is quicker and quite understandable.

I need to work more with these tools to really make a judgment on them, however.

The one thing I always start with is a bit of upfront UML modeling. I use Enterprise Architect, which is a really inexpensive and reasonable good UML tool. Just brainstorm out the use cases and draw up some classed. It always helps to diagram these out before putting them to Java , and it doesn’t take too long to get to the Java stage.

One thing I did take away from reading some of the Web Flow docs was the use of UML state diagrams. I have always used Use Case diagrams and activity diagrams almost exclusively, but the web flow authors showed how State diagrams can more easily model the overall flow of the entire applications.

So I will most certainly do a Spring MVC / Hibernate / MySQLback end. Build out the model and services. I haven’t decided on the front end. It may be Flex, with BlazeDS or web service interface. Maybe JSF, which I have the least experience in and would like to learn. Most likely a portion will be in a Spring MVC view technology, namely JSF, Velocity, or Freemarker. Most likely, the application wills involve several of the above tools.

Have you ever worked on a project and not thought that is would really benefit from a complete rewrite? It would be nice if that was not the case, but I believe reality dictates that what we wind up releasing is less than ideal.

One reason for this is changes in technology. New tools, techniques, and frameworks are constantly being developed. How many projects out there using Struts would not prefer a rewrite in a more modern framework.

The second reason is time constraints. We just do not always have the time to implement things the way we would like in the ideal world. There is always pressure to get things done yesterday. Much of programming wisdom is in finding the right balance between quick development and a well designed application, and delivering as much of both as possible.

We also seem to like the complete rewrite, such as when a new release of a product comes out. Check out this announcement from Spectral Core for their excellent Full Convert product.

Full Convert 5.0 released:

1-Conversion engine rewritten so that .NET framework is no longer required. This considerably reduces installation size and memory consumption, improves conversion speed and user interface responsiveness.

I feel good about this new feature, after all, it is a complete rewrite.

When I wrote Domuswap, I didn’t have the luxury of a complete rewrite. Domuswap was developed concurrently with the XX framework 1.1 and 2.0. Once the framework proved successful in Domuswap, it was released. However, I was still using the underlying framework and legacy code. Some was rewritten, but the time certainly wasn’t there for a complete rewrite. Indeed, I was very happy with how easily the existing code fit into the Spring MVC components that were added.

Would I have liked to do a complete rewrite? Definitely. I’d probably like to prove that XSL could indeed be speedy, or get rid of that approach entirely. I’d also like to enhance the multi threading techniques. I did this to some extent for version 2.0, in conjunction with my Sarasota Java Users Group presentation on concurrency. But that feature is still in experimental stages.

If I was to do a complete rewrite of the XX Framework, I would probably start with pure Spring MVC and just weave in some of the more interesting XX features, all the while sticking to their interfaces as much as possible.

All that being said, I find myself with the luxury of doing a complete rewrite at this very moment with the New Project. I plan to do this, in addition to satisfying the necessary functionality, as an implementation of what I see as the current best practices in web application development. I’ll have much more to say about this project in future columns.

You usually come into any project with somewhat of an idea of what you want the thing to do. The first step, therefore, is to get these ideas down on paper. This process can encompass a mission statement, feature list, or other textual description of what you want to get done. We are in the brainstorming phase here, so anything you write is good. Let the ideas flow.

Now when you are ready to sit down and actually begin work (making sure your coffee cup is filled first) the first step should be use case diagramming. We are still in the brainstorming phase at this point, but use cases make the application begin to take shape, with early definitions of actual application components emerging.

Many of the use cases will be obvious. Some will become evident once the more obvious ones are defined. For use cases, there will certainly be “view available quizzes”, “take quiz” and of course some sort of authentication / log in behavior.

The initial data model can be developed in parallel with the use cases. Remember, both of these models will evolve throughout the life of the project. We are not doing big upfront design here, just enough architecture to get going. But some formal design is always a good idea.

As you go through the use case modeling, keep a note of the domain objects that you start describing. Start building your domain / class model now as well. Some of these will be obvious. In my cases, things like Quiz, Answer, Question, and of course the always present object User, were things I didn’t need to think much about. But the relationships between the two are not obvious. Is user related to quiz, quiz to question, or is there something more complex going on.

As soon as a few main uses cases are defined, it is time to jump into coding. Besides the fact that this is what I like to do, early coding will help you solve early problems and answer unknowns related to new technologies. You just want to make sure you are on the right track. This is called the vertical slice approach, where you build out a piece of functionality, generally a couple of use cases, from start to finish (from the web page to the database, the full stack). Plus it is always nice to have a working application to show. I won’t go into a full discussion of this topic. Just see any of the Agile literature for more information.

The quiz application is not yet an earth shattering innovation (but I do have a few things planned that could very well be). However, one goal is to implement the latest best practices in web application development. As such, I finally have the luxury to take the time and do it right. Of course, there are time pressures for this one as well, there always are. Even if there aren’t any dictated timelines, technology will eventually move ahead, you can’t stop that, and you will always be chasing the latest and greatest technology and practices.

Originally published Tuesday, September 1st, 2009

Most anyone who has done Java server programming has dealt with the Session object, as well as its siblings (and I use that term in essence, not in fact) objects: ServletContext, HttpRequest and HttpResponse. Of course, if you are using a newfangled “Component” framework that tries to “shield” you from the intricacies of HTTP, you may not be familiar with these babies.

GWT is somewhat of a mélange of both Component frameworks and Request/Response frameworks. It is certainly on the component side of the spectrum, in that you are programming mainly in Java objects and using Swing-like constructs and events. But that is mainly on the client side of things. On the server side, GWT is strictly Servlet based, with some excellent marshalling thrown. The marshalling is so good that sometimes can make you forget the HTTP underpinnings. A dead giveaway, other than of course reading the documentation, is that any remote service must be defined in web.xml as a Servlet. I always found this odd, since most newer request /response frameworks(that gladly expose HTTP constructs) tend to use a single “Base” Servlet that you then must extend. Typically, you would create a single Servlet Mapping for this Base Servlet, which would handle essentially all requests. The Base Servlet, based on some xml, annotated, convention based, or a combination of the above, would pass control to a custom Java class which would handle the actual implementation. The Base Servlet and related framework will also provide much of the “plumbing” and other features, such as parameter object mapping, view integration, etc.

With GWT, every remote service you make available to the client must be defined as a distinct Servlet in web.xml (I feel like I’ve already said this, but it is worth repeating). The Servlet class defined is actually the developer’s specific java class, not a base Servlet. This class must extend RemoteServiceServlet, which is a descendent of HttpServlet. This is a key point in the discussion that will follow. Beware of a framework that forces you to extend its own classes (Ok, for the few of you in the know, XX Framework makes you do this as well, but I plead ignorance since I didn’t know better at the time. And I hadn’t seen Spring MVC yet).

Begin a Servlet, our GWT remote service implementation has access to all the HTTP goodies, specifically HttpSession, which I at one time said this post was about. To access the HTTP Session, you use the method

getThreadLocalRequest().getSession()

If this was a HttpServlet Sevice() method, you’d have access to this directly via the HttpServletRequest parameter . But since that method is long gone by the time your code is called, GWT stores this information and makes it available in a ThreadLocal object. ThreadLocal is a construct that lets each JVM thread have its own version of any class level variables. GWT needs ThreadLocal since a Servlet, as in HTTPServlet, needs to serve multiple threads. TheThreadLocal makes data available to all threads that may be accessing that Servlet.

Now remember the following point:

Each Servlet maintains its own ThreadLocal storage

There is nothing unusual with this. How else could multiple threads be served?

The problem arises when you decide to treat your Remote Service Implementation as just another Java class (POJO anyone) and not what it truly is, an HTTPServlet.

So the problem arises when any server side GWT code instantiates a GWT Remote service implementation directly.

Why is this a problem? Well in most cases, it may not be. We won’t include bad architecture in this discussion, which that most certainly is. The problem occurs when you try to access our old friend, getThreadLocalRequest().

The Remote Service Serlvet’s, which our Implemenation must extend, private ThreadLocal storage is initialized when the HTTP Service (POST, GET) happens. The HttpServletRequest, which includes the HttpSession is stored in the Servlet’s Threadlocal storage for access by the current thread.

When that Remote Service Implementation, or any other subsequent code, instantiates another Remote Service Implementation, the new Service’s ThreadLocal is created (it has to be as we are creating a new object) but it is not initialized, since no HTTP Get or Post has occurred. Therefore, any access to getThreadLocalRequest() will throw a NullPointerException, as this information has not yet been stored in ThreadLocalStorage.

I recently hit this problem while working with a client’s code. Doing an internet search and looking at some GWT books didn’t really shed any light on the problem. The only mention was a simple description, useful nonetheless, of the basic method for accessing the HttpSession and related objects. No warning or discussion of what happens when you instantiate a new Remote Service Servlet implementation object.

This is another reason why the SpringSource guys are being proved right time and time again. Please check out Spring MVC for an example of a web framework that can use pure POJO’s for most functionality. These POJO’s can be subsequently instantiated and used, as they have no dependency on the framework.