Stripes 1.5
Monday, 18. August 2008, 23:24:52
The guys behind the Stripes web framework shoved a version 1.5 out the door today (well, yesterday - it's past midnight here).
Here's the link: http://www.stripesframework.org/
So, this is where one usually talk about why this is cool, but truth is; I only just started creating anything with Stripes today/yesterday, and that is even with the previous version 1.4.3. Still, I'de like to get my initial judgment across, because I think that this framework is undervalued and dosn't get the talking-about it deserves.
The thing about Stripes is how it combines simplicity and flexibility. You can configure and customize a ton of things - but you don't have to, because almost everything has a reasonable default. The only required configuration is that you need to tell it where you controllers, or ActionBeans, as they're called, live. From then on, Stripes is pretty much just a request dispatch mechanism and a tag library.
This brings me to my second nice observation: Stripes is all about the presentation layer, and Stripes is only about the presentation layer. It dosn't care about how you talk to a database or if you even have one. It is also isn't particulary picky about how you organise you controllers - it uses annotations to figure out who does what and when. These annotations can also be used for input validation on forms, it seems, but I have yet to try out that feature.
The requests are dispatched to your action beans, and by default the URL is based on the fully qualified class-name of that bean. However, this can be overwriten with a UrlBinding annotation on the class. The methods on the class may then be annotated as handlers of some sort. You usually annotate a DefaultHandler, and then annotate the other methods to match the names of submit buttons on forms, or stripes:link tags. To communicate state from request parameters to your ActionBean, and from your ActionBean to you JSP or other view file, you use getter and setter methods on you ActionBean - this makes them non-thread safe, but that dosn't matter because they're created on a per request basis.
At first you might run into problems getting Stripes to find the right ActionBeans for the right URLs - especially if you use the UrlBinding annotation, but fret not. Just leave your JSP files in their default place, make sure you have configured the proper packages for the ActionResolver.Packages init-param in your web.xml, and finally check that the URL that you specified in your annotation will actually be hit by the Stripes DispatcherServlet and then you should be on your way.
With this, I'm starting to like Stripes; the simplicity and reasonable default configuration let me see some fireworks in short order, and yet it allows me to configure and tweak and customize the parts I need. Simple on the surface, flexible underneath - that should be their slogan. They put it like this on their home page:
And I'm thinking they're getting close to home on that one. So even though I've only been working with this framework for a few hours, I have a feeling I'll be sticking to it.
Here's the link: http://www.stripesframework.org/
So, this is where one usually talk about why this is cool, but truth is; I only just started creating anything with Stripes today/yesterday, and that is even with the previous version 1.4.3. Still, I'de like to get my initial judgment across, because I think that this framework is undervalued and dosn't get the talking-about it deserves.
The thing about Stripes is how it combines simplicity and flexibility. You can configure and customize a ton of things - but you don't have to, because almost everything has a reasonable default. The only required configuration is that you need to tell it where you controllers, or ActionBeans, as they're called, live. From then on, Stripes is pretty much just a request dispatch mechanism and a tag library.
This brings me to my second nice observation: Stripes is all about the presentation layer, and Stripes is only about the presentation layer. It dosn't care about how you talk to a database or if you even have one. It is also isn't particulary picky about how you organise you controllers - it uses annotations to figure out who does what and when. These annotations can also be used for input validation on forms, it seems, but I have yet to try out that feature.
The requests are dispatched to your action beans, and by default the URL is based on the fully qualified class-name of that bean. However, this can be overwriten with a UrlBinding annotation on the class. The methods on the class may then be annotated as handlers of some sort. You usually annotate a DefaultHandler, and then annotate the other methods to match the names of submit buttons on forms, or stripes:link tags. To communicate state from request parameters to your ActionBean, and from your ActionBean to you JSP or other view file, you use getter and setter methods on you ActionBean - this makes them non-thread safe, but that dosn't matter because they're created on a per request basis.
At first you might run into problems getting Stripes to find the right ActionBeans for the right URLs - especially if you use the UrlBinding annotation, but fret not. Just leave your JSP files in their default place, make sure you have configured the proper packages for the ActionResolver.Packages init-param in your web.xml, and finally check that the URL that you specified in your annotation will actually be hit by the Stripes DispatcherServlet and then you should be on your way.
With this, I'm starting to like Stripes; the simplicity and reasonable default configuration let me see some fireworks in short order, and yet it allows me to configure and tweak and customize the parts I need. Simple on the surface, flexible underneath - that should be their slogan. They put it like this on their home page:
Stripes aims to provide an experience similar to owning Apple hardware, Sony TVs and luxury German cars (without the price premium); things just work, they feel right and every now and again you get that "oh, it does that too? awesome!" feeling.
And I'm thinking they're getting close to home on that one. So even though I've only been working with this framework for a few hours, I have a feeling I'll be sticking to it.
WIDGETIZE