Matt Raible has a new presentation in which he compares a sprinkling of web frameworks. He discusses the technical, and political merits of Struts, Spring, Tapestry, WebWork, and JavaServer Faces. Do you agree with his conclusions?

Matt Raible presents Comparing Web Frameworks

Had a look at it. I would personally share the conclusions, even if I must point out the following:

1) JSF could probably take more space because of its "standardness" and vendor-support. This could be a perspective choice in a corporate environment;

2) Tapestry, Spring, etc. are excellent tools but if you need support, you may lack of it, especially in Europe;

3) Struts is the de-facto choice and IMHO the best but you have to do a lot of work for preparing a decent framework upon it.

3) Struts is the de-facto choice and IMHO the best but you have to do a lot of work for preparing a decent framework upon it.

why do u feel it is the best...

I didn't want to do this at first even though several users already pointed me to Matt Raible's post. Since it was pretty clear from the outset that he was only comparing the 'top 5', I didn't see any point in starting to comment about less known alternatives. However since Barracuda and Wicket have been mentioned I now can't refrain from pointing towards RIFE.

The RIFE (http://rife.dev.java.net) web application framework is very complete and offers everything that you need for most web applications. Some complex projects we didn't didn't required more that the basic RIFE jar. Recently, Bamboo (a web forum application - http://bamboo.dev.java.net) has been released and it can been released and perfectly fits the bill as a demonstration application with available source code. For a detailed featurelist, I point you to the project's website and the wiki (http://rifers.org/wiki).

Recently someone inquired about the differences between RIFE and WebWork and opted for RIFE after he read the mailinglist post and evaluated the project. You can read this post here: http://www.uwyn.com/pipermail/rife-users/2004-September/000643.html

Shame you can't edit or preview your posts at The ServerSide
Apart from the spelling errors, a better link to the RIFE wiki is http://rifers.org/wiki/display/RIFE/Home and the cookbook is probably the most interesting: http://rifers.org/wiki/display/RIFE/Cook+Book

Tapestry is mostly a presentation layer framework, concerned only with generating and interacting with the user interface.

I think this is a pretty good approach in that it lets you pick Spring, EJBs, etc. as your underlying tier.

Tapestry, Spring, etc. are excellent tools but if you need support, you may lack of it, especially in Europe;

FYI, Rod is based in London, Alef is based in the Netherlands, and I am based in Austria. So actually, half of Interface21, the company offering "Spring services from the Source", is based in Europe...

Juergen

JATO (now called Sun One Application Framework)is an MVC framework developed by Sun. The current version is commercial, but we are still developing with the last free version (1.2).

We were able to learn JATO and develop a complex web application in 2 months. It blows Struts away as far as simplicity, TRUE MVC architecture and completeness. It has an extensive model framework (including a powerful tree view). The support is great (and free) via their news group. Since it is now commercial, it seems to have lost some of its traction. However, as I said, we are using the free version with tremendous results. Has anyone else has any exposure to JATO, good or bad?

Thanks...
Ted Jones

I would encourage the readers to take a serious look at Barracuda (www.barracudamvc.org) - IMHO it may be the most flexible and powerful of the bunch, and one I chose easily over Struts. My team has used it for several years - have found it solid and well supported.

Are there any really sane people out there using Barracuda on real projects? I have evaluated Barracuda in the past and found it over engineerd. Also it seriously lacks good documentation and even their online examples don't work. During my evaluation I had to dig through the source code to really understand the framework. After I came across it I regretted the time and effort I had put in it because I had several concerns including scalability of it in real world applications.

Waste your time on proven frameworks instead. Currently my favorite is tapestry. I've used tapestry on a number of projects and haven't had any regrets.Its one of the best that exists today.

My .02 cents.

After I came across it I regretted the time and effort I had put in it because I had several concerns including scalability of it in real world applications.

And what are those scalability problems according to you? We've used Barracuda for 3 years now (in several large web application with now more then 270 screens).

I understand that people quickly get a personal bonding with their favorite web framework, but don't be too quick with unfounded statements.

I read about Wicket here on TSS. Having used Echo and Tapestry I thought I would give Wicket a shot.

It is in Alpha, and continually evolving, but I tell you, I have never experienced this level of productivity for developing a website. I have written some about it.

If you hate JSP and HTML but love OO and simplicity, I think you will really like Wicket. But be prepared, it is in an Alpha state, for some reason the documentation is not in the lates release either.

http://c2.com/cgi/wiki?JdoWebApp


-geoff

I'll be meeting with Matt at ApacheCon and hopefully will be able to attend his presentation. I expect to gently persuade him to accept the Tapestry cool-aid a little more heartily. Really! He just fell down those stairs. Twice. :-)

As regards the Tapestry Documentation and the supposed lack of examples: the Tapestry In Action book is really a great book, with a ton of useful, full-featured examples. As a learning tool, it is excellent. I can highly recommend it to anyone. In addition, my Tapestry experience has really been nothing but positive, although somewhat limited.

I have not used the Barracuda framework but I have used XMLC which is the base of it's page generation engine and IMHO currently (XForms anytime soon?) it is the best aproach to solve the HTML based presentation problem I have found. I think it is the cleanest solution to web contents generation (even if XSLT could be considered cleaner it easily get's to hard to be used in generic scenarios) although it's learning curve might be somewhat harder than other aproaches like Velocity and Struts.

Regards.

Ignacio.

Ignacio,

I have not used the Barracuda framework but I have used XMLC which is the base of it's page generation engine and IMHO currently (XForms anytime soon?) it is the best aproach to solve the HTML based presentation problem I have found. I think it is the cleanest solution to web contents generation (even if XSLT could be considered cleaner it easily get's to hard to be used in generic scenarios) although it's learning curve might be somewhat harder than other aproaches like Velocity and Struts.

