BT

Reasons to choose Wicket over JSF and Spring MVC

by Rob Thornton on Dec 19, 2006 |

A recent post to the Wicket mailing list details some reasons to choose Wicket over Spring MVC or JSF. Wicket is a component based web application framework.

Ryan, who has a background with a variety of web application frameworks including Struts, Spring MVC and Tapestry, was evaluating frameworks for large projects that will have a long lifetime. In doing his research of the many frameworks, he narrowed his list down to JSF (MyFaces), Spring MVC, and Wicket. He felt that these three represented the best of breed tools. He quickly ruled out JSF:

I liked its form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it.

He is a big proponent of Spring and Spring MVC, but the biggest drawback for him ws the fact that it is bare bones:

It really is just a MVC framework. If you want infrastructure for ajax, redirect after post, poups, and other common webisms you will need to build them yourself with Spring MVC.

He goes on to list the pros and cons of Wicket. The pros:

  • All configuration is done in Java.
  • Well thought out support for common webisms (Ajax, redirect after post, etc)
  • Strong community witha ctive core members
  • Powerful model abstraction

And the cons:

  • Con: Session support
  • Con: Documentation

The thread goes on to talk about some of the changes to the session support in Wicket 1.3, where visited pages are saved to disk rather than being held in the session, thus shrinking the session size significantly.

InfoQ covered the Wicket 1.2 release back in May.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Spring by Jonathan Locke

The casual reader should know that although Wicket is an unmanaged framework (you create components with the Java new operator) we on the Wicket project like Spring and provide integration for Spring bean injection. There's even a project called Qwicket if you want to get a quick start on a spring+hibernate+wicket application.

JSF by Michael Yuan

I think the most important "feature" of a component-based framework is how many components are available. JSF really excels in this area with a large ecosystem of commercial and open source vendors.

The shortcoimg of JSF is that, out of the box, it does not support "webisms" very well. But, that is why Seam is so compelling.

cheers
Michael
Book on JBoss Seam

Re: JSF by Keith Donald

Spring Web Flow integrates with Spring MVC to provide many of these "webisms" out-of-the-box including automatic redirect after post, flash scope support, full browser navigation button support (back, forward, refresh, new window). It ships a sample application demonstrating Ajax integration with prototype. SWF also provides a higher-level of abstraction for defining controller components in an externalized definition language--these components then become modules reusable across Servlet, Portlet, and other environments without change.

For more information about what Web Flow can do see:
www.springframework.org/webflow

Perhaps we should call Spring MVC and Web Flow combined "Spring Web". It is worth noting, though, our users do experience value in having flexible components upon which they (and we) can build upon and extend. For example, Spring MVC's dispatcher servlet is re-used by Spring's remoting and web-services support. That's just one example...

In summary a development team evaluating Spring's web app development stack should consider Spring MVC + Web Flow + DWR together, and not simply the Spring MVC base in isolation.

Cheers,

Keith
Lead, Spring Web Flow

Tapestry by David Skelly

It's interesting to me that he says that he has spent the past two years working with Tapestry, yet he doesn't say why he ruled Tapestry out of his list. He presumably has some experience of using Tapestry in the real world on real projects which leads him to think that Spring, JSF and Wicket would all be better choices going forward. I'd be interested to know what those reasons were, since he's coming at this with hands-on experience to back him up.

I like JSF but I hate the mark-up. Facelets is a must-have for me with JSF because then I can use proper tools to design the web page, and non-techies can look at the page source and understand what it is doing.

stripes by graham o'regan

I've also looked at a lot of the options out there, but I'm leaning more towards stripes. Some of it's principles fly in the face of popular opinion, but its hard to deny how productive it can be. I'm not sure if it would be as maintainable in the longer term tho.

Try the RI by Jason Lee

I liked its form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it.

