Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

The AjaxCommand strategy for JSF

Update the Command pattern to handle common Ajax requests

By Matthew Tyson, JavaWorld.com, 10/16/07

Page 5 of 5

The Command pattern vs. the AjaxCommand strategy

The essential motivations or "forces" behind the GOF Command pattern and the AjaxCommand strategy are different. In the Command pattern, the main issue is that you don't know what commands will be added, nor how they function, yet you want to provide a mechanism for allowing commands to be added. While that could conceivably be a motivator for the AjaxCommand strategy, the main thing you are working around is sending out calls over HTTP, handling them in a modular way, and respecting the layers of the application design. The AjaxCommand design also provides a standard and easy way to add new commands to a Web application as it grows over time.

As is often the case, this example of a "real world" pattern is akin to, but not exactly like, what's laid out in the textbook. A fascinating thing is that even though the class diagrams are different, the spirit is definitely there. This makes the "pattern" designation useful. I consider the AjaxCommand strategy a variant, or modification, or just "similar to" the GOF Command pattern. Doing so enables me to sketch out, in a general way, what I am trying to accomplish. As a point of reference, take a look at the original Command pattern class diagram in Figure 2.

Figure 2. A class diagram of the GOF Command pattern

Figure 2 is the generic class diagram found in the GOF book. You'll notice that the AjaxCommand class diagram in Figure 1 doesn't look a whole lot like it (and neither do the GOF examples of the pattern, for that matter).

Still, it isn't hard to see the mapping between the two patterns. In the AjaxCommand implementation, the Command client is the JSF application, which sets the receiver on the command using the managed bean facility. The receiver, which knows how to accomplish the action, is the JsfAction subclass, DeleteAction. The ConcreteCommand role is played by the DeleteCommand, and AjaxCommand takes over for the Command interface. Finally, the Invoker is the PhaseListener, which tells the command to fire.

In conclusion

Ajax is a fun technology, all cautions about its potential for overuse acknowledged. In the right situations it can really avoid some unnecessary processing and network traffic, and make for a nice user experience. JSF is a cause for ambivalence among many developers, but I believe that it will supersede the other front-end frameworks, because it capitalizes on component reusability. Over time, the JSF community's work on components that are readily pluggable will leave other frameworks behind. Also, the difficulties associated with JSF are being addressed and solutions will gradually become well understood and more readily available.

Getting the two technologies to work together is a common requirement, and will become more so. In this article I've shown you a nice trick for certain occasions, when you need to access Ajax functionality without embedding it in a JSF component.

I'd like to hear about your experiences using the JSF AjaxCommand strategy. Join the discussion below to let me know what you think!

About the author

Read more about Enterprise Java in JavaWorld's Enterprise Java section.