In the Spotlight - David Geary

Stuart Halloway, Bruce Tate, Dave Thomas, Venkat Subramaniam (pronounced Superman) and yours truly started the proceedings. My first session was JSF: A Whirlwind Tour, which is a conglomeration of my JSF Intro, JSF Advanced, and Felix sessions over the past few years. I've probably spent around 500 hours over the years on the material in this session, so it's good to go. And guess what? I wore jeans.

I was pumped for my first session. I hadn't spoken since JavaPolis, and I really miss having someone actually take what I say seriously. I was so excited before the talk that I could literally feel my body buzzing, very similar to a time in my youthful past when I popped too much speed to stay awake on a cross-country drive. We had a great time—in the session, not the cross-country drive, although that wasn't entirely unpleasant either, as I recall—examining the awesome power of JavaServer Faces with some engaging discussions and stimulating (at least for me) demos. Harumph.

My other sessions were: JSF: State of the Art, where we explore MyFaces's Tomahawk, Facelets, and Seam (now that's a kick-ass session); Shale: Turbo-charge your JSF Applications (hey Gary: Clay was a big hit!); and Killer Web UIs, where I introduce Tiles and Sitemesh. Killer Web UIs is a strange session: it's nearly always my least attended session, but I routinely get some of my best evals for it. Strange or not, it's a fun session for me because I love Tiles and, yes, I happen to like Sitemesh a great deal too. I particularly like showing people how to use them together.

For the next two weeks, I'll mainly be occupied with finishing my Ajaxian Faces session. That, and JSF: State of the Art should wind up being my most exciting sessions. There's a lot of bleeding edge, fun stuff in those two.

So next week I'm off to St. Louis, where I'll repeat my four sessions from Milwaukee. The week after that, in Boston, I add Ajaxian Faces as my fifth session, and that will be my lineup, along with an occasional sixth session: Hands-on Rails. I'm also thinking of adding a session on Maven and perhaps a session on either Dojo or Prototype + Scriptaculous (btw, here's a good list of Ajax JavaScript Frameworks and links). We'll see if those pan out.

Tried to take a shuttle to Spain
They kicked me off of the plane
I guess I'll go to Japan
It all looks the same when you stump for the man.

Bought for a Song
from Welcome Interstate Managers by Fountains of Wayne

Since I'm lucky enough to reside in both the Rails and JSF worlds simultaneously, I often get asked what we can do in Java to reap some of the benefits of Rails. I had no idea until recently, but Maven—especially Maven 2—is a heck of a good start.

Maven has been on my list of things to learn for awhile, but it's never made it to the top until I experienced a Maven confluence of sorts, when Shale added Maven support and a client handed me an application built with Maven.

Maven, like Rails, can generate an application for you. Maven 2 has something called archetypes that you can use to generate an application. But the archetype mechanism, much like Rails' code generators, is pluggable. This is really cool; for example, MyFaces has an archetype that will generate a starter MyFaces application. Maven even comes with a plugin that generates IDEA project files. (I'm fresh into IDEA these days)

Now comes the good part. The application that Maven generates for you is setup to work with an impressive array of built-in goals (Maven goals == Ant tasks). So you just do "mvn install", for instance, and watch Maven go through it's paces creating and deploying your newly minted application. You can go pretty far on the built-in goals, but of course, you can also, like, write your own.

One of the barriers to entry for a new technology for me is how easily I can get an app up and running—the so-called 10 minute test. Because Maven can generate a starter application from an archetype created by a third party, I can have a MyFaces application, for example, running in minutes even if I know nothing about MyFaces. Then I can examine the files, learn how it hangs together and extend the app for my own purposes. That saves me an enormous amount of time. (I was hoping Seam would have an archetype, but my searches have failed. Anyone know if there's one available?)

All of this is possible because Maven essentially inverts the structure that Ant users are familiar with. Instead of you implementing build logic with Ant targets, other people implement Maven tasks that you use in your Maven-generated application. That shifts the responsibility of implementing build logic from you to a provider (Maven built-in, MyFaces, whatever) much the same as EJB has forever freed us from the banalities of implementing distributed applications.

One more thing and then I'll send you on your way to someone else's blog. If you're like me, you've got numerous Ant-powered projects and you are committing the cardinal sin of software development: you are repeating yourself. You've got build files all over the place, that essentially do the same thing, but a little differently, for lots of applications and you've got to maintain those build files. You've also got JAR files scattered across your hard disk like goose bumps on the neck of a new Rails convert. Those JAR files have to be maintained too, not to mention the space they eat up.

Instead of bleeding all of this build knowledge all over your drive, Maven encapsulates it in goals that are publicly available and a repository. Like its namesake, Maven accumulates knowledge that you can take advantage of. The Maven repository stores one copy of each of your required JARs at a cool 28 degrees F on your hard drive to ensure maximum freshness. No more JAR files all over the place; Maven gets them from the repository and automatically downloads required dependencies for you. What more could you want?

And I learned not to say much of nothin'
So I figure you already know
But in case you don't, or maybe forgot
I'll lay it out real nice and slow

Outfit
from Decoration Day by Drive-By Truckers*

* New album due in April, 2006

I had given a variant of that demo quite a few times at NFJS but I was always uncomfortable showing the corresponding code, because it felt overly-complicated. To use Shale remoting, you had to:

• Declare a Jakarta Commons Chain object in chain-config.xml
• Implement the chain class
• Invoke the appropriate URL

In the beginning, it seemed to make sense to use Chain for remoting; after all, Shale uses Chain under the covers to process requests, and using Chain for remoting seemed like a natural extension of that implementation. Craig and I had talked about replacing Chain with Dialogs, so you could remotely invoke a dialog, but as I thought about it on my flight home, using dialogs seemed like it would make remote calls even more complicated. Instead of the steps listed above, I wanted:

• Implement a POJO method
• Invoke the appropriate URL

So soon after I got home, I filed an enhancement request to simplify Shale remoting. I wanted to eliminate the Chain dependency altogether so that we could remotely invoke pojo methods on the server, sort of a remote value binding. Craig responded to that RFE with a revamped remoting package that was almost exactly what I'd envisioned. I was so excited that I modified my JavaPolis Ajax demo and added it to the use-cases application that comes with Shale. So, at last, Shale has an Ajax demo. The crux of the demo is captured in this JavaScript code:

function zipChanged(zip) {
   sendRequest("http://localhost:8080/struts-shale-usecases/" +
               "dynamic/remoting$business/cityAndStateForZip.faces" +
               "?zip=" + escape(zip), 
               processZipCodeSelection);
}

The preceeding code uses an XMLHttpRequest object to invoke a URL on the server. Shale intercepts the URL and turns it into a cityAndStateForZip method call on a managed bean named remoting$business (the $ is a Shale convention that has no bearing here).

The remoting$business.cityAndStateForZip method calls FacesContext.responseComplete, which effectively halts the JSF lifecycle, and writes an XML response to the response stream. On the client, I have some JavaScript to parse that XML response and store the corresponding city and state values in the appropriate HTML elements in the page.

Teo torriatte konomama iko
Aisuruhito yo
Shizukana yoi ni
Hikario tomoshi
Itoshiki oshieo idaki

Teo Torriatte
from A Day at The Races by Queen

From an article titled Out of the Fyer, Into the Lights in the Dining In section of the New York Times, Wednesday, Dec. 23rd:

We all learned in Hebrew school that the reason we eat latkes on Hanukkah was because they were cooked in oil, to remind us of the miracle of the oil that lasted eight days instead of one," Ms. Goldman said. "It never occurred to us that you could eat other fried things until some Israelis in our congregation introduced us to sufganiyot (jelly donuts).

Surely this is unthinkable to the average American, who is drowning in a sea of artery-clogging delicacies at every turn. But the underyling theme that such a simple concept never occurred to these folks is staggering. It never occurred to us that you could eat other fried things. You've got to be kidding, right?

Yet, as I sat at my kitchen table munching on sesame chicken for lunch, it suddenly occurred to me that it never occurred to me, while I was helping to define the JSF 1.0 spec, that you could have zero-turnaround time in your framework. Or that you could create rich-client applications with JavaScript using a collection of technologies that would later be labeled Ajax. Or that something as simple as convention over configuration could be such a powerful tool.

I was sitting next to Jason Hunter on an Expert Panel at NFJS and Jason told the crowd that the WAR mechanism was never meant to be used to deploy applications, it was meant as a distribution mechanism. "Why jar everything up into a WAR when the server's just going to unjar it?" Jason asked. "Instead, just work in the webapps directory, or map your context to another directory". At the time I was working on a consulting job, where, guess what, we were deploying a WAR file to the webapps directory for every build.

So perhaps the assertion that it never occurred to these folks to fry something tasty is not so far-fetched after all.

How come all the poets fall into despondency?
And they write it down
for us to read every indignity

I'm a Dog
from A Worm's Life by Crash Test Dummies

I hope you had a good time at the conference, Mr. P!