Speaking of other frameworks, how do people think Stripes compares with
Wicket which seems to be getting quite popular. I looked at the wicket book
and it seemed that wicket did a few bad things that stripes does with ease,
and that it did a few things that stripes doesn't do
Thoughts?
Alex
On Sun, Nov 2, 2008 at 1:49 AM, Will Hartung <[EMAIL PROTECTED]> wrote:
> 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
>
-------------------------------------------------------------------------
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