I agree, the XMLC approach is interesting. I discussed it in Expert One-on-One J2EE Design and Development, and the Interface21 framework, which became Spring, supported it. That support could easily be ported to Spring, but no one has ever asked. Which is the sad thing about XMLC as a technology, I think. It did provide a nice separation between Java developer and HTML editor roles, but it just doesn't seem to have gotten much momentum.

Rgds
Rod

Hi Rod,

>>It did provide a nice separation between Java developer
>>and HTML editor roles
>>but it just doesn't seem to have gotten much momentum.
I guess this is because it provides a great VIEW mechanism for mVc but nothing else. Most people when looking for a framework will try and get the whole stack from one source rather than trying to integrate product from different sources. Barracuda probably provides a great controller for XMLC but arrived years after Tapestry (which I guess is its nearest competitor in terms of ideology and complexity) so it was probably simply too late to market.

>>That support could easily be ported to Spring, but no one >>has ever asked.
PLEASE PLEASE add this to Spring. This could be enough to attract the critical mass around XMLC that it deserves. XMLC's approach of doing one thing very well and nothing else fits Spring's philosophy perfectly.

Thanks,
Richard

ps. I am a part-time Java developer who occasionally does web-apps. I've used XMLC and loved it but apart from that have no connection to the XMLC developers. When I do web-apps I need to leave something behind me which will be easy to maintain when I leave - ideally without a learning curve.

Richard

That support could easily be ported to Spring, but no one has ever asked.

PLEASE PLEASE add this to Spring. This could be enough to attract the critical mass around XMLC that it deserves. XMLC's approach of doing one thing very well and nothing else fits Spring's philosophy perfectly

Please contact me offline and I'll send you the code. You can send me a private message through the Spring forums. Porting the XMLC support from the Interface21 framework to Spring should be straightforward: mainly involving changing the package names, and updating to work with any changes to XMLC since I last tested it in late 2002.

If you're happy to test it, and perhaps do some documentation, we should be able to make the integration available as a separate download quite soon. I don't think it should go in the Spring core as the binary dependencies of XMLC are very large.

One of the key drivers of Spring's MVC framework design is to allow for any view technology without changing controllers or models. Another reason that, as you say, XMLC support would be very much in the spirit of Spring.

Rgds
Rod

I am also interested in using spring with XMLC within enhydra 5.0.

I have used xmlc extensively, and am now considering spring. May I have a look at the code/docs you mention please?

I will try to create a page on the Spring wiki with the code and a little discussion. Hopefully I should have time to do this next week.

Rod Johnson
J2EE without EJB
Spring from the Source

XForms anytime soon?

There's Chiba, which is a server side implementation.

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP. ActionForm is an optional element of action mapping, but I find it useful.

Why Spring requires to write a lot of code in JSP?

What are success messages? Is this the same what I call result page (the one that generated after the POST)? Spring allows for very easy usage of redirection via RedirectView class. PetClinic now uses it, works very nice right out of the box. But after I made a small helper library for myself, I am pretty happy with Struts as well.

Struts got a market recogntion as has a lot of inertia. The solutions for its quirks are known. It is mature platform and it works, so I do not see the point to switch to something else right now.

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP.

It's exactly why they are pain. Next subset of Your domain model reimplement in different layer. Everytime You extend model You have to reflect changes in transfer objects. It's why "nonintrusive" frameworks like Hibernate ("POJO persistence") or Spring (regular beans as form backing objects) gains so much attention.

Why Spring requires to write a lot of code in JSP?

It's because Spring developers decided not to emit html from within Spring tags. So page could be developed by non programmers. But on the other hand <spring:bind> requires lot of more code than e.g. strtus version. Ever tried mapping of multi select is spring?

Artur

Everytime You extend model You have to reflect changes in transfer objects

You do not need transfer objects, you can use just a DAO that returns a collection (of rows).

You can chose to have transfer objects but then don't complain about using it if you chose to use it. There are many way's to do Struts and some are better than others.

.V

That collection (of rows) is actually Transfer Object.

That collection (of rows) is actually Transfer Object.

In this case harddrive platter is transfer object as well ;-) But at least it does not require additional programming.

You do not need transfer objects, you can use just a DAO that returns a collection (of rows).You can chose to have transfer objects but then don't complain about using it if you chose to use it. There are many way's to do Struts and some are better than others..V

Actually I hate DTOs. I consider this very bad idea and a maintenance nightmare (I work with huge legacy application with CORBA as a middleware few levels of DTOs - idl structures in C++ (business), idl structures in java (presentation) etc). Actually I don't use DTOs if I don't have.

Artur

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP.

It's exactly why they are pain. Next subset of Your domain model reimplement in different layer. Everytime You extend model You have to reflect changes in transfer objects.

Simply not true.

Usually Struts Action form for has only one field: Domain Object,
and MAY have additional fields to help addressing HTML defficiences ( checkboxes handling for example ).

You cannot use domain objects in struts action forms as the only reference to form data as you need to have a "holding" area where you hold the form data since it has to go through validation (plus domain objects properties are typed so type conversions need to be validated as well.)

You should want to a) first validate all form data and b) if all validation passes then push the data to the domain object and then to the db. Unfortunately this tends to duplicate the fields but the only other solution is pushing it to your domain model pre-validation and then you have a domain object in a potentially non-validated state which while possible is bad design (in my opinion).

Bruce

You cannot use domain objects in struts action forms as the only reference to form data as you need to have a "holding" area where you hold the form data since it has to go through validation (plus domain objects properties are typed so type conversions need to be validated as well.)You should want to a) first validate all form data and b) if all validation passes then push the data to the domain object and then to the db. Unfortunately this tends to duplicate the fields but the only other solution is pushing it to your domain model pre-validation and then you have a domain object in a potentially non-validated state which while possible is bad design (in my opinion).Bruce

