Where JSF and struts2 fails/goods - jsf

I am begining a web system and can't decide what technology use! Struts2 and JSF (with jboss seam) are a nice choices, but I can't decide which's better. In JSF have some that I don't like, maybe its "paradigm" no action like. And Struts2, the peoples here don't use more.
The system is a map collaborative web site.

I have used both Struts2 and JSF extensively, both are good but I would still recommend JSF. Here is why.
More users. Yes this counts; more people means its easier to get hands on new programmers.
Better tool support. IDEs like IntelliJ have very good JSF support.
Facelets. Lets face it, JSP sucks. You simply should not be allowed to write business logic inside your view code. Keeping your views in XHTML ensures that they are clean and tidy.
Documentation/Books. This might have changed, but when I was in the struts2 camp (2007/2008) the books available was few and of very poor quality. There is a good choice of JSF/Seam books.
JSF2/Seam. JSF2 is very nice (and IntelliJ 9 supports it). New scopes, such as the view scope, are really helpful (fx. if you are having a long running conversation in a flow).
If you are interested in some of the newer features in JSF2 then checkout this blog post. Also you might want to check out Stripes, it is also a very nice server side web framework and finally here is a very thorough (and a little old) comparison of most Java web frameworks.

This a very debatable topic. I think the main advantage of Struts2, compared to JSF, is its simplicity, it is much easier to grasp. Specially for beginners in web programming, or those familiar with "action based" web frameworks (Struts 1, Webworks, Spring MVC, Stripes).
But Lars Tackmann's points are valid (though Struts2 does not force you to use JSP; and indeed it uses FreeMarker internally). It's true that Struts2 has not attained a big user base, the community (both users and developers) does not seem to be very active, and that is a big minus. JSF also has its shortcomings, I've heard (I've not used it)... as every Java web framework, it seems.

Related

JSF modification in Groovy way?

Somewhere in Grails family I had a lecture about conneting JSF / Groovy / Grails. I.e. less configuration, more convention, Groovy session bean returning "next" navigation link etc.
Very interesting at intellectual level, but i think these tools have acceptance by totally different teams / people. JSF (standard, certified etc) in corporate programming, G* technologies at small, independent development.
Meet anybody real project using such mixing?
(To understand my POV: in web programming I prefer Wicket, JSF in prototype, I'm quite new in Groovy, and no real project in Grails)
We have both JSF and Grails applications. We are in the process of sunseting the JSF applications and all new applications in Grails. I have read that the LinkedIn site used Grails on a larger projects with much success. I am still on the Grails 2.X platform. Switching developers from JSF to Grails was an easy transition for me and generally provides a large increase in productivity over JSF. I highly recommend Grails over JSF.

Any success stories for JSF, GWT, Wicket or Tapestry on the web?

I am searching for framework references. In other words I am looking for companies, which have successfully implemented a framework solution in java web application environment (success stories). Frameworks I am interested in are JSF, GWT, Wicket and Tapestry. I wasn't able to google any results, nor to find any references at the official sites. At the end I am a bit confused if there are any. Can someone help me out?
Some more webresearches resulted in nice findings:
Wicket: http://web.me.com/jonathan.locke/JonathanLocke/Wicket.html
Tapestry: http://wiki.apache.org/tapestry/PoweredByTapestry and http://wiki.apache.org/tapestry/SuccessStories
JSF: http://wiki.java.net/bin/view/Projects/RealWorldJSFLinks
If you can find anymore, plz let me know :)
Not aware of JSF, Wicket and Tapestry based apps, but Google Wave, Adwords, Adsense are built using GWT
mobile.walmart.com, that surely has some serious traffic, is built with Wicket.
One of the reasons to go for Wicket was the complete decoupling of code and markup. The site serves three different kinds of HTML for different classes off mobile devices from the exact same code on the server.
http://www.dzone.com/links/apache_wicket_powers_mobilewalmartcom.html
Websites based on Wicket seems to be the largest list of Wicket websites out there.
For what it's worth, I was the architect on one of those sites, a financial services portal. There were three other developers, two of them were GWT fans. I haven't kept in touch with one of them, but the other has started his own company using Wicket, leaving GWT in the process. I personally don't like GWT because of the javascript compilation. Wicket has excellent ability to keep markup and code separated throughout the product lifecycle, something that is very hard to do with many technologies. I was a fan of Tapestry for a while, that is until I found Wicket.
Two other frameworks that are JVM based and worth considering are Lift (uses Scala) and Vaadin. People who love Scala swear by it, and after seeing a demo of it, I have to admit I want to start using it soon too.

JSF Adoption and Popularity

Just a general question, open for discussion...
I'm very much liking JSF so far, I'm new to it, but I prefer it to Struts. From a professionals standpoint, do you see a strong future for JSF ? Is it worth an investment as a young programmer to learn JSF 2.0 over Struts or another similar framework ? Should I stick to regular JSP ? Is Ajax really simpler through JQuery than JSF ?
I like new technologies and I like what I see so far from JSF but I want to be practical as well, and a lot Google searches turn up some bluntly critical comments about JSF 2.0.
Thoughts ?
Comparing JSF with Struts is like comparing apples with oranges. Struts is a request/action based MVC framework while JSF is a component based MVC framework. Struts is also aged. In the IT you're supposed to keep moving. Generally, a component based MVC framework is seen as a further evolution of a request/action based MVC framework.
JSF is currently already used very widely. It has indeed received a lot of critism before. You can read about most of them in the question What are the main disadvantages of JSF 2.0? The strength of JSF is mainly being a Java EE maintained standard and the availability of relatively a lot of 3rd party component libraries (PrimeFaces, RichFaces, IceFaces, OpenFaces, Tomahawk, etc). With JSF, it's very easy to develop CRUD applications and web forms with nice look'n'feel quickly.
However when it goes into the complex, JSF may cause some unforeseen surprises. Although the JSF specification and reference implementation (Mojarra) is pretty mature since the latest 1.2 builds, you may encounter some very specific behavioral problems which goes against your intuition. Some are just "by design" and can only be understood when you understand in detail how JSF works under the covers which in turn often boils down to the stateless nature of the HTTP protocol. JSF abstracts it in essence "too much" away that you don't see it anymore. Some are just bugs in the 3rd party component libraries used, but that's thus not strictly JSF-implementation-specific. Bug/issue handling is however pretty good in most of the major component libraries -if you report the bugs timely.
As to ajaxical stuff, JSF 2.0 indeed provides very little manual control over manually firing ajaxical requests and controlling the view tree in both server and client side. Simply because it's a component based MVC framework which keeps the tree state at the both sides. You've got to take the both sides into account when taking the ajaxical works in your own hands. If you really need more freedom in ajax/request based actions, then a component based MVC framework is simply the wrong choice. You should pick a request/action based MVC framework instead like Spring MVC, Struts or Stripes, along with a JS library like jQuery. You however have to write lot of HTML/CSS/JS boilerplate yourself instead.

Wicket vs GWT - Advice needed

I am developing a Java EE based web application. We have a very limited time to come up with a alpha version and trying to decide on a web framework to use. It has to be something easy to learn but powerful. Standard JSP/Servlet is not an option here due to the time it takes for the development. Appreciate if anyone could advice. Current options are Wicket and GWT. (JSF is also an option)
Wicket is component-based and comes with a bunch of standard components (like pagination, auto-complete, data grids, form handling etc.). If you want to create a standard panel (with the possibility for easy re-use) just create your HTML fragment to use a template (with wicket:id attributes wherever you want to bind dynamic content or sub-components) and a corresponding Java file. Furthermore, you can attach specific CSS and JS files.
In my opinion, Wicket development is good value (functionality) for money. And you get a lot of built-in AJAX functionality without even writing (not reading) any JS. E.g., change the model for a component, attach the component to an AjaxRequestTarget and the panel is automagically repainted via DOM manipulation.
For a quick overview and intro I recommend Wicket in Action by Dashorst & Hillenius. (And don't miss out on other great resources.)
Everything depends on your application. I don't have experience with Wicket, not much with JSF. I have big experience with GWT.
GWT is good if your application has to be mostly dynamic. In GWT you can change everything on the page not even calling the server. GWT is compiled to Javascript. On the other hand, if you have big project, it is quite frustrating if your application in development starts few minutes, because it has a lot of code to compile to Javascript. My opinion: it is not good for big projects.
If you don't need to change your pages so much client-side, I would use JSF2 (or Wicket, if I knew it).
Have a look at this comparison of Wicket and GWT, this may help you decide for yourself:
Wicket and GWT compared with code

Are JSF/Seam/Spring suited for non-enterprise work? (website, not "web application")

I'm starting work on a new website (sort of an e-commerce product comparison thing) and I'm trying to choose what technologies to build it on. I've ruled out PHP and I don't think I want to use Python or Ruby. I really like Java and Hibernate so I started looking into Java-based web technologies.
My problem is that all of the documentation and examples I've read can't seem to stop repeating the words "enterprise" and "web applications." I'm afraid of ending up with giant XML configuration files and business-oriented components while losing the ability to actually design the website. From what I've read of JSF, I like the idea of reusable components, but I still want the ability to customize individual pages. So my question is, are JSF/Seam/Spring well-suited for non-enterprise development? If not, what Java technologies are?
I have just started looking into JSF/Seam so please forgive me if this is an uninformed quesiton. Thanks in advance. :)
No problem. The JSF/Seam stack gives you all the customization you want, and it has very few XML files. In fact, it uses a lot of annotations to define entities and components, so you don't have to worry about writing tou much XML (it is one of the reason why Seam was invented).
JSF's standard components are rendered as simple HTML tags, while if you want to go AJAX and use Richfaces it will be a little harder to customize it, but nothing dramatic. I can assure you that for the view part, you can write whatever you want in your webpages.
Here's a nice reference of how the JSF tags are rendered.
For the model and DB part, the JPA framework gives you the ability to work with simple Java Objects, and sometimes using it in an "enterprise" context with legacy schema is even more difficult, so don't worry.
For a simple website you may safely skip the EJB part, this will help you writing a more cleaner project structure. You can package all your website in a simple .WAR file.
As for the "enterprise" word, I think it is more related to the fact that the Java EE framework gives you the feature you may need in an enterprise context, (i.e. EJBs), but you can avoid them.
They don't bite.

Resources