I can't really speak for MyFaces, but with the RI (1.2), the only time Javascript is used if you use h:commandLink. Otherwise, the page is JS free. The extra markup I can only assume means (client-side) state-saving code, but, since I don't use MyFaces, I can't say for sure. If you use server-side state saving, even that can be minimized. Personally, I think the "extra markup" argument is a bit specious, but to each his own. :)

jason lee
JSF RI Dev Team

Tool support and documentation by Marc Tremblay

The tool support for JSF shouldn't be discounted either. Once you're outside JSF there pretty much isn't any.

Likewise for documentation. JSF is well documented. Most other frameworks are not in my experience.

Wicket is cleaner than Tapestry, yet flawed in that by Matthew Payne

css attributes are done in java code. There is nothing wrong with simple if condition in a template for altering row colors.
Keep the css and view code out of my java.

After dealing with Tapestry on the last two projects I have come to the conclusion component frameworks are overrated.
Whole views/templates/and actions are components in my mind, and tapestry like frameworks have much less re-uses since there is a 1:1 relation between an action and a template.
Thats BS, a action should be return multiple views and template could be reused used with multiple actions as well.
If you want to look at what is wrong with tapestry just look at the roadmap for tapesty 5. They list everything that is broken and restarted about the framework. (terrible spring integration, wonky abstract classes, no interceptors, uses heavy inheritance model over light interfaces, frequent app sever restarts).

Webwork/Struts 2.0 is where it is at.
Stripes is nothing more than webwork lite, with much less flexiblity.

Components configured in Java by Frank Silbermann

What I like about Wicket (and Echo2 and GWK) is that not only are the pages configured in Java, but so is every individual component and nesting of components. That means I can subclass anything -- pages, panels, widgets -- and I can provide any constructors, overridaeble methods, and defaults for the subclasses as I please. This greatly increases the possibilities for re-use. The advantage over other web frameworks is analogous to the advantages that languages such as C++, Java and Smalltalk have over C, Pascal, and Basic.

Of course, people won't appreciate this difference or benefit from it unless they understand how to design class hierarchies.

Re: Wicket is cleaner than Tapestry, yet flawed in that by Jonathan Locke

"There is nothing wrong with simple if condition in a template for altering row colors."

I think it's a slippery slope. If you add this if condition, you have to add variables for the if statements to work on. Which means model OGNL or something like it in the markup. If you add that, then why can't you do OGNL interpolations? If you add that, then why can't you do OGNL method calls? If you add that, then why can't you do other constructs in the markup? What about a loop construct? It just never ends. And when you're all done you have dynamic behavior embedded in the markup and you never know for sure which file has the if statement in it. In Wicket, you always know that. This has its benefits.

I do understand where you're coming from. I just disagree with your conclusion. By keeping ALL code out of your markup, Wicket is clean and compatible with even the simplest design tools. And that aspect of it will never need to change. The markup in Wicket concerns the look of the view. The Java part in Wicket concerns behavior. If you're dynamically changing a css attribute, that is dynamic behavior in Wicket which means it is predictable in location and form and susceptible to OO techniques and IDE assistance. Behavior is not and should not be markup. Or at least that's the dividing line I came up with when I started Wicket a couple years ago.

In practice I have not found dynamic attributes to be a problem with Wicket. Any CSS or attribute modification I do usually winds up encapsulated in OO code such as a custom component (which you can create by simply using the "extends" keyword... imagine that!) and I never need to look at it again. But if I do need to look at it, I know where it is a priori.

Re: Wicket is cleaner than Tapestry, yet flawed in that by Jonathan Locke

"Whole views/templates/and actions are components in my mind, and tapestry like frameworks have much less re-uses since there is a 1:1 relation between an action and a template."

It could be the OO coder in me talking, but I've read it several times and I still don't understand this statement at all.

Re: Wicket is cleaner than Tapestry, yet flawed in that by Jonathan Locke

"Whole views/templates/and actions are components in my mind, and tapestry like frameworks have much less re-uses since there is a 1:1 relation between an action and a template."

It could be the OO coder in me, but I don't understand this viewpoint.

Re: Wicket is cleaner than Tapestry, yet flawed in that by Jonathan Locke

Whee, so much for the AJAX cancel button on InfoQ. ;-)

JSF and Webisms by Rick Hightower

Many of the issues that Wicket solves core JSF does not. However there are frameworks like Seam, Shale, etc. that solve these problems (common webisms).

JSF is the core specifications. There are plenty of add-ons that solve these issues. Some of the "add-ons" will get added to the core. Some will not.

Wicket and Tapestry sounds like more complete out-of-the-box solutions for component-oriented web development where with JSF you need to combine it with other frameworks to get a complete solution.

The core JSF is well documented. Shale and Seam are less so. (Shale docs have improved. Seam docs seems pretty good).

With JSF the solutions are there, but it is not one stop shopping.

Re: JSF and Webisms by Matej Knopp

Is that so? I've seen couple of demos of JSF frameworks that claim to bring Ajax support to JSF but I can't say I liked very much what I saw.

Take webgalileo for example. Looking at the demo (support.jscape.com/webgalileofaces/)
I've got mixed feelings. Well, not exactly mixed. More like negative.

The site took quite long to load. Why? Well, for beginning, there is 200kb of javascript being loaded. Some of the files seem to be compressed, so in the end, browser needs to process 700kb of javascript.

And that's not all. The left tree - it's a completely different file in an iframe - it's 145kb of generated javascript. For a simple tree. In an IFRAME! What's the reason for iframes in component oriented frameworks anaway?

Now the question is, why am I bashing Webgalileo. I took that one just as an example. I have this feeling with other frameworks built on JSF too. A know a huge hack one I see one. A hack to get somehow things working together.

Would you build your application on something like that? I mean, in the end, can the application be any better than the framework it's built on?

Re: JSF and Webisms by Rick Hightower

I've never uses WebGalileo, but don't think it is indicative of the JSF framework per se.

My point was that there are several solutions to these common webism and it is a shame they are not handled by the core JSF spec. Hopefully, they will be added to the core of JSF.

Wicket has been out for a while. How popular is it? As popular as Tapestry? Spring MVC? JSF?

If not, what are the chances that it will become mainstream.

I took a look at it and did not like the programming model, but then again my mind has been tainted by Tapestry, JSF, Facelets, etc. Perhaps, I'll give it another look one day....

Re: JSF and Webisms by Dorel Vaida


I took a look at it and did not like the programming model, but then again my mind has been tainted by Tapestry, JSF, Facelets, etc. Perhaps, I'll give it another look one day....


Well, it's full of ugly inner classes, components, the framework clases are full of things that you cannot override (read final) etc. I didn't like that either and still don't in some cases. Still ... something tells me that's all about OOP and not Wicket, isn't it ? :-).

I love Wicket. Wicket has an excellent, clean 'pure java' design. And you get bonuses for that, no doubt. For example, let's take clustering. Arguably it's been a weak point (constantly improved over time, from the last I've read it's MUCH better now) since it's inception because Wicket was making 'heavy use' of the HTTP session and most of the time that impedes scalability through HTTP session clustering. But guess what. Some terracotta guys open sourced their JVM clustering solution and it seems that, by design, Wicket fits perfectly into that vision. HUGE bonus.

Congrats to the Wicket folks, great job they did, I've been allways sorry that due to the lack of time I wasn't able to actively participate to the mailing list (some brilliant guys there, really), but at least I read it :-( .

This thread is a microcosm of the ongoing Java framework battle ;) by Ivan L

It's amazing how many key people just popped up in it.
As a user, I want you all to know I'm investigating all your technologies and should be productive in no time flat in early 2008 ;)

Re: This thread is a microcosm of the ongoing Java framework battle ;) by Rick Hightower

The battle has been fought and won. These guys are just trapped on an island somehwere and didn't get the news....

Battle news: JSF wins so far

I'll keep my eye on Wicket, but it is not too exciting at this point (for me).

Re: This thread is a microcosm of the ongoing Java framework battle ;) by david m

Struts is EOL by Rick Hightower

Classic Struts won a long time ago. This is old news. It is officially dead now.

The next question is... who will succeed classic Struts.

Struts was replaced with WebWork so classic Struts is EOL (end of life). Struts2 is based on WebWork not classic Struts.

Out of the possible replacements for classic Struts, JSF is the leader.

The possible replacements are Struts2 (WebWork), WebWork (or is this EOL now that Struts 2 is out), Spring MVC, Tapestry, Wicket, JSF, Rife, etc.

Out of those, JSF is clearly in the lead.

On a side note: I feel pretty comfortable with Tapestry, Spring MVC, classic Struts and JSF (I've used them in anger).

After using Tapestry, Spring MVC and JSF, I can't go back to classic Struts. Struts 2 looks pretty good. I saw Matt Raible's talk on AppFuse. He said some pretty intriguing things about Struts 2. It piqued my interest.

When I looked at Wicket, nothing piqued my interests. I have not seen a convincing argument for it (yet).

Re: JSF and Webisms by Rick Hightower

Can you please clarify... Please replace "it" with the framework you are talking about. You bounce back and forth, it is hard to follow your logic.

Re: This thread is a microcosm of the ongoing Java framework battle ;) by Rick Hightower

Just a note....

After reading the posting on InfoQ and this article, I've put Wicket back on my radar as things I want to look into "when I get enough time".

There are so many frameworks and so many good ideas out there it is hard to keep track of them all.

I wrote a series on JSF and Facelets on IBM developerWorks. I've ported thes examples to Tapestry. Perhaps for my own edification I will port them to Wicket (one day).

Re: Struts is EOL by Geert Bevin

Now that Rick mentioned RIFE, I can officially jump in without sounding like a zealot ;-)

I've always found these 'job statistic graphs' totally useless. Of course the established standard and enterprise-targeted solution will come out as the one that the most developers are being hired for. Small to medium companies rarely have the budged to start hiring consultants in a such a fashion.

Alternative frameworks often target another (alternative) audience. A lot of RIFE users are part of 'the long tail' of small companies that simply want to get faster results, less setup, more reuse and reduced maintenance efforts. Choosing a suitable alternative framework is one the easiest initial approaches to be able to compete against bigger firms.

It is thus useless to try to 'deduct who won the battle' from any kind of statistic like this. However, I think it's even more useless to see alternative solutions as being in a battle to grasp the most developers. All the choices that have been mentioned here have clear advantages and their goals and purpose are clearly defined. It all just depends on the task at hand, the preferences of the developers, the paradigm they feel comfortable with, etc etc

I think however that it's healthy to post constructive criticisms about why you prefer one solution over the other, like Ryan did in his original mailing list post. This helps other developers to discover differences and problem areas that they are now already aware of before selecting one technology or the other.

Re: Struts is EOL by david m

People choose one solution over the other because it's practical - a Struts programmer is going to have the most choice, when it comes to new gigs, for example. Even today.

I checked out Rife and thought it was excellent, and found the community very helpful and pleasant, but ultimately ended up settling on more boring tech because it's easier to find devs, most of the questions have already been answered, and it is well integrated in usual environments.

Granted there are sometimes fundamental problems with 'standard' techs where they need to be revamped or usurped, but I don't know how anyone can ignore stats like this (well, maybe for you superstars its easier). There will always be "cooler tech," but in trying to fulfill my client goals and not make myself crazy, I'm most interested in the cool end product. The cool project I'm working with now is still using Struts 1.3.

The abundance of choice is really maddening in the Java world, which does call out for JSF dominating eventually, as a 'standard,' endorsed solution. Just like J2EE. :) j/k. Java seems to have as many stacks as all other languages combined (OK, not including PHP, with ten more arriving each cola fueled evening). What would be nice, to make this work, is finding a cohesive way to combine arbitrary stack components at different points (persistence, component management, view), as required.

Re: JSF and Webisms by Matej Knopp

Can you please clarify... Please replace "it" with the framework you are talking about. You bounce back and forth, it is hard to follow your logic.


I think it's quite obvious that it = Wicket :)

Re: This thread is a microcosm of the ongoing Java framework battle ;) by Matej Knopp

Well, i think this is a bit unfair. None of the "small" frameworks has a big company behind it, unlike JSF. With the marketing power Sun has this is hardly a surprise.

The goal of Wicket never was to rule the world. Believe me, there are people using Wicket (after all, so far we have had almost 100000 downloads from SF). I know a lot of people frustrated from either JSF or Tapestry that are happy Wicket users.

You like JSF. You are happy with it. Good for you. Lot of people are not. I think it is the programming model that makes the difference. And that is hard to explain. You simple have to try using it, and then you'll find out whether you like it and gets more productive with it, or not. This is not something a feature matrix or eye-candy demo will do.

I know people who were using JSF or Tapestry and switched to Wicket. On the other side, I don't know anyone who was using Wicket and switch to JSF or Tapestry (Which of course doesn't mean that such people don't exist :)

Anyway, you might want to look at jroller.com/page/JonathanLocke?entry=wicket_pla... and read the comment from Closet Wicket Lover :)

Re: JSF and Webisms by Rick Hightower

Now I am more confused....

So it refers to Wicket....

So you say:

"Well, *it*'s full of ugly inner classes, components, the framework clases are full of things that you cannot override (read final) etc. I didn't like that either and still don't in some cases. Still ... something tells me that's all about OOP and not Wicket, isn't it ? :-)*

And then you say:

I love Wicket.

Please clarify.

Re: Struts is EOL by Rick Hightower

Geert,

