And sometimes all you want to do is add a class to a form element so it can be styled. But the code you’re handed to work with looks like this:
<form:select path="statuses" multiple="true">
<c:forEach items="${statuses}" var="status">
<form:option value="${status}"/>
</c:forEach>
</form:select>
Interruptions can be both external and internal. In fact, people tend to interrupt themselves “as much as…44% of the time.”
Imagine you had to add a class to the form element in the code above—would you know how to do it?
If you’re like I was at one point, you’d have a good idea of what to write, but you wouldn’t be sure. Being something of a perfectionist, you’d be left with a couple options. One, you could search your repository, hope you got lucky and found an example of how the class attribute was added in a similar line of code. Two, you could turn to Google/Stack Overflow for help. Three, you could bother your developer friend for help. Four, you could take a shot in the dark, deal with the guilt as you re-built your project and hope for the best.
Three of those four options certainly introduce interruptions—options one and two, internal; option three, external (for your “friend”) and internal (for you). But all of these options would be better than option four, taking a shot in the dark, if you ask me.
But let’s say you go the route of option four—you take a shot in the dark. You add the class .grid-100 to the <form:select> tag, reasoning that that’s what you’d do with vanilla HTML. You re-build your project expecting to see the changes take effect, but for some reason the class isn’t even listed when you inspect the element.
You might re-build the project a couple more times, do a hard recompilation of your pre-processed stylesheets, triple check that all your files are in sync and subversion is clean as a whistle, only to end up exactly where you started half an hour earlier.
Frustrated and nearly exhausted, you finally seek help. You discover that the cssClass property is being set in the code-behind and is overriding the class you added to the <form:select> tag in the view. You change your class attribute to cssClass and everything renders as you expected it to in the first place. You’re still a little frustrated, but also relieved; a bit bewildered and curious, but now an hour behind schedule with miles to go before you sleep.
Case in point why designers should know the basics of programming. Having a basic understanding of how MVC frameworks work could have drastically reduced the length of this interruption.
Having a basic understanding of how different frameworks render HTML can also change the way you go about writing code and significantly reduce the amount of time it takes to reach a desired outcome.
For example, check out this line of code from Duck Ranger’s “Spring MVC and Twitter Bootstrap – customizing the input fields” post:
<form:input path="${path}" cssClass="${empty cssClass ? 'input-xlarge' : cssClass}"/>
Essentially, the line says if the cssClass is defined in the code-behind use that as the class, otherwise use the class .input-xlarge. Pretty cool way of dynamically setting a class attribute.
Here’s another cool line of code:
<form:input path="email" size="40" cssErrorClass="form-error-field"/>
Did you know that some frameworks, like Spring MVC, have built in properties that can be specified to handle certain situations? The line above will return a class of .form-error-field when an invalid e-mail address is entered.
The bottom line is there are a million reasons why designers should know something about what goes on behind the front-end. This is only a simple case study on how being part developer helps, by limiting the number of interruptions through which you’ll have to suffer. Because, let’s face it, we all know how awesome it feels to be in the zone, and how equally painful it is to be interrupted when we’re in the zone, even if we’re only interrupting ourselves.
Leave a Reply