Back when I wrote firmware for a living, every project had an exciting phase in the middle which we called “bringing up the board.” Bringing up the board consisted of getting a fresh, chemical-smelling new circuit board from a short-run manufacturer, applying power to it, and attempting to take control of it with software. It sat neatly in between a very waterfall-ish design and coding phase at the beginning and a very deathmarch-y integration and test phase at the end.
Bringing up a board requires intensive, cross-disciplinary debugging in which very few abstractions are of any use to the engineer. Rarely do enterprise software developers think about things like reset vectors and fetch-and-execute cycles (much less voltages and currents), but these are the stock in trade of the firmware developer working with a brand new hardware design. The phase is full of the seemingly intractable problems and contradictions that normally attend test-last debugging. Inevitably, at least once on each project, some impossible condition will arise in which the engineer knows he is flipping a bit in a control register somewhere, and he knows the corresponding digital output pin is driving a high impedance, but somehow under such-and-such conditions the trace on the oscilloscope barely wiggles when it should be banging back and forth between five volts and zero. He’s sure of everything else in the system, he knows he’s got the address of the control register right, he’s certain he understands the circuit the output is driving. There’s just no other option: Ohm’s Law must be wrong in this case.
Of course it never is. And while widely used, production-ready web frameworks like Grails are less reliable than fundamental laws of physics, they can probably handle trivial form submissions with aplomb. Of course, that still didn’t stop me from thinking Grails had a bug last week.
I had generated some scaffolding for a fairly simple domain class, and had begun elaborating on it in the way that any Grails developer does for a real-life application. The GSP code looked something like this:
When I clicked on the submit button, I got a 404 error. I verified that AssessmentController had a save action, which it did. I bounced Grails, which I was running in dev mode. Still no love. I banged my head against this for a while, unable to believe that I couldn’t get a form submission to work. Was it some strangle UrlMapping oddity? Was it a problem with allowed HTTP methods? Nothing made sense.
So I decided to bypass the Grails GSP tags and code up a form myself. It looked like this:
That worked perfectly! My next task was to figure out what was different between the two requests. Ever a fan of the big hammer (my favorite debugging tool in my firmware days was the oscilloscope), I broke out HttpFox to see what was happening on the wire.
I saw, as you might expect, two apparently identical requests that looked something like this:
No differences in headers, request URL, or anything that might affect how the request would be routed to an action. Everything was the same until I looked at the POST Data tab. The version of the form that was built by the Grails tags looked like this:
while my custom form generated these parameters:
The _action_Submit vs submit difference should have tipped me off right away, but it didn’t. I had simply forgotten that Grails is capable of doing request mapping through the submit button, so I continued plugging away at the code for longer than I’d care to admit. I knew at this point that there was some kind of internal processing of this form parameter going on, and was ready to resign myself to spelunking in the source to figure out what it was. Since this was such a basic operation going on here, surely this had to be a bug in the framework excited by an as-yet-undetected subtlety in my form markup. Surely. Then it hit me: the form code I was debugging used
Sure it should, if g:submitButton is all you ever use. I’ve never been a big fan of scaffolding—a conceit I have long suspected is to my detriment, and one I am currently in the process of reforming—and I had never had occasion to become familiar with g:actionSubmit. What that magical tag does is allow you to include multiple submit buttons inside a single form, each of which targets its own action within a given controller. Great idea, and great tag. And an epic failure if you’re trying to accomplish mapping through the
I’m tempted to conclude that the moral to the story is to know how your web framework accomplishes simple tasks like form submissions, even if it throws a few nice features your way to spice them up a bit. And there is nothing wrong with knowing this; in fact, it’s a good trick if you can do it.
The real lesson, however, is about debugging. Ohm’s Law is never, ever, ever wrong, and when you sit down with ohmmeter and oscilloscope and proceed to prove that it is, all you’re doing is establishing that your mental model of the problem is badly off-base. Grails, like any web framework or well-used public API, sometimes is wrong—it is not a fundamental physical law—but public releases probably aren’t wrong about trivial things like form submissions. If you think you’ve got a bug so obvious that someone had to have caught it in the past, then somebody probably did. The bug is probably with you, either trivially in your code or even in your debugging process itself. In the heat of the chase, it can be difficult to remember this, but how often is the resolution to the story actually some complex subtlety that takes hours to explain? Sometimes it is, but most of the time you’re just using the wrong tag. Looking for the obvious is probably going to pay off well in advance of a deep dive into the code. Or, for that matter, a reconsideration of classical physics.