You are absolutely right. Within "classic" Struts model with one form bean per action it is hard to use domain objects directly for output. This is exactly why I use two form beans per action. What is more, I often use two action classes too.

You have an "input" form bean which represents your HTML FORM, and which you can easily validate. If you happy with your input, you update your domain model and forward to (or, which is better, redirect to) your output action. Output action can have only one reference somewhere to domain model. Output form bean does not have to validate anything, it just locates your data in the domain model, and then JSP dislpays it.

You may want to take a look at the source code in my article here on TSS, describing how to implement redirection from input to output actions in Struts https://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2 It is not exactly on subject but can give you a clue what I am talking about. Not all output forms use domain model directly. For example, ItemFormOutput does not use it, but ItemListForm does. I have another article which discusses different combinations of Struts actions and forms, hopefully it eventually will be published.

You cannot use domain objects in struts action forms as the only reference to form data as you need to have a "holding" area where you hold the form data since it has to go through validation (plus domain objects properties are typed so type conversions need to be validated as well.)You should want to a) first validate all form data and b) if all validation passes then push the data to the domain object and then to the db. Unfortunately this tends to duplicate the fields but the only other solution is pushing it to your domain model pre-validation and then you have a domain object in a potentially non-validated state which while possible is bad design (in my opinion).Bruce

You are absolutely right. Within "classic" Struts model with one form bean per action it is hard to use domain objects directly for output. This is exactly why I use two form beans per action. What is more, I often use two action classes too. You have an "input" form bean which represents your HTML FORM, and which you can easily validate. If you happy with your input, you update your domain model and forward to (or, which is better, redirect to) your output action. Output action can have only one reference somewhere to domain model. Output form bean does not have to validate anything, it just locates your data in the domain model, and then JSP dislpays it.You may want to take a look at the source code in my article here on TSS, describing how to implement redirection from input to output actions in Struts https://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2 It is not exactly on subject but can give you a clue what I am talking about. Not all output forms use domain model directly. For example, ItemFormOutput does not use it, but ItemListForm does. I have another article which discusses different combinations of Struts actions and forms, hopefully it eventually will be published.

Does it ever strike you that if you have to build a framework on top of your framework then maybe it indicates a limitation in your framework?

Does it ever strike you that if you have to build a framework on top of your framework then maybe it indicates a limitation in your framework?

Interesting comment. Ironically, the framework I prefer, Cocoon, is often criticized because it contains so much stuff that it is hard to learn. However, the more I have worked with Cocoon the more I have come to appreciate what an amazing framework it is. Interestingly, it wasn't one of the frameworks that the author chose to review.

Hey, a fellow cocooner. I was a big fan, even an erstwhile developer on the cocoon project back in the day, and it would still be my first choice (well, maybe after Zope) for most any large information system type site. But for business applications, I frankly haven't yet found a framework that didn't eventually cause more pain than it eased.

I write my own servlets, and I control my own URLspace, and it's a cool one, thank you very much. Every object has a URL. GET requests view things, POST requests modify state, everything is grand. I keep my business logic and web logic distinct by transforming HttpServletRequests into BusinessRequests, vice versa with the responses.

Less is more. But if you need more, do give cocoon a look-see.

Does it ever strike you that if you have to build a framework on top of your framework then maybe it indicates a limitation in your framework?

Interesting comment. Ironically, the framework I prefer, Cocoon, is often criticized because it contains so much stuff that it is hard to learn. However, the more I have worked with Cocoon the more I have come to appreciate what an amazing framework it is. Interestingly, it wasn't one of the frameworks that the author chose to review.

I don't mean that a framework should include everything, just that it should be designed in such a way that it can be easily extended through extension points made available by the framework. I've seen cases with Struts where people create just one Action and use that as a dispatcher to do something differernt from what Struts does. Another common thing to do with Struts is to have to create a subclass of the request dispatcher. Frameworks like WebWork and Spring which allow for interceptors allow for much more flexibility in extending the framework and integrating other projects.

I've seen cases with Struts where people create just one Action and use that as a dispatcher to do something differernt from what Struts does. Another common thing to do with Struts is to have to create a subclass of the request dispatcher.

There is one small framework 'OzStruts' on top of Struts using this approach.

Documentations at
http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=120334&release_id=280886

What is does are
1:Page oriented programming without Action and ActoinForm maze.
2:Consistent pre-population sequence, even on the validation error page transition, which is one of the most ugly part of Strus.

There is one small framework 'OzStruts' on top of Struts using this approach.Documentations athttp://sourceforge.net/project/showfiles.php?group_id=111296&package_id=120334&release_id=280886What is does are1:Page oriented programming without Action and ActoinForm maze.2:Consistent pre-population sequence, even on the validation error page transition, which is one of the most ugly part of Strus.

Why would not you just say "Here is my project, guys, take a look". Anyway, Page-based approach is not for me. I am happy that I do not live in ASP.NET land, where Page Controller makes the cornerstone of a web app.

Page-based approach is not for me. I am happy that I do not live in ASP.NET land, where Page Controller makes the cornerstone of a web app.

Oh, I didn't know that page-oriented == ASP.NET!?
It's come from my Struts experiences, and I still want to use it.
I have mentioned pains of current Struts development in my articles. So if you don't mind, please let me know why page-based approach is not good? because I may be missing something important.

No reason to retype it so read this white paper

http://www.nextapp.com/products/echo/doc/white_paper.html

http://www.nextapp.com/products/echo/doc/white_paper.html

It is very interesting, and I didn't know this. I understand you call all the conventional web applicaiton developments are page-based, not only for my framework.
The term page-oriented and page-driven I am using is in Struts development approaches, so we're discussing different thing, even though both are page-based from your point of view.

