[Colorado Software Summit] Spring and Comparing Web Frameworks
I'm pleased to announce that I'll be speaking at the Colorado Software Summit in October. I'll be doing a presentation on Spring and one on Comparing Web Frameworks. The abstracts are on my very own speaker page. I've never been to this conference, so I'm definitely looking forward to it - especially since it's only an hour away from my house. The only downside to the conference (for speakers) is you have to deliver each presentation 3 times. Of course, this is great if you're an attendee. Now I just need to figure out a way to get SourceBeat to sponsor my condo for the week.
I originally did my Web Frameworks Comparison (PDF) last year at ApacheCon. I'm looking to revamp it this year - so please let me know if have any suggestions for improvements.
Posted by Keith Weinberg on May 09, 2005 at 01:04 AM MDT #
Posted by KK on May 09, 2005 at 02:00 AM MDT #
* On the Struts Pros/Cons "ActionForm they're a pain" - since Struts 1.2.4 the "form bean" doesn't have to be an ActionForm - if you specify a POJO or DynaBean in your struts-config.xml then Struts will automatically "wrap" it in a BeanValidatorForm.
* On the Struts Pros/Cons "Can't unit test" - Struts 1.3 will allow moving from Action's to Commons Chain Commands which should enable easier unit testing.
* on the "Success Messages" page - Struts 1.2.7 now provides similar functionality for "errors" as it does for "messages" - i.e. saving them to the Session with automatic removal after access. Also new in 1.2.7 - "ActionRedirect" object is an ActionForward with the facility to add parameters.
* on the "Internationalization" page - don't understand the comment about Struts encouraging one resource bundle per locale. Struts supports multiple resources bundles (using the "bundle" attribute on tags) - version 1.2.7 also now extends this support to Commons Validator.
Posted by Niall on May 09, 2005 at 02:24 AM MDT #
1. Not just pros and cons, but a comparative matrix as well (even if the users at the conference need to print it because it wouldn't fit on a screen). You could make this as a comunity project thru' your WIKI, so that till the conference you could have a rafined(/improved) version of it, with lot of user participation.
2. Load testing numbers for all the frameworks on the same reference machine.
3. Client response time for all the frameworks on the same reference machine.
4. Complexity of bug search (e.g. in tapestry is easy because of that line precise ... )
Obs:
1. would be very useful to have a better decision process
2,3. can't be found at the moment for none of the frameworks in Internet, and would give a very unique aspect to you paper.
4. would be very important to be able to estimate the maint. costs of the project.
IMHO, having these detailed numbers, would allow users a better decision about what framework for what project to choose, and even more - to convince the management(where it's required) that the choosen framework was the best alternative.
Posted by Ahmed Mohombe on May 09, 2005 at 10:14 AM MDT #
Posted by sergio on May 09, 2005 at 12:56 PM MDT #
Posted by Matt on May 09, 2005 at 02:53 PM MDT #
Posted by Mike Bowler on May 09, 2005 at 05:42 PM MDT #
Posted by Bruce Atherton on May 09, 2005 at 10:18 PM MDT #
Niall - #1 sounds very interesting. I'd love to get rid of the ActionForm XDoclet generation in AppFuse and just declare my POJOs as forms in my struts-config.xml file. Hopefully this works as you say it does. #2 sounds cool - but when is 1.3 coming out? #3 - regarding errors, I know - I filed the bug. ;-) ActionRedirect sounds very cool too. #4 Internationalization - WebWork and Tapestry by default expect you to have a resource bundle per Action/Page. I prefer the Struts way, and have never really found a need for the "bundle" attribute.
Ahmed - sounds like a good exercise, but I don't know if I'll have the time to do it. If anyone else wants to do it, I have the machine and the frameworks setup to do it on.
Bruce - I've had other requests to add Cocoon to my comparison. Unfortunately, I'm not that interested in learning Cocoon. All the other frameworks I wanted to learn . If nothing else, I've seen a lot more demand for them than Cocoon. As far as RIFE, I've seen no demand for it at all.
Posted by Matt Raible on May 10, 2005 at 08:13 PM MDT #
Posted by Niall on May 11, 2005 at 02:59 AM MDT #
Posted by Lars Fischer on May 16, 2005 at 09:50 PM MDT #
Posted by Eelco on May 17, 2005 at 05:19 PM MDT #
Eelco - personally, I don't have a lot of interest in learning Wicket, Cocoon or RIFE. That's why none of them is in my comparison. If there comes a time where their features or ease-of-use sounds better than my current tools, I'll be sure to learn them and add them to this presentation. Of course, I can be bribed too. ;-)
Posted by Matt Raible on May 18, 2005 at 05:17 AM MDT #