Bar and Grill Lab Notes: Groovlets

It seems whenever I read discussions about JSF, Struts, etc., someone invariably claims they’re happiest foregoing frameworks and writing Servlets by hand. I have an inexplicable aversion to HTML code in println() statements so I’ve hand-coded a grand total of one simple “Hello World!” Servlet. I even once wrote a Java tool that converted the pointy-bracket output from a WYSIWYG HTML editor to all those PrintWriter.println() statements. JSPs put a quick and merciful end to that project.

There are some valid points to the Servlet-by-hand approach, not the least of which is avoiding the unnecessary overhead of a bloated framework, which can presumably translate to better performance. For small and even some medium-size web apps, an industrial strength framework might very well be overkill.

With all that in mind, I looked at Groovy’s version of Servlets: Groovlets. The sample on Groovy’s site is markedly minimal, so I decided to write my own to explore the capabilities of a Groovlet. The following example, IMHO, better demonstrates the power of Groovlets. Without further adieu, here is my 1.0-jsr-05 Groovlet, which displays historical stock quotes for a given ticker symbol, in two parts (to break up the monotony):

Part 1

import groovy.xml.MarkupBuilder;

def symbol = request.getParameter('symbol')
if (symbol == null) {
 symbol = '^DJI'
}
def today = new Date()
def end = new GregorianCalendar()
end.setTime(today)
def beg = new GregorianCalendar()
beg.setTime(today.minus(7))

// this line broken up for clarity
def url = 'http://ichart.finance.yahoo.com/table.csv?s=${symbol}&a=${beg.get(Calendar.MONTH)}
   &b=${beg.get(Calendar.DAY_OF_MONTH)}&c=${beg.get(Calendar.YEAR)}
   &d=${end.get(Calendar.MONTH)}&e=${end.get(Calendar.DAY_OF_MONTH)}
   &f=${end.get(Calendar.YEAR)}&g=d&ignore=.csv'.toURL()

def text = url.getText()
def list = text.tokenize("n")

Things of note:

• request is an implicit reference to the ServletRequest.
• The def keyword is not required in scripts but it’s probably best practice to use it anyway.
• It’s easy to initialize a page the first time in. Here, I look at the value of the symbol parameter and initialize it if necessary.
• Though Groovy has slightly enhanced java.util.Date, GregorianCalendar still rears its ugly head.
• A mere 3 lines of code retrieve a CSV table of quote history from Yahoo and parses it into a List.

Part 2

html.html {
head {
 title('Groovlet Example')
}
body {
 form (method:'get', action:'index.groovy') {
   div {
     label (for:'symbol', 'Symbol: ')
     input (type:'text', name:'symbol', value:symbol, size:'5', maxlength:'5', '')
     input(type:'submit', value:'Submit', '')
   }
 }
 table (cellpadding:'10') {
   tr {
     list[0].tokenize(",").each {
       th(it)
     }
   }
   list[1..5].each {row ->
     tr (align:'right') {
       row.tokenize(",").each {
         td(it)
       }
     }
   }
 }
}
}

Things of note:

• GroovyMarkup is very cool—no pointy brackets.
• The input tags didn’t render properly without the empty string.
• value:symbol can be replaced with value:”${symbol}”–not sure which is best practice.
• Nested closures. suh-weet!
• In nested closures, it has to be renamed in at least one closure.

Groovlets definately won't take over the JSP/Servlet stack any time soon, but they do provide an easy technology for quick solutions to small and perhaps even some mid-size projects.

Why JavaServer Faces will Dominate

Javalobby Readers’ Choice: Top Java Books consists of 112 books with a total of 72,079 pages. Rick Ross, founder of Javalobby, writes,

…if you read fifty pages per day every day, then you would finish reading this collection sometime in the middle of January, 2013! Of course, there’s some question whether all of this material would still be relevant by then, and there’s also the small issue of whether you’d really want to fork over the $5,238.66 this library would cost if you paid full price for every title.

For those reasons, one would be inclined to derive some means by which to pare down the list. It’s a good bet the top five or ten are excellent reads and should be on every developer’s shelf. Word of mouth from a trusted colleague or by recommendation from an industry expert might also be good reasons to consider ownership of one or more of these books. Whatever the choice, it is most certainly not based on personal experience, but somewhat arbitrary.

The same can be said for adopting a technology. (A Google search on java web development frameworks turns up over 22,000,000 hits–admitedly unscientific, but telling none-the-less.) There are simply too many frameworks, tools, and techniques to absorb enough knowledge to make an intelligent decision when it comes to selecting technology for a development team. Some may be so overwhelmed by the staggaring number of choices, they stick with the tried and true. Most, I suspect, will decide to adopt the latest, especially for new projects. The decision to select one technology over the others most likely will be based on whatever will be around for at least the typical life span of a system. So a great guessing game ensues and inevitably the answer is, “whatever the industry leaders are pushing.”

Thus, JSF will be, if it isn’t already, the dominate web development framework for at least the next 5 years. Not because it’s a superior framework, or that it cuts development time or increases quality, or even because it’s (arguably) innovative, but because it’s a standard and Sun is behind it.

Sorry, Tapestry fans, but it’s Betamax v. VHS all over again, and you’re behind Betamax.