No reason to retype it so read this white paper ...

"Sometime it's worth to know the subject" or "who does not love free advertising?".

Does it ever strike you that if you have to build a framework on top of your framework then maybe it indicates a limitation in your framework?

If a framework is used in quite a few deployments, and is still popular, why not to share the experience of how to make life with it more productive and, may I say, pleasant?

Does it ever strike you that if you have to build a framework on top of your framework then maybe it indicates a limitation in your framework?

I don't agree with that. No framework can address all the issues with a specific framework. At my job, I was asked to create a framework that would allow us to quickly and consistently code our specific types of web frameworks. This framework is based on Struts, Spring, Hibernate, and Livelink.

The out of box lack of support for Livelink is not a limitation of Struts, Spring, and Hibernate(SSH). The advantage of using SSH is that once someone sees how we are using all tree, it is still familiar technology.

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP.

It's exactly why they are pain. Next subset of Your domain model reimplement in different layer. Everytime You extend model You have to reflect changes in transfer objects.

Simply not true.Usually Struts Action form for has only one field: Domain Object, and MAY have additional fields to help addressing HTML defficiences ( checkboxes handling for example ).

Ok, and if your domain object has a property of a complex type? How about a collection of related domain objects? Can Struts and commons-beanutils handle the type conversion? That's why I've heard people usually end up using String-only Formbeans.

Ok, and if your domain object has a property of a complex type? How about a collection of related domain objects? Can Struts and commons-beanutils handle the type conversion?

Yes, just register type convertor with commons-beanutils if necessary, I do it for string-date converter. That is it.

That's why I've heard people usually end up using String-only Formbeans.

I feel sorry about them. Guess they did not look at nested taglib or do not understand it.

Simply not true.Usually Struts Action form for has only one field: Domain Object, and MAY have additional fields to help addressing HTML defficiences ( checkboxes handling for example ).

This approach works only if Your domain object has simple primitive type fields. In other (Collections, Dates etc.) cases You have to handle it differently. In fact You end up reimplementing Your business model.

Even if the only property of ActionForm is domain object (I think this approach is not what most developers thinks as best practice for struts...) why simply not get rid of ActionForm like Spring MVC does? :)) As a long time Struts developer I can say I feel *a lot* more comfortable working with Spring, even if I have code more (a bit more) in jsp.

Artur

Simply not true.Usually Struts Action form for has only one field: Domain Object, and MAY have additional fields to help addressing HTML defficiences ( checkboxes handling for example ).

This approach works only if Your domain object has simple primitive type fields. In other (Collections, Dates etc.) cases You have to handle it differently. In fact You end up reimplementing Your business model.Even if the only property of ActionForm is domain object (I think this approach is not what most developers thinks as best practice for struts...) why simply not get rid of ActionForm like Spring MVC does? :)) As a long time Struts developer I can say I feel *a lot* more comfortable working with Spring, even if I have code more (a bit more) in jsp.Artur

Check out WebWork... It's simpler on both the Action side and the JSP side and integrates very well with Spring for IoC, transactions, etc.

Simply not true.Usually Struts Action form for has only one field: Domain Object, and MAY have additional fields to help addressing HTML defficiences ( checkboxes handling for example ).

This approach works only if Your domain object has simple primitive type fields.

Simply not true.

In other (Collections, Dates etc.) cases You have to handle it differently. In fact You end up reimplementing Your business model.

Learn 'nested' taglib.

Even if the only property of ActionForm is domain object (I think this approach is not what most developers thinks as best practice for struts...) why simply not get rid of ActionForm like Spring MVC does? :))

Because there is a need for a place to hold HTML specific handlers ( for example handling collection of checkboxes )

As a long time Struts developer I can say I feel *a lot* more comfortable working with Spring, even if I have code more (a bit more) in jsp.Artur

I would say that working long time with a product does not indicate anything.

This approach works only if Your domain object has simple primitive type fields.

Simply not true.

I disagree. What if You have Map property? You have to add proprietary setter mathod to Your domain object - just because presentation layer limitations. There are plenty examples in struts of problems like above.

In other (Collections, Dates etc.) cases You have to handle it differently. In fact You end up reimplementing Your business model.

Learn 'nested' taglib.

I know nested taglib. This unfortunatelly doesn't solve problems with struts at all. The problem is that certain properties (Maps, Collecions, arrays) to be handled by struts You must provide proprietary getters/setters only used by struts.

Even if the only property of ActionForm is domain object (I think this approach is not what most developers thinks as best practice for struts...) why simply not get rid of ActionForm like Spring MVC does? :))

Because there is a need for a place to hold HTML specific handlers ( for example handling collection of checkboxes )

Disagree. There is no such a need. Just try frameworks which
don't use DTOs to transfer values to/from view. Spring is good example. I recently refactored middle sized project with Spring and my code is cleaner, no DTOs, and I get rid of 30% of classes (moslty ActionForms and various converters).

As a long time Struts developer I can say I feel *a lot* more comfortable working with Spring, even if I have code more (a bit more) in jsp.Artur

I would say that working long time with a product does not indicate anything.
Agreed.

Simply not true.Usually Struts Action form for has only one field: Domain Object, and MAY have additional fields to help addressing HTML defficiences ( checkboxes handling for example ).

This approach works only if Your domain object has simple primitive type fields. In other (Collections, Dates etc.) cases You have to handle it differently. In fact You end up reimplementing Your business model.

See the power of nested taglib:
http://www.keyboardmonkey.com/StrutMonkey/MonkeyStruts_v2.jsp

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP.

It's exactly why they are pain. Next subset of Your domain model reimplement in different layer. Everytime You extend model You have to reflect changes in transfer objects.

To input data from a web page you do not need form beans at all if you comfortable to read values from HttpRequest object. Anyway, form beans are tied to your JSP/HTTP stronger that to domain model, because what you submit is what you get.

For output you can use only one propery on your form, which can be ob some generic type, thus your form would be generic too (Damn, cannot say generic anymore). Struts tags support nested properties, so there is no reason to describe all output data directly in the form bean.

Thanks a lot for explanation on Spring JSP.

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP.

It's exactly why they are pain. Next subset of Your domain model reimplement in different layer. Everytime You extend model You have to reflect changes in transfer objects.

To input data from a web page you do not need form beans at all if you comfortable to read values from HttpRequest object. Anyway, form beans are tied to your JSP/HTTP stronger that to domain model, because what you submit is what you get.

When using jbuilder you can change the actionforms really quick, no xml or java code editing, just a fast to use gui. But you shouldn't change the actionforms frequently, because before making your database model you must have a good idea (sometimes a classdiagram) which object has which field. So in ideal situation you only create the actionform once and after that you never look at it again.

Why Struts ActionForms are pain? They are just transport objects from request to an action, and from action to JSP.

It's exactly why they are pain. Next subset of Your domain model reimplement in different layer. Everytime You extend model You have to reflect changes in transfer objects. It's why "nonintrusive" frameworks like Hibernate ("POJO persistence") or Spring (regular beans as form backing objects) gains so much attention

Maybe I might be totally wrong, but don't you have to reflect changes to the domain model in any way? Either it is in your JSPs, or (in case of Struts) within your presentation object (i.e. ActionForms).

Nevertheless, I like the idea of having presentation obejcts, since it generally reduces Java code in your JSPs (e.g. if x.y == then "", else x.y, I guess that's the most common). You may implement methods within the presentation objects, that return values only valid for your web presentation layer, without "polluting" your business objects. So in fact these objects act as an adapter for the presentation layer.

Regards,
    Dirk

I haven't seen this presentation, but it looks like a pretty fair assessment of the different frameworks. Some things are a little nitpicky, like JSF's validation messages.

Also, while it's true that JSF tools generally cost money, they vary quite a bit -- MyEclipse (whic is really cheap) has basic support, you can get Exadel's JSF Studio, or you can use full-fledged IDE support in WSAD, Java Studio Creator, JBuilder 2005, and (soon) JDeveloper. I don't think it's necessarily true that these IDEs require a tie-in to a particular application server. They may integrate _better_ with a particular app server, but usually they'll work with different ones, and the JSF applications they create aren't tied to a particular server.

Kito D. Mann
Author, JSF in Action
http://www.JSFCentral.com - JSF FAQ, news, and info

The comparison is superficial at all points discussed.

For example, if the entire focus is the Web, it makes sense to mention that Spring has the most sophisticated web controllers; for example, wizard form controller and multiaction controllers. Plus it provides outstanding support for a number of view technologies: Velocity, XSLT, Tiles, Tapestry (when used as such).

I don't understand the slide about Success Messages: why would Spring require a custom solution for such a simple thing? - you simply specify your success screens in config files.

From all frameworks compared, Spring is the only one build for TDD, so it's much more than "allows easy testing with mocks".

From all frameworks compared, Spring is the only one build for TDD, so it's much more than "allows easy testing with mocks".

Have you looked at the other frameworks to make this claim? One of the key design goals of WebWork is to make it easy to test your Action classes. Mocks are no easier to use with Spring than any other properly designed framework (i.e. one which does not tie you to the Servlet spec like Struts does).

Jason, please accept my appologies, for not giving the due credit to the WebWork which you actively maintain. I used many web frameworks; and know that both Spring and xWork/WebWork are very flexible and easy to use frameworks, which are not limited to web applications only.

I just wanted to point out that Spring (and perhaps WebWork) not only offers a good environment for testing web controllers, but also welcomes the entire TDD approach by being one of the best Dependency Injection containers.

Regards,
Valeri

Tapestry
• Cons:
• Impossible to test - page classes are abstract

To me it seems as much sense as to write unit tests for, say, ...Bean class in Stateless Session bean. Strange, not to say more.

In my view, the whole app should be tested as 'blackbox' with HttpUnit or something alike.

I've created a tool for Tapestry 3.0 that will "fill in" missing methods (methods that look like property accessors), allowing abstract classes to be instantiated. Same runtime bytecode enhancement used elsewhere in Tapestry and HiveMind. An improved version is part of Tapestry 3.1 (still in early alpha).

Older Tapestry code violates Law of Demeter fairly consistently, which can make it hard to mock. I ran into this at a client, when I was trying to mock up a call to BaseComponent.getMessages() that ended up involving six or more mocks.

Tapestry 3.1 will simplify this greatly (most components will just have whatever they need injected in).

What's interesting to me is that TDD teams (such as Ken Auer's RoleModel software) don't have an issue with this ... the code inside a listener method is rarely interesting to anyone short of a TDD zealot and they have all thier business logic inside a seperate framework.

So a proper listener method gathers together information and pushes it into a seperate, testable, logic container and then has, perhaps, some tiny amount of logic to control what gets displayed next (or maybe not, if it passes the IReqeustCycle into the business logic layer).

Not perfect but quite reasonable.

Yes, your point is very true about TDD. If there's a lot of business logic inside the listener, it's time to refactor to an external (testable) main class.

It doesn't make sense to hold this kind of argument. Each framework has its advantage and disadvantage and no one is perfect.
Just forget the stupid effort on so many frameworks in java community today. People here enjoy technology games, and never consider cost and risk of a project when using a new framework.If you really want to do something useful, please
consider how to make a perfect office on linux.

It doesn't make sense to hold this kind of argument. Each framework has its advantage and disadvantage and no one is perfect.

Exactly because each framework has its advantage, it does make sense to compare them. Each time a new framework arrives, I hope that this one will be the one. Did not happen yet, but looking at Spring, it may happen that it will become a Mega-framework and will embrace all others. Until something like this happens, I will continue to stay with Struts ;)

