I think one of my favorite features of Stripes is indexed property binding. With Stripes is it so simple. Let me give an example. I currently building an ad hoc reporting tool for an existing web application. Unfortunately this piece was an afterthought by the original developers so there is a lot of static data in code that I have to deal with. So to get around that I am wrapping the static data in my own objects and persisting them to the database, then I will fetch them to help build the query.
The following class is a (simplified) version of my StoredReport object:
Here is StoredReportGlobalItem
The following is a piece from the JSP for the form. In the actual JSP there are about 20 rows of these but for the sake of this example I am only showing one variation.
When I POST this form Stripes automatically instantiates and populates any depth of properties at the correct index and places the values accordingly. But the real benefit isn't in the POST. Now I need to edit a stored report. What has to be done on the JSP to support edit mode?
I create an edit link like so:
I create method in my ActionBean like this:
The ForwardResolution forwords the request to the same JSP I use to create new reports. But since the StoredReport object now contains all its properties Stripes populates the HTML accordingly with its taglib. [ November 19, 2008: Message edited by: Gregg Bolinger ]
The only real thing I omitted from this is some methods to populate select lists on the JSP. All they are were calls to DAOs.findAll() methods. But for creating a new report, saving, and editing an existing report this is how simple it is.
Now, what did I have to do so Stripes knows about this Action?
What did I have to do so Stripes understands my navigation and what I want to happen when things after events?
It's all right here in this java code. No additional XML or properties of any kind of wire things up.
This specific feature of Stripes binding can not be underestimated.
There is a lot of power in being able to do something like this:
Assuming these simple beans:
When this form is submitted, Stripes will: a) Create a list (an ArrayList) b) create the Map (a HashMap) c) create an empty MyData d) bind the name to the MyData name field e) convert the age to an Integer and bind it to the MyData age field f) convert the date to a Data and bind it to the MyData date field g) put the MyData in the the Map using the "theKey" key f) put the Map in to the 10th slot of the ArrayList
If any of those bindings fail, it will redisplay the form, WITH the bad values, and flag the offending fields.
You get all of that "for free", out of the box.
This makes developing things like forms with dynamic fields VERY easy to do, yet still leverage the binding and validation capabilities of Stripes.
When it comes to dynamic forms, a lot of frameworks make you toss out much of their functionality and rewrite it from scratch because they only work well with static fields.
The dynamism of Stripes binding is very powerful.
He's giving us the slip! Quick! Grab this tiny ad!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop