David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler

    Web app developer since 1994 and Google Cloud Platform Instructor now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 223 other followers

  • Sleepless Nights…

    October 2021
    S M T W T F S
  • Blog Stats

    • 1,029,242 hits

Archive for the ‘Model-View-Presenter’ Category

More Benefits of gwt-dispatch

Posted by David Chandler on September 25, 2009

When you use gwt-dispatch, a single dispatch servlet handles all service requests, so you no longer need to configure individual servlets in web.xml. Furthermore, action handlers are configured in Java code, like this:

		bindHandler(FindPrayerListsAction.class, FindListsHandler.class);
		bindHandler(AddPrayerListAction.class, AddPrayerListHandler.class);
		bindHandler(DeletePrayerListsAction.class, DeletePrayerListsHandler.class);

Because all configuration is done in Java, you can rename any handler, Action, Result, etc., and the Eclipse refactoring tools automatically rename it everywhere.

And speaking of Eclipse, did you know you can type only the capital letters of a class name and hit Ctrl+Space to let Eclipse automatically expand it? For example, to type “FindPrayerListsAction” above, I could simply type “FPLA” and hit Ctrl+Space. This also works in the Open Type (Ctrl+Shift+T) and Open Resource (Ctrl+Shift+R) dialogs.

Posted in Eclipse, Google Web Toolkit, Model-View-Presenter | Leave a Comment »

GWT + MVP = Very Manageable Code

Posted by David Chandler on September 24, 2009

I’ve been struggling with GWT a bit. It’s a new way of thinking for someone who’s been writing Web apps on the server side for 15 years now. But I was intrigued by a few posts on GWT with MVP, and then I found this:


I cannot say it or do it any better. It took me about a day to rewire my small GWT + AppEngine app with gwt-presenter and gwt-dispatch. It worked the first time. Color me impressed.

I can understand my own GWT code far more easily now.

And it’s more testable.

And more modular so other developers can work on it at the same time.

Did I mention I was impressed?

For the CM-inclined, these are the jar versions I put in my GWT project’s lib directory:

  • gwt-dispatch-1.0.0.jar from the project’s Downloads page
  • gwt-presenter-1.0.0.jar from the project’s Downloads page
  • gin.jar from GIN project’s out/dist folder I built from SVN trunk on 9/23/09
  • guice-2.0.jar from GIN’s lib folder per the blog post above

Posted in GIN / Guice, Google Web Toolkit, Model-View-Presenter | 4 Comments »

MVC and Event-Driven Programming

Posted by David Chandler on September 10, 2005

A dynamic Web application has more in common with a traditional Windows GUI application than with a static Web site. A Web application, similar to any GUI application, typically consists of forms populated with database data. As with any Windows application, forms have action buttons and familiar controls such as check boxes and text input fields. Fifteen years ago, Microsoft revolutionized GUI programming with the introduction of Visual Basic and the event-driven paradigm. Arguably, the industry transition from procedural to event-driven code has been every bit as significant as the transition to object-oriented programming.

Until recently, however, the shift to event-driven programming was completely missed by Web application developers. Most likely, this is because early on, the Web was mostly about sites, not applications. HTTP and HTML are page-oriented, and scripting languages like ColdFusion, ASP, and JSP made it easy to develop dynamic “pages.”

The page-oriented paradigm works fine for small applications with uncomplicated navigation, but it quickly breaks down for large applications with a lot of user input. The root of the problem is one of encapsulation. A typical script “page” contains at least two different kinds of code:

  1. Action code that processes input from the submitted form
  2. Presentation code that displays the result page

These two things do not belong together in the same unit of code. For example, suppose a form has two buttons, one which goes to another form to do some kind of lookup, and one to process the completed form. Regardless of which button is pressed, you want to save the data from the initial form so you can use it later. Typically, the “page” referenced in the form action attribute would save the form data regardless of which button was clicked, then include or forward to a new “page” based on a form variable like a named submit button.

From an encapsulation point of view, there is no reason that the unit of code that saves the form data should have to know about the navigation changes associated with the different buttons on the form. The more complex your navigation, the more apparent this becomes. In one application I worked on, there were hidden variables named “what” (no kidding) and “origWhat” that got copied from page to page to keep track of the user’s page flow. Many pages had code blocks like

if (origWhat = “page x”)
// Came from page A
do one thing
do something else

In essence, this and the previous example are a kind of event-driven programming where each button represents an event, but the navigation rules and processing code are all jumbled up together. Code like the block above is dependent on the preceding page flow, yet the exact nature of the dependency is not clearly visible in the code. Hidden dependencies make code brittle.

Event-Driven Web Frameworks
Enter event-driven Web frameworks like Fusebox, Struts, and JavaServer Faces (JSF). These frameworks decouple event handlers (action processing) from view selection (navigation). This is commonly done by using a navigation rules file that specifies all the page transitions independently of any code that handles events. This is perfectly in keeping with Chandler’s Law of Coupling:

Where dependencies exist, represent them explicitly in one place instead of hiding them in many places.

Of the frameworks mentioned, the JSF navigation controller is the most flexible, allowing you to specify the next view based on the previous view, the event that fired (which button was pressed), the outcome of that event (success, failure, etc.), or any combination of these. In addition, JSF devotes an entire step in the request lifecycle to automatically saving the data from the previous form, so you don’t have to worry about that any longer. More on that in a coming article.

In a nutshell, the event-driven paradigm for dynamic Web applications fulfills Chandler’s First Law of Application Design:

Choose a design paradigm that most closely fits the system you’re trying to model.

Event-driven Web frameworks let you code a Web application more like the GUI application that it really is. If you want robust, maintainable code, you need the right tool for the job.

Controlling Page Sequencing with an Event-Driven State Machine
A State Machine Engine for Web MVC


Posted in JavaServer Faces, Model-View-Presenter | 3 Comments »

%d bloggers like this: