NFJS Coming Up (Yet Again)

Only a mere five days from now I’ll be attending the NFJS Gateway Software Symposium for the 4th time… and I’m pleased to say I’m quite excited. NFJS is one of those conferences that just has a knack for being fun, small, easily accessible, and very very educating.

The “educating” part however is the only aspect that has me a little worried, since this being my 4th NFJS conference I worry there may not be much new to see… and a quick initial glance at the sessions I easily spot many of the usual sessions they’ve had in the past… so what to do? 😉

Without a doubt, I’ll have to attend Michael Nygard’s session “Failures Come In Flavors.” I actually had the pleasure of meeting Michael last year at the GSS Fall edition at the hotel lobby bar… from the discussion we had about software development I could tell the session would be interesting, but unfortunately missed it due to having to head back to Columbia early on Sunday. So I’ll be “making it up” this time around. Additionally, he is also giving another session titled The 90 Minute Startup that sounds pretty interesting too.

The session that stands out is Nathaniel Schutta’s Designing for Ajax (Part 2). Why am I only interested in part 2? One reason… one reason only… Google Gears. Google Gears is one of the most interesting things I’ve toyed with lately that sadly your average developer has no idea what it is (but should).

Anyway, feel free to hit me up if you happen to be attending. If not, keep an eye here as I’ll try to post some fresh content daily from the sessions, if not just quick notes on what’s going on. Hopefully I’ll have something enlightening to post! 🙂

Smarter Javascript for Java Web Applications With JAWR

One thing that has always annoyed me a little about javascript is the burden induced by modularity. Sure, you can keep your javascript in many small, testable files… but good grief it’s annoying when you have to put 10 or 15 script tags in the head of your document and thereby inducing much overhead on the client side. I mean, first you have a good chunk of markup taking up bandwidth and then you have the overhead of each http request for each javascript file. Once you take into consideration that some browsers only allow two http connections at a time things start to slip. Jamming everything in one file is annoying too, and always feels sloppy.

Recently I’ve discovered jawr, and it’s alieviated all of my javascript modularization problems. Jawr is cool in that it allows me to define “modules” that consist of many javascript files… I can either list the files I need, in the order they should be included, point to a directory to include all scripts in it, or even use some pattern matching. The simply define a mapping for the module to serve up the javascript (i.e. /js/all-the-scripts-i-need.js) and jawr goes to work, stitching the javascript together and serving it up… minimized and gzipped. I’ve only began delving into it, but so far it’s been great. On a single page on our site we had about 60KB of js, 30KB of it jQuery. After defining a module, the resulting file served to the client side was a mere 22Kb. Similarly it also can do the same for CSS, which slimmed our 8 css files from a total of 28KB to a single 5Kb file.

The idea is pretty sweet… keep a collection of javascript objects/functions with appropriate namespaces, fit together into modules for each place they are needed. Inside of each of those modules though will probably be our usual “binder” functions… you know, the usual “hunt down and find the DOM elements I need to bind events to” type behavior.

My only annoyance so far? Sometimes the minification process exposes javascript that, shall we say, does not minify well thanks to it’s layout. In my case, there was a javascript file with a multi-line string used for templating… my deployment just outright failed because of a “unterminated string literal” and took a bit of mucking around to find exactly what file it was that it hated. Other than that, it’s well worth the look. 😉

Extending Selenium Via Javascript

Looks like I’ve already accomplished one of my new year’s resolutions by doing some polygot programming at work today embedding javascript within java. And it happened completely by accident.

Lately we’ve had a handful of Selenium Remote Control based fitnesse fixtures crop up at work… there’s a nice generic one, and several custom ones designed to tackle specific front end domain problems. On our latest project we have your run of the mill tabbed layout, you know… click on tabs and and you see different content, nothing special. What made things interesting, however, is that marketing wanted to track some specific usage information when each tab is clicked. Fine enough, just whip up some ajax and register some event handlers for the click event, and we’re ready to go. Well, hold on… what about testing?

Everything on the server side was unit tested and functionally tested to a T… in fact I am rather proud of the partner I worked with and myself on how well the tests are written and how many scenarios are covered. However, I still wanted to test the front end… I want to be sure that each time someone promotes, they didn’t do something to, as our team’s QA member would say, “jack it up.”

So I quickly wrote some selenium tests in fitnesse (note: this violates everything I believe FIT should be for, but fitneese is a convenient poor man’s application server) to get to the vehicle history report and test it. Speed bump number one. The interface that lets users run reports uses a target attribute on the form to open the report in a new window, and apparently selenium can’t focus on a window unless you explicitly use to open the window. Drats… foiled. Or was I?

After a bit of searching, I found out that selenium remote control has a method called getEval that will simply evaluate any javascript you pass into it, which is handy for checking variable values for example. From there, you can access the runner via this.browserbot, which provides a whole slew of awesome commands you can use for manipulating the runner, including accessing the current window. And that’s where it sinks in… I can do anything in the world (almost) with javascript, and if I can access the window, I can make things happen. Bypassing the earlier speed bump was a simple matter of opening a new window with the same name as the target, and then focusing on it once the form is submitted. Piece of cake.

Since we have a lot of forms like this, I wrote a simple script to open new windows for any forms with a target on it using the name of the target, and wrapped in a java method. So that was step one… I now had a java method in a fitnesse fixture with javascript code inside a string indented all nicely… and evaluated on demand.

Now. at the new tabbed page is where things got immensely interesting… I wanted to intercept xmlHttpRequest calls, capture them, and be able to access them later. Redefining jQuery’s XHR methods were a piece of cake, the code was something like this (and whipped up in about 5 seconds):

