News: Stripes: annotation-driven web framework released
Stripes has been released for download. Stripes is an annotation-driven web framework, that tries to avoid external configuration by providing annotations to manage configuration details. Stripes looks like a very light framework, with three jar files required for runtime (with Log4J being an option.)
- Posted by: Joseph Ottinger
- Posted on: September 07 2005 10:32 EDT
Annotations provided via Stripes cover two primary areas: dispatch and validation. Dispatch annotations (@UrlBinding, @HandlesEvent, @DefaultHandler, and @SessionScope) manage handlers and how they're invoked; Validation annotations (@DontValidate, @Validate, and @ValidateNestedProperties) address validation operations, obviously enough.
There's also a tag library provided, that covers the typical HTML form tag library, as well as some binding for errors.
The web site for Stripes includes a quick start guide, a reference manual, and a sample application, as well as a comparison with Struts.
As the download page shows, releases are being made on a regular and constant basis.
What do you think of the direction Stripes has taken? The developers have committed to Servlet 2.4/JSP 2.0 and JSE 5, which frees them to do some fairly elegant things such as having configuration done completely by annotation, and they've avoided configuring things that JEE 5 provides for them. What potential do you see for this technique?
- Stripes: annotation-driven web framework released by rags kidiyoor on September 07 2005 13:38 EDT
- The problem with annotations: multiple contexts by Jason Carreira on September 07 2005 14:29 EDT
- OK, I'm confused by Jing Xue on September 07 2005 15:11 EDT
Looks cool to me. The action binding is simple and natural. However, I still have one gripe -- the page designers need to learn stripes tags, just as they did in Struts. In the projects I have worked on, the pages are designed in HTML for review and an extensive work is required to convert them into JSPs with framework tags. Any future incremental review is painful at best. I liked Tapestry for this very reason and I must say that its designers got it right.
So, IMHO, there are 2 categories of frameworks - one that tries to solve the problem with no regards to existing frameworks (Tapestry, for example) and the other, a competitor to Struts. Stripes falls into the second category.
I love annotations, and use them frequently where they make sense. The problem is that annotations are very static and don't give you a lot of contextual control. This is not a problem with annotations, per se, as that's what they're designed to be, but in terms of different behavior at runtime based on context, they're not so good.
So in the simple case for a web application, annotations seem like a great idea. One class = one action handler / controller = one set of validations. Unfortunately, this is only true for simple applications, and you quickly find yourself wanting to have multiple configurations for the one action class, each with different sets of parameters and different dispatch rules. You might also want different validations for each of the different configurations, or to be able to reuse your validations across different contexts (web vs. batch mode). In this case, annotations blow up on you because you have to start contextualizing every configuration and you quickly have more lines of annotations in your class than you have business logic.
With WebWork we've had people ask about XDoclet and annotations for configuration and validation for years, and I've been happy to point anyone who wants to do it in the right direction, but I point out to them the issues they'll face with multiple contexts. Some efforts have been made, but they never support more than the simplest 1-1-1 mappings. We're going to look at implementing annotation support for config and validation later this year, and I expect we'll probably end up punting on more complex mappings for this very reason, but in our case, you'll have the XML file to fall back on. When annotations are all you have, then the simple case is all you get.
Anyway, good luck to the Stripes developers. It's a tough market, even when you're giving your work away for free :-)
Why did we decide to move all the action url's and event names out of the source code and keep them in an XML file in the first place?
Cause we love XML and we need to justify our salary.
Just reading through the comparison and have a feeling that author's efforts could be directed on improving Struts instead of creating a new framework.
Number of artifacts. Yes, one has to create a bunch of objects/artifacts to make even one simple page, and Stipes is better in this sense. Can Struts be improved? Sure. Stripes has a simple return new ForwardResolution("/bugzooky/BulkAddEditBugs.jsp") object to forward to a view. Great, but one does not have to use indirection like return mapping.findForward("success") in Struts either. Just create a new ActionForward object on the fly. Events can be easily mapped to methods with some sort of DispatchAction, while not so simple as with annotation, that is true. But mapping through a separate file is more flexible. Whether you need the flexibility or not is another question.
Incremental development. Yes, in Struts a JSP cannot be previewed if bean data is not initialized. This calls for updates and fixes in Struts. But a new framework?
Property binding. "Struts lets you use nested properties, and that's great. But say you have a property on your Form 'person.address.line1'. Struts will try and set it for you, but if person or address is null, you'll be very sad indeed." Again, this issue is the perfect candidate for improvement in Struts.
Validation. "Validation in Struts is divorced from Type Conversion. This is just plain wrong. Why validate that something is a well formed date, then spend a whole bunch more effort converting it to one?" I am not happy with Struts validation either, but at least I am free to do whatever I want with input data. I can define string properties and go wild. Also, there is a project, which tries to solve exactly this problem: StrutsLive!. Instead of devising own framework, it would be better to evaluate and maybe include StrutsLive! or portions of it into future versions of Struts.
Null mean Null. "Ask yourself this. You have an int property in your form bean and the user doesn't enter a value in a text box. What should your property be set to?" Right, Struts uses default values for non-string properties. The answer is using string properties only. This is what I do and it gives me full control over input data. Try the aforementioned StrutsLive! project for automatic validation, or check out FormDef project.
Formatting. "The Struts FAQ says this (among other things) in answer to why the Struts tags provide so little formatting: First, work started on the JSTL and we didn't want to duplicate the effort. Second, work started on Java Server Faces, and we didn't want to duplicate that effort either. Third, in a Model 2 application, most of the formatting can be handled in the ActionForms. ... Great. JSTL doesn't have form tags, so while JSTL is great, it doesn't really help here. JSF and Struts don't mix so well even now, and that's a reason to leave people without formatting for years? And the last is just a cop-out."
Right. So, why not to solve this issue for Struts users instead of creating a brand new framework? Why not to submit patches to Struts codebase? See aformentioned FormDef project, which performs data formatting, data conversion and locale support.
Multi-Event Actions. "If you want to have a form that submits multiple different events in Struts you have to either extend the DispatchAction or write your own support for it. And since the DispatchAction requires all buttons to have the same name, and uses the value to determine the method to invoke, it's a huge pain if you're using localized or even just externalized values for your buttons." Multi-event actions are easy with Struts Dialogs library. This library also allows to create simple JSP components using two-phase request processing.
JSP / View Helpers. "Struts doesn't really provide a good pattern for providing dynamic data to JSPs that are not the result of another Action. This leaves you with the options of writing a pre-action for the page or doing something outside of Struts." Struts Dialogs provides an easy development approach with only one action class per web resource, so supplying view data and collecting input data is easy.
"HTML" Tags. "Maybe it's just me who could never get used to it, but why do the Struts form input tags use 'property' instead of 'name'? And why is it 'styleClass' instead of 'class'?" The reasons were explained in Struts mailing list, while I accept styleClass, I dislike property instead of name. And the docs for Struts tags beg for improvement. This is what I would rather see instead of another framework announcement.
From what I've read so far on Stripes, it is not so much different than Struts, so I don't see a point converting. On the other hand, if I decided to abandon Struts, I would rather try something completely different, like Tapestry or Wicket. Nevertheless, I wish Stripes all the best, the framework market is tough as never before ;)
P.S. Posting is screwed up. I can post only to the last message in the tree. Cannot add comment to the root message.
I think you missed the top-most "Post Reply" - the article itself is considered as the first "Item" in the thread. There is a "Post Reply" button above it.
Strange indeed, but true.
Thanks for the insightful comparison. I'm not an expert with Java frameworks and haven't got the time to read the article but your comments make sense.