strut vs. wicket framework, any opinion??

[sirpelidor]

Hi, I'm about to develop my first java web app, and I've been through a lot of readings (i spend over 3 months just to do readings), I found out there's many web frameworks available for java. JSF, Spring, Strut, and Wicket (etc etc).

Other then tutorial found on google, I've also finished reading Strut (http://oreilly.com/catalog/9780596006518/) and 1/3 of Wicket. (http://www.manning.com/dashorst/). Just like everyone else, I only got 24 hrs a day, all these frameworks and their differences are driving me insane. Anyone got any opinion on any of those framework, preferences and why? Would dataaccess tier such as hibernate would be enough or do you use EJB? When and why would u use ejb? Is (should) there any alternative to ejb?

I have .net (1.x and 2.0) background, I'm hoping to find a framework that is not too far away from asp.net/ado.net so the learning curve won't be as steep.

Thank you for your input.

[chazzy]

ejb does quite a bit more than just data access, though most people seem to have given it that simple wrap. the problem with using either framework (wicket and struts) is that neither has native EJB connectivity support, so it becomes a pain when you do actually want to integrate stateful/stateless beans into a web app. if you do go the ejb route, i'd recommend you use JSF since you can give a reference to an EJB from a managed bean, and it wouldn't hurt to look into JBoss's Seam framework.

There's another tool you can look at, Spring. There's even a .NET version you may have looked at before. It markets itself as an "Inversion of Control" container, meaning the actual implementations behind each bean aren't known to the referencing user at any time. it helps with customization/dependency injection. it has its own MVC tool as well, and integrates well with Struts and Hibernate. it typically replaces ejb's as the business rules tier of a web application, but it doesn't natively support things like web services (at least, not as easily as ejb supports them).

one of the downsides of Wicket (and GWT, btw) is that the development style use is unique. It was long ago decided by the demigods of web development that web pages should be written in a markup language, to make compilation easier. wicket uses a combination of markup and regular class files. it will probably take you longer to develop a wicket app than other apps, but the fact that it's a more comprehensive framework should help you a bit.

as far as features like localization go, it serves the reminder that "the whole should be strong than the sum of its parts." meaning, JSP natively supports localization (via a standard taglib). If the framework doesn't support it, it's no good.