var _d = this.browserbot._caughtValues = []
this.browserbot.getCurrentWindow() = function(a,b,c){
	_d[_d.length] = b;

the second parameter here was the data packet being passed in, which is what I was interested in the most. Different meta data is fired off on different tab clicks.

Then topping this off was a simple matter. I created a method that would return a ListFixture (because I wanted to loop over the meta-data packets in the order they were fired, and also because it is vastly supperior to RowFixture) and got to work scraping the values out, which became a mix of BOTH java and js, together.

Building a list of java objects from the captured values was a matter of:

  1. Getting the length of the _caughtValues array and converting it to a java int (getEval only returns strings)
  2. iterate a number of times equal to the length to visit each value on the array
  3. do an eval against _caughtValues with an index specified to get the json packet:
    String packet = getSelenium().getEval("this.browserbot._caughtValues["+index+"]");
  4. parse it into a java.util.Map by making a call to a nice JSON parsing library
  5. populate a java object representing the packet with the map, add it to a list, and return a new ListFixture containing that list.

I wrestled a little to get it work, but I’ll have to admit it felt oddly great when I saw the table of expected packets light up green… and then red for the last 4 rows (good to know it was able to catch the invalid packets). There’s also a sense of joy in seeing it run consistently… for a session it worked, but would randomly fail.

It’s pretty interesting, but I think my coworkers might hate me for the embedded javascript code inside of java. So far they either think it’s really cool, or really insane. 😉

Spicing Up Your UX With Javascript

Recently (and as others have pointed out) I noticed gmail has a nice feature that allows you to select multiple emails by clicking on one checkbox, then shift+clicking another to select all of the messages in between. This is a very useful UI feature that is present on thousands of desktop applications, which provides users with a natural behavior of being able to select multiple elements in some list with ease.

So why not give the users of your latest application website the same ease of use? What follows is my quick and dirty way of accomplishing it. Granted, my js skills are still in “de-rusting” mode, but after a couple hours I was able to crank out something pretty useful that mimics the same behavior. So let’s dive in!!

Continue reading

AJAX is the New DHTML

First let me start this post by putting on my Captain Obvious hat.

[puts on hat]

There that’s better. Okay, time to post. 😉

Sadly, I must concede defeat. Like numerous others, I used to always get a little riled up when someone mentioned the term AJAX back in 2005… like others, to me it represented a marketing buzzword that had no place in technical speak amongst web developers and software engineers. “Either use the term XmlHttpRequest or XHR if you’re referring to client server communication in javascript, or use the appropriate names if you’re just referring to javascript and CSS” I’d say.

Unfortunately, AJAX became the common term, and sadly other developers wouldn’t understand what I was talking about unless I used the term AJAX.

“We could just take the form action, serialize the field name/values, and send it via XHR.”
“XHR!? Huh? What’s that?”
“Uh… AJAX”
“Oh! I gotcha! Sweet. Could we also use some AJAX to make the info window fade in?”

I was thinking about this the other day when I got an email from a customer to request a new feature. They essentially wanted to change a form to submit to an in-window “window”. Simple enough. What interested me was that one customer referred to it as a “DHTML window” and another customer, in a separate email about the same feature, referred to it as an “AJAX Window” … and I couldn’t try harder to chuckle. DHTML was a pretty dubious term to begin with, and now we have AJAX, the new dubious term to represent javascript, dom scriping, and other “neato tricks.”

I guess what I’m getting at is… it looks like those of us who hated AJAX because it was a marketing term for something that had already existed since 2001 (and before, if you take the current interpretation of “AJAX”) have quite simply lost. It’s the term for it now, and it’s a buzzword that continues to be all the rage. At this point, I’ve given in… I’m perfectly fine with someone using the term AJAX.. I won’t get riled up anymore, but let’s call an apple an apple.

I can even accept the fact that AJAX is an oxymoron since most “AJAX Applications” have no XML involved. But I just really really wish that some people would quit using the term for just plain old javascript. Seriously… what is the point in calling a little DOM manipulation and animation effects AJAX? It’s not really Asynchronous and there’s no XML involved. Just like the early days, it’s just a rebranding of the DHTML term with a small update for XmlHttpRequest. Bleh.

I hate it. But I guess I have no choice but to accept it. Ajax it is. 😉

HTML5 Shim in IE

There’s been something that cropped up as of late thanks to a comment made by Sjoerd Visscher and expanded on further by John Resig here … it seems that by using document.createElement() for a previously unknown tag makes IE start parsing that tag differently. As John points out, you can even apply CSS rules for it.

It’ll be interesting to see what comes from this… no doubt someone is going to implement a mock HTML5 library that lets you make HTML5 behaving pages for modern browsers.

Oh, and by the way, the draft covering the differences between HTML 5 and HTML 4 is worth a look. Especially since the first public draft was released this week. 😉

Making extJS More Accessible to Java Developers

With my recent interest in extjs, I was playing with the idea of making a Struts2/WebWork component library or a tag library to handle a lot of the boilerplate extjs code (i.e. creating layouts and such) but, luckily, discovered someone beat me to the punch!

I randomly came across ExtTLD this morning while sifting through my rss feeds, and I must say I am rather impressed. Although I consider myself a pretty good javascript developer, there seems to be a lot of java developers who aren’t that hot at javascript… which is why whenever I attend any java related conference there is always several sessions touting “javascript free ajax!” frameworks like GWT, Ajax4JSF, or IceFaces. Although I’ve always been skeptical of such frameworks, I do see their benefits… especially for the java developer who excels at serverside JEE development but generally sucks when it comes to adding javascript behavior to the presentation layer.

So far it looks good, but I haven’t had a chance to play with it yet. Basically, I’ll have to see if it passes my “good javascript generator framework” test. I’m a pretty staunch advocate of unobtrusive javascript, and generally hate any presentation layer framework that seeks to dump several hundred (or thousand) lines of javascript inline in the html document. This is the reason I totally hate Struts 1’s client side validation plugin.

jQuery: Binding Submit on a Form’s Action Attribute

Sigh… got bit a little today trying to do something with jQuery. I just could not for the life of me understand it! I was wanting to bind a submit handler to a form and, in trying to be clever, thought I would bind the form based on it’s action versus adding an id to it for the sole reason to bind it. So, I tried the following:


Dang it! For reasons that confound me, it wouldn’t work!

So I took a quick gander at the documentation on the CSS selectors used in jQuery and decided to use the * modifier so it would match if it found it at all:

	alert("intercepted! " + this.action);

For good measure, I thought I’d alert this.action to see the actual value of the action attribute. Surprisingly, it did have the full URL prepended before it… and that’s why I couldn’t bind by it before. LIkewise, I could also use ?= rather than *= if I want to match only the end of the action attribute’s value… since *= will search within the entire string. Good item to know. 😉