You are speaking like a Visual Basic programmer and I beleave you are not. :)

Check out Tapestry Palette, built on top of Spindle with lots of help from Geoff Longman (Spindle Developer). You can browse all of the Tapestry components in your application, including framework components, inspect component parameters, access the online component reference and, on Linux and Windows drag and drop components into your HTML templates. It's early days yet but I'm specifically trying to target the Tapestry learning curve and flatten it out.

Sorry, this has to be a stupid question, but I guess it has to be asked :)

Anyways: can anybody point me to a web address of that framework called "wicked"? I am not able to find anything, googling doesnt give me a clue.

thx & forgive me

http://wicket.sourceforge.net/

I'm pretty sure you are looking for "Wicket" not "Wicked":

http://wicket.sourceforge.net

-geoff

now that was, ehm, wicked :).

thx

If is "wicked" I bet it is from Boston. :)

Oh the horor! :|

I believe that the lack of jsp taglibs in the spring framework is a plus. There are plenty of good presentation tags and libraries out there. Spring developers should not waste their time on writing new set of taglibs. There time as been wisely used integrating to the existing presentation resources out there.

Matt,

Great job in putting this together. There are a couple of corrections that I wanted to point out for WebWork:

1. WebWork actions only need implement Action, not extend ActionSupport. ActionSupport is a base implementation provided for convenience.

2. WebWork has a standard mechanism to deal with the duplicate post problem. Add the token interceptor to the action which gives you control over how you want to handle the duplicate post.

Eventually you'll all be using JPublish, so why don't you just give in now. ;-)

As someone who has been using Perl (ModPerl/MASON) and PHP for some years, I have to say I love Rife.
I cannot ofcourse say anything about the other contestants, but Rife makes building apps in a clean manner very easy. It forces you to work structural, its template system makes sure you seperate logic from presentation but it does that without making you feel crippled.
It has support for Java, but also for Groovy, it supports quite alot of databases with its Generic Query Language, and it has already brought forth two great apps, which I use or intend to use on the site i build with Rife, www.caosity.org. Check out Drone on it under the support/irc/logging section, and check out bamboo on http://rifers.org/bamboodemo.

Does anyone know which of the mentioned frameworks does not present any hurdles for clustering? My favorite framework is Webwork due to its excellent testability, but I had problems serializing my HttpSessions under Tomcat due to the object graph Webwork places in it.

RIFE's core features make any web application clusterable thanks to the simple fact that it stores no state on the server side, and handles everything through it's data flow definition (which complements the logic flow - http://rifers.org/docs/usersguide/ch03.html#sect1_numberguess_data). Since no state is stored on the server, you can just set up a collection of servers that are used with for example a round-robin DNS configuration.
However, when you use features like web continuations (http://rifers.org/wiki/display/RIFE/Web+continuations) or explicitly configure RIFE to store the state in the session (http://rifers.org/wiki/display/RIFE/Acceptable+session+support and http://rifers.org/wiki/display/RIFE/Configurable+state+storage) instead of on the client, this doesn't work anymore. You can easily get by without these features though, and of these two, only continuations can significantly make your life easier for certain flow situations ... it's just a luxury though.

First of all, I'm happy that Matt stopped crying and weeping about JSF because he could'nt understand it.
I still don't understand why struts is considered to be the "standard". The documentation sucks, the updates are rare and the design is a real pain. With all the good choices we have, we are no longer doomed to consider struts as the standard and use it.
My next impressions are about Spring since I'm using it on a big project (on my previous projects I used to use struts). What Matt considers a lack ; the jsp tags, is IMHO one of the best parts of Spring MVC. Spring MVC has a limited set of very powerful and generic tags whereas with struts you have to learn a lot of them. In "big" applications like the one I'm working on, you have a graphic designer who desgins the web pages with pure html. With struts, you have to modify them, to replace the input tags with struts tags which can become a pain to maintain. With Spring MCV you just add your tags around the input tags without modifing the html whic is a lot easier. By the way, the Spring forum is one of the best around and I ALWAYS got answers to my questions by the large and nice community.

What is wrong with this community?

Cocoon is way over the top compared to these Mickey Mouse Web frameworks, what a sad reality, so many lost souls.

Oops, sorry, excuse me, just get back to your Eclipse and don't forget to take your red pill.

Looks like its time for yet another J2EE vs .NET Web frameworks talk show...

Struts more so than most others. Tapestry I think is much better. Barcutta sounds like some mean canine breed and Wicket... hmmm lets not get sticky! Cocoon is a framework for masochists! Seriously, its nasty. It is NOT a web framework. Cocoon is great for transforming XML (a la freebie biztalk).

The real competition is from Microsoft. What MS could do in 2 years, Java hasn't been able to do in 6! and that is very sad. Look at the component market for asp.net - look at componentsource.com, infragistics.com, componentone.com - these are extremely sophisticated components that transform web app development into a breeze. Struts can never match up to an app built using these.

Java needs to seriously develop a rival to asp.net and I don't think jsf will cut it. The biggest problem is the uncontrolled proliferation of open-source web frameworks. It has completely fragmented the market. Choice is good - asp.net gives you a choice of component to use. Java gives you a choice that requires a much higher investment and learning curve. That is the failing of the java web framework endeavor.

I don't want to rain on the argument, but that argument would only make sense if there is such a thing as "one framework for everyone." Obviously, everyone is different. Even with ASP.Net, developers are different. the more I work in this industry, it becomes more apparent just how different people/developers are.

What comes naturally to one person often feel backwards to someone else. Just as bruce lee put it, "there is no one style. there is your style." You have to figure out what your style is. what works for someone else is most likely not going to be the style for you. Some web frameworks are easier for new developers to pick up, but they all eventually falls short of the user's needs.

depending on what i'm working on, I may use JSTL, ASPX, ASMX or JSP. Say you want to build a server administration tool in .NET to deploy/suspend/resume/undeploy any web application across a cluster. Would ASPX or ASMX be appropriate? Or would it make more sense to go to a lower level and hook into system API?

"Struts more so than most others. Tapestry I think is much better. Barcutta sounds like some mean canine breed and Wicket... hmmm lets not get sticky! Cocoon is a framework for masochists! Seriously, its nasty. It is NOT a web framework. Cocoon is great for transforming XML (a la freebie biztalk)."

You say Struts is good and Cocoon is for masochist. I rest my case; I just have to find a jury that doesn't use Eclipse.

Look, Struts is for dummies (mass majority) and Cocoon is for, well you wouldn't understand.

Do you know, I use Cocoon for a lot of things that don't use XML, really, please everyone it's not bad to say "I don't know".

Although, I "do" know for a fact, Struts is for dummies :)

Unfortunately, any pro- or contra- frameworks position does not answer to Karl’s question: where are Java components?

Dmitry
http://www.servletsuite.com

I totally agree with you!! However, the comparision lacks some not so popular component based framework .. one of them you will propbably hear of soon on this channel ;-)

I do not agree with this comparisons, I believe that other application frameworks such as WebOnSwing have advantages over these 5 frameworks.
I think that these comparisons could be done by developing a petstore demo or something similar (such as wafer.sf.net), and then we will able to evaluate the following frameworks features: friendly, versatile, reusable, abstract, object oriented, easy, learning curves, speed, configuration, etc.

If you are a real technical guy, you will love webwork because it does the exactly what you expect it to do in the easiest way.

If you are a manager, you will love Struts because it is from Apache, popular, got books, etc.

I have successfully done 2 commercial projects using webwork. It impressed me a lot by its features and it simply works.

Frankly speaking, webwork still need to improve their documentation. It took me quite some time to setup the development environment with Spring and Hibernate.

Nice comparison, thanks!

Anyway, IMO, we need to go further. Comparison of web presentation frameworks (Struts, Barracuda, EAF, ...) and techniques (JSP, XMLC, Velocity, ...) is always nice but it will be more useful if we can integrate all of them.

We need to go one abstraction layer higher. Use UML and MDA to define the web presentation layer and generate the best Java code for this purpose. Use the same "language" to define the presentation layer, so we can generate different frameworks and techniques from one - yes one and only one - source model.

In AndroMDA project you'll see this happen. At the moment there is BPM4Struts, WebWork and EAF + XMLC cartridge, so you can define a model and generate the Java skeletons (and sometimes more, like in BPM4Struts) of those frameworks.

I myself - like some threads said - use XMLC and love it. I don't use Barracuda but only EAF (Enhydra Application Framework) as my web framework. I generate almost everything from one UML model which makes it very easy to use:

1. Create your use case for your application.
2. Create your class diagram for your pages.
3. Create your activity diagram to have your flow.
4. Compile your model.
5. Extend the generated source codes to fullfil your needs.

With this style - for the first time in my experience - I can save a lot of work writing those helper classes, wiring them together, etc. And also you can easily use inheritance to extend your need (with a help of IDE like Eclipse it is very nice and easy to do this). Therefore MDA (Model Driven Architecture) + SCD (Sourcecode Centric Development).

The same is also happening in the "business" layer. You can choose your cartridge (EJB, EJB with Hibernate, ...) and generate from one model different kind of implementations. So, no need to fight, what the best persistance mechanism (Hibernate, CMP, JDO, ...). Use the best tool for your purpose.

IMO, this will be the future of application development just help us to create new cartridges, so we all can easily use them with the same way!

Next step to go: every specification in Java (JSF, EJB, ...all other JSRs) should be delivered with an AndroMDA cartridge, so:

Each JSR will have to deliver:

1. Specification API.
2. Test Compatibility Kit (TCK).
3. Reference Implementation.
4. And the Cartridge to be used with UML, so we can generate everything we need!

This will make integration and update to a new technology, technique a lot more easier!

Cheers,
Lofi.
EJOSA: Enterprise Java Open Source Architecture
Documentation EJOSA 2.1: http://prdownloads.sourceforge.net/ejosa/ejosa-revo2.1-doc.pdf?download

In AndroMDA project you'll see this happen.

I never saw it happen. The features of AndrMDA are appealing,but, whenever i tried to do reverse engineering of a code base with 100+ classes,it just hangs in the second phase of parsing. Why , second phase of parsing?.i don't know.but i noticed that more than once. Maybe, AndoMDA's cousin which is a commercial product,fares better..maybe..

Regards
Surajeet

<quote>
I never saw it happen. The features of AndrMDA are appealing,but, whenever i tried to do reverse engineering of a code base with 100+ classes,it just hangs in the second phase of parsing.
</quote>

What do you mean by reverse engineering in this topic? AndroMDA does not support reverse engineering :-) You need to do the reverse engineering by yourself...

<quote>
Why , second phase of parsing?.i don't know.but i noticed that more than once. Maybe, AndoMDA's cousin which is a commercial product,fares better..maybe..
</quote>

What is the second phase of parsing? And what's AndroMDA's cousin product? I never heard of it... Maybe we talk about different products? :-)

Cheers,
Lofi.

Maybe we talk about different products? :-)Cheers,Lofi.

ooopss.sorry..total confusion. I had ArgoUML and its commercial cousin Poseidon , in my mind,when i said that.

Thanks for the jitter. For quite sometime i was under this wrong assumption of referring ArgoUML as AndroMDA.. maybe too many tools for my head to accomodate :)

Regards
Surajeet

<quote>
Thanks for the jitter. For quite sometime i was under this wrong assumption of referring ArgoUML as AndroMDA.. maybe too many tools for my head to accomodate :)
</quote>

yeah, nowadays it is quite tough to remember all those wyrd acronyms ... MDA, AndroMDA, UML, ArgoUML, PoseidonUML, SOA, EJB, JSP, JSR, XMLC, JSF, JSR, MTL, EMF, MDR, GMT, VE, XMI, JMI, BMP, BPM, ... ;-)

Cheers,
Lofi.

Boy, as a refugee from a long time spent in the 'architecture' BDUF wars, I hope we don't adopt this approach. TDD is not the total answer (see Scott Amblers reasoned papers on this subject), but it get you a heck of a lot more useable design, if you do a little up-front design to start, as Ambler suggests. FDD, anyone?

From the presentation:

"JSF uses POST for everything"

Is it really true? If it's true, then it's definitely not an option IMHO. If a web framework forces me to have a web app that does not respect the web standards, then it's not an acceptable framework. Plain and simple. I want to be able to bookmark a page, to send a URL via e-mail, and to easily test my web-app with HttpUnit.
I also want to be able to use my web-apps with multiple frames or tabs, BTW, and I don't like frameworks which make it impossible dur to their insane use of the session.

JB.

Matt Raible has a new presentation in which he compares a sprinkling of web frameworks. He discusses the technical, and political merits of Struts, Spring, Tapestry, WebWork, and JavaServer Faces. Do you agree with his conclusions?Matt Raible presents Comparing Web Frameworks

The title of the article itself misused here. It should be "Comparing Web Frameworks for J2EE". If the author want to stick with the title "Comparing Web Frameworks", he must be a guy who's totally against M$. Otherwise, he might've compared ASP.NET in his article / presentation.

Also, guy's who are in the J2EE field, just because of you hate M$, dont tell that ASP.NET is nothing. Afterall, 80% of these J2EE based development is going on in Windows platform, which is again a M$ product. If anyone disagree, no one will digest that also.

Let the author, re-write his article / presentation, and post it. I hope he can't do that, why because, there is no other framework available now, in comparable with ASP.NET, with this much of simplicity.

What you guys need. All the API's of ASP.NET and its sourcecode. What you're going to do with that. Write code for hacking it ? Whatever is available as OpenSource for J2EE, developed in the last 6-8 years, its 50% available for .NET environment within 2 years, apart from what M$ has given as ASP.NET Controls. So, just like that dont comment on something, which you dont know.

I'm slightly stunned that no one but Geert and Maarten discussed the advantages of RIFE. I've been using RIFE for more than a year now on everything that I write.

It's really done the trick to free me from having to think about my framework. You don't have to think about how to do anything, but it's so easily done. 5-10 minutes and you could honestly have the basics of the framework down. Easy like Sunday morning.

Really that takes care of about 75% of all the stuff you write. Simple. But for when you need something a little more powerful, you've got things like continuations that make you wonder what you did without them.

I think the thing that strikes me as one of the most useful things is the templating system. It's a dumb templating system, but that's the beauty of it. The template is directly controlled by Java (or Groovy/Python/et. al.) code in an Element. Not by Velocity code or JSP or PHP or whatever. So it's maintainable. No code in the templates, as it should be. The separation holds.

RIFE just makes sense. So if nothing else, give it a try, you might just find you like it. ;)

I think that the result from the comparison made by Matt is a bit biased , it seems that struts wins every battle hands up , but one factor should be taken under consideration when reading this article is that Matt has over 3 years experience in Struts and only started with JSP or Spring this year.

So its kind of obvious that he will find struts more easy to work with ;).

cheers,
    Javed

With so many choices for Web Frameworks out there developers
really need form their own opinion about each one. Get out there and try as many as you can and form you own opinion.

I personally have been using ATG Dynamos web framework (ie droplets, form handles, nucleus beans etc...) for a number of years now and find it to be quite adaquete at anything I've needed to throw at it. I've examined Struts and JSF and both seem reasonable. But I haven't have any compelling reason to switch.

I have enjoyed struts when I started for giving the framework it offered to implement an MVC framework.
I have also played with JSF and I am considering using it for complex user interaction controls. I do find it a bit complicated and the error messages are really bad for the release I tried.
Spring gets my vote for multiple reasons:
- it does everything Struts does
- it gives you a framework for the entire scope of the project, up to persistence where as Struts stops way before that.
- VERY nice feature is that I can use my existing model as the model for the web page. I have contact -> addresses and I am able to maintain all that with the existing model in one web page very easily. With Struts you need to create action form classes for all the models and you can only use String as data types.
- it allows to have declarative transactions with only a Servlet container
- it does also integrate with other frameworks (ie JSF)
- The IoC is great, but I suppose you could use Spring with Struts anyway to implement the rest of the business logic. Spring remains a nice framework to look at for Struts afficionados.

It is true it does not have a very extensive tag library. I have created one input tag class in the meantime and I am able to use that. I believe a tag library is in development.

Yann

I want to encourage the readers to visit http://spago.eng.it
Spago is a horizontal framework for the development of web and multichannel applications in enterprise environments, and it is the result of more than 4 years of expertise of two companies in the development of applications based on Java in heterogeneous, complex and always changing software environments.
Spago is an Enterprise Wide Framework because it is a platform that allows communication among different internal and external corporate processes.
Other previous releases before Spago have been available on the market since 2000, and today we can count approximately 30 application projects for the the public administration, finance and large corporate groups already using some previous release of Spago.
The project, based on a Java platform and released as an Open Source Software, is held in the best worldwide repository for this type of initiatives at: http://sourceforge.net/projects/spago/. Here you can too download some examples and italian version of doumentation (Overview, User Guide, Tutorial). The english version of the Spago doucmentation will be released by the end of the year.