So, a friend recently got a position to be the head Data wrangler for
a firm that collects a bunch of demographic data for its clients.
He's a DB guy basically, and was able to convert the horrible data
they were getting in to something usable (can we say raw data rows
with over 4000 columns? Sure we can.).
Of course, now he needed to get the data accessible to clients, so he
needed to deliver some charts to the client base. Oh, and by Monday.
The hammer du jour was a flash based charting component. No doubt
it's very powerful and has all sorts of features. The problem with
power and features is that it takes time to learn and figure out.
With the deadline, he was trying to avoid any blackholes he could.
So, he managed to get the chart displayed using some simple XML data,
and that was going to have to be good enough.
He can tweak an existing Java program, but creating one from scratch
isn't really his forte, so he came down to the house today so we
could pound out something functional for him to shine up over Sunday.
The premise was simple: set of drop down lists to create a criteria
that returns a proper XML feed.
With Stripes we were able to pound out the infrastructure for this
app in about 4 hours. The whole thing is completely dynamic, and
driven totally off of the database. The number of criteria, the
options, the charts, everything. The game was to push as much in to
the DB as possible (his domain) and keeping the front end simple so
he could maintain it.
He populates a table with the IDs and Labels of the criteria
categories. The IDs also happen to be the names of SQL Views that
hold the name/value pairs of the criteria IDs and their labels
(sorted of course). The chart pages are simple JSPs with the name
derived from the chart set ID that he's using.
This is all driven by a single action bean, with a 25 line core
action. (DAO is separate, straight JDBC...)
Once the JSP loads, it presents the Flash Chart component that
happens to have a hard coded URL in it. This calls a separate action
bean that pulls the criteria from the Session, calls a Stored
Procedure, and streams back the XML for the chart, using
StreamingResolution of course. Do I like using the Session data? Not
really, but we don't know yet if or how we can influence that XML
Feed URL in the chart, so it has to be static, and a separate
request, so we use Session data -- no big deal.
The beauty of Stripes comes through with this little gem:
<c:forEach items="${actionBean.paramLabels}"
var="label">
<td>${label.name}</td>
</c:forEach>
</tr>
<tr>
<c:forEach items="${actionBean.paramLabels}"
var="label">
<td>
<c:set var="name" value="selections[$
{label.label}]"/>
<s:select name="${name}">
<s:options-collection collection="$
{actionBean.dropDowns[label.label]}" value="id" label="name"/>
</s:select>
</td>
</c:forEach>
These two loops build up the N drop down boxes with whatever
selections happen to be in the DB. They all bind to the "selections"
variable, which is simply a Map<String, Integer>, and this is stored
in the Session. Notice these three specific lines:
<c:set var="name" value="selections[$
{label.label}]"/>
<s:select name="${name}">
<s:options-collection collection="$
{actionBean.dropDowns[label.label]}" value="id" label="name"/>
You'll note the s:select name is of the "selections[ID]" style (our
String->Integer map). Meanwhile, dropDowns is a Map<String,
List<Property>>. JSTL handles that dereference to get us the specific
list for each drop down. Thankyouverymuch.
That's it. "Instant", dynamic, DB driven form. 1 drop down or 100
drop downs. Whatever he wants. Even better, when the form reloads, of
course all of those dropdowns retain the values the user selected. I
mean, of course they do. That cost me a big zero to implement.
Tomorrow, he's going to finish populating his DB data, finish his
charts, throw in container managed security to keep the rubes out,
and tweak some CSS and HTML to pretty it up.
Why is this remarkable? What's the big deal?
The big deal is this stuff just worked. I had that form working the
FIRST time. It Just Worked.
But here's another thing. I haven't been doing much front end and
stripes work at all in the past, what, 6 months. I've been head down
in server infrastructures and fighting IDEs and web services.
But I was able to create a new project, copy and past the few web.xml
entries that EVERY Stripes app uses, drag and drop the few jars I
need and get my basic action bean firing in short order. The key was
as a guy who can't remember his wifes cell number, I was able to
retain enough Stripes "arcana" to pull this thing off without a
hitch. Because Stripes is simple, and works as expected.
I had to web crawl <c:forEach ... >, but I ALWAYS have web crawl
that. Just..well, just cause -- it's a curse. But Stripes? I've
always said the magic of Stripes is in its binding. The binding Just
Works, and works as expected. Can you imagine doing this in Struts 1?
omg.
I can't compare Stripes to any of the other modern action frameworks,
but the real key point here is -- I don't have to. I don't have a
need to look at the others.
Monday is going to come and they're going to have a pretty good app,
and we got it turned around fast because I have a framework that
stays out of the way and just works.
Regards,
Will Hartung
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