I agree with everything you say to a degree. Rife is cool, inovative and has a good niche. I hope I get to work with it some day. (Most likely I'll continue to work with JSF, Spring and Hibernate.)

The graphs matter to some. I am one of them. It is not the only thing that matters.

Rick Hightower

Re: Struts is EOL by Rick Hightower

I agree 100%. It is hard to get non-de facto standards (or standards) at big companies.

And, I think JSF is the next "Struts" for better or worse.

This does not negate the value of Wicket, Tapestry, Rife, etc. This does not mean that Wicket won't have a large following. Certainly, 100,000 is a large number (I am one of the 100,000 who downloaded it).

Re: JSF and Webisms by Matej Knopp

I believe the first paragraph is half-ironic. Is what most of the people see when they look at Wicket for the first time. Lot of inner classes, final keywords... Some developers, especially developers not very familiar with OOP, can find it weird and foreign, because it's completely different then for example the procedural nature of struts.

But in the end, it's just the plain old object oriented programming :)

Re: Struts is EOL by Geert Bevin

The graphs matter to some. I am one of them. It is not the only thing that matters.


If you're talking about job security as a consultant, I can see that. However, I can also see that being specialized in niche technology gives you much less competition for the same positions.

However, the graphs were shown above to 'prove' that one framework supposedly already has won 'the battle'. I stand by my previous comment that this is a useless metric for that matter as there simply is no 'one battle'.

Re: Struts is EOL by Rick Hightower

Geert,

You have touched on a few issues here. I mostly agree with you, but let me play devil's advocate a bit and highlight where I differ.


RE: If you're talking about job security as a consultant, I can see that.


To a certain extent this is true, but when the technology saturates (like classic Struts for example) it loses some of its consulting value. If everyone knows it, the bill rates go down. The golden thing about JSF is that there are so many niches built on top of JSF (Seam, Shale, Tomahawk, ADF, it is really endless).

I think the graph is actually more important to the classic architect who works at a fortune 500 company. His concerns are usually: Can I find people who can maintain this and add new features? Will I be able to hire people off the street who can use this technology? Is it a big project with 10, 20, 30 developers? Will I have to train them all to use this new framework. How big is the learning curve?


RE: However, I can also see that being specialized in niche technology gives you much less competition for the same positions.


I get a lot of calls to work on/with frameworks people don't use anymore or are trying to get off of. It is good to have a few niche skills if you are a consultant.

What is even better is if you can create your own framework! That is consultant gold. Ain't that right Geert? :o)


RE: However, the graphs were shown above to 'prove' that one framework supposedly already has won 'the battle'. I stand by my previous comment that this is a useless metric for that matter as there simply is no 'one battle'.


True, there are many battles. And, it is also true that not every framework fits every problem.. But the one battle I am talking about is specific. Which framework will be the next 800 lbs gorilla (the de facto standard)? Which framework will replace Struts as the de facto standard?

I did not say which framework is the best. And, I stand by my previous comments, JSF has won that single battle already. It seems like it is the most likely to be the next 800 lbs gorilla.

WAFFLE:
Although since there are so many options circa 2006... maybe JSF will never be as popular as Struts is. There is just so much choice (which is always a good thing). But, allow me to waffle from my point a bit.... Maybe there can never be another 800 lbs gorilla... maybe the most we get is a 150 lbs gorilla and a bunch of 10 lbs monkeys.

I am glad there is not one monolithic framework that we all must use. About the coolest thing I've seen framework wise is how Rife does continuations. If Rife did not exist.... that would suck....

I dig the Java community we live and work in. I've learned a ton by using Spring MVC and Tapestry.


peace
--Rick

Re: Struts is EOL by Rick Hightower

Before I get too much grief...

When I said this... "The golden thing about JSF is that there are so many niches built on top of JSF (Seam, Shale, Tomahawk, ADF, it is really endless)."

I was mostly kidding... an emoticon would have been nice....

Re: Struts is EOL by Geert Bevin

I get a lot of calls to work on/with frameworks people don't use anymore or are trying to get off of. It is good to have a few niche skills if you are a consultant.

What is even better is if you can create your own framework! That is consultant gold. Ain't that right Geert? :o)

Euhm, what RIFE,and more particular the continuations support, brought me was reputation. Besides a few trainings, I have never done much consulting work specifically for RIFE. However, for the development of solutions for customers as a software shop, I use it all the time. Getting a framework out as open-source and making it accessible for other developers is a lot of work and I'm pretty certain that the time invested in that hasn't paid itself back at all yet. Thankfully one of the benefits is that it's easier to find other developers for bigger projects, since I don't have to train everyone myself. Also, the quality of the framework has improved a lot thanks to public scrutiny. Mark Fleury said something very interesting in his keynote at Javapolis related to this, open-sourcing technology is only beneficial if you have a brand, doing it as an unknown small company is close to suicide. If you ever open-sourced a project of any considerable size, you know what I'm talking about. I was in the comfortable position of having all my customer projects being done with RIFE, so the development was actually partly funded by the solutions themselves.

Re: Struts is EOL by Rick Hightower


Getting a framework out as open-source and making it accessible for other developers is a lot</v> of work and I'm pretty certain that the time invested in that hasn't paid itself back at all yet.


I can only imagine. I was mostly giving you a hard time.

We wrote a framework for a client called Presto (built on top of Facelets, JSF, Spring and Hibernate with a small amount of codegen via Velocity and Maven 2). We were trying to get permission to Open Source it. It got nixed by legal. I don't think I had the bandwidth to do what you did with RIFE anyway. The documentation.... etc. The time it takes... Ouch!


It is quite an accomplishment. RIFE is very innovative so I am glad you spent the time to get it out there.

Re: Struts is EOL by david m

Just to expand on my own point, it would be nice to have a wiki style list of concerns that a typical and non typical app might have, and an index of technologies that address each concern, as well as a way of linking them all. That would consider all the diversity of the Java world, and prevent some confusion and re-inventing of the wheel. A click-able diagram with searchable keywords would be ideal.

It could include general concerns such as kits for persistence, users, domain logic, presentation, etc, all the way to 'esoteric' concerns for particular fields. Existing open source projects that use combined stacks could be used as showcases. This would show one of the real strengths of java, being able to mix 'n' match granular components.

Of course, this is probably a fantasy, as it would require a lot of long term commitment and cooperation. There was a project that tried to do something similar with blog implementations, but it gave up.

Re: Tapestry by Ryan Crumley

After using Tapestry 3 extensively (touching briefly on Tapestry 4) I have a few gripes which caused me to consider Wicket instead:


  • Request lifecycle - The Tapestry request lifecycle is very complex. Combine the lifecycle complexities with a complex component design (especially components that need to interact with other components) and it becomes very difficult to design, code, and understand how a specific component operates. This can lead to maintenance problems for teams where many people need to maintain the same code.

  • OGNL - Tapestry makes heavy use of OGNL expressions which have a LOT of power. This means that logic can be triggered from many different places in your component (the html template, the xml descriptor for the component, or the java itself). If you are on a team with more than few developers each with a different style of handling tapestry it can lead to some confusing code to follow. Over time (even with a lot of disciplined developers) this issue only gets larger.

  • Abstract classes - Not only does tapestry force you to inherit from its own classes but you must mark your classes as abstract. This makes testing components unnecessarily difficult (because you cant just new them up, not to mention how would you simulate the request lifecycle mentioned earlier) and leads to some cryptic error messages at times.



I think Tapestry is a great framework with a great community. I understand that in later releases they are working hard to address these issues and I will be keeping an eye on their progress. Tapestry was a key reason why the small team of developers I worked with was able to be so productive in bringing new products to market as well as maintaining old products... However at this point in time I feel for the new projects I am working on Wicket will make myself and the team I work with more productive.

Re: JSF by Ryan Crumley

I hope that my original post did not shed a negative light on Spring Web Flow. I think it is a great product. Over the past year SWF has added support for a lot of the common webisms that I spoke about in a very clean manor. I had great success in integrating SWF with Tapestry 3 (I would have liked to open source the integration however because of the design of Tapestry3 it proved to be very difficult to create a module out of the integration).

My only gripe is that applications which have a lot of hub and spoke navigation SWF adds a lot of overhead to development time (and adds little value)... If you application is more workflow based than hub and spoke check out SWF it will do wonders for your application otherwise I have found it very difficult to justify using it.

Re: Tool support and documentation by Ryan Crumley

One of my evaluation criteria was tool support (JSF did very well). I did not use any tools when creating my JSF prototype application however I imagine it would make some of the more tedious tasks easier (such as creating a 'component' ).

JSF may be well documented as a specification however the implementations seemed very splintered. Searching for a tutorial, example, or bug fix for an issue I was experiencing was difficult because each implementation has its own quirks that may not apply to what you are looking for.

Re: Wicket is cleaner than Tapestry, yet flawed in that by Nic Holbrook

Sounds like you've really done your homework on Stripes. I have personally tested stripes, spring mvc, tapestry, jsf, and webwork. Before stripes came along, I was leaning towards webwork all the way. Now I use stripes and haven't looked back. I am curious as to why you think stripes has less flexibility than webwork? In my experience, it is the most flexible framework out there.

Re: Tool support and documentation by Thomas Anderson

The tool support for JSF shouldn't be discounted either. Once you're outside JSF there pretty much isn't any.

Likewise for documentation. JSF is well documented. Most other frameworks are not in my experience.


JSF is part of JEE 5, that is the only reason being used by most people. Hopefully some new framework will replace it soon

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

43 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT