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.
Related
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.
I've been using Struts 1.x for more than 1 year now, and I've been learning about JSF recently. I know both JSF and Struts are different frameworks but I wanted to use Struts as Action framework and JSF as Component framework in my web application. I'm not sure if we can do that, and couldn't find any materials online regarding this.
Suggestions and links are welcome, Thanks in advance
Struts and JSF can be used in a web application, some(or no) changes might be required in the back end but as both the frameworks follow MVC, the "VIEW" tier would be much similar.
As JSF and Struts both have their own advantages, we can use the advantagesof of each combinedly, like ValidationFramework in Struts and JSF components (html components in Struts)
All this I would just only if you have an existing Struts application, can find more detailed information here
though the link talks about older versions, i hope it gives basic information
I am on the hunt for a extra component library to the core JSF 2.0 library. I need calender-pick, tabbed pane, tree view and other nice components to complete my Java EE 6 - Glassfish 3 project.
But I don't know which additional library to choose; MyFaces, OpenFaces, PrimeFaces, etc. I never tried any of them.
My most important requirement for the additional library I choose, is the footprint in bandwidth and memory it will make. It has the be a lightweight library, because the web-system is used by many users in the developing countries, where bandwidth is far from what we have in US/Europe. Plus it would be nice if there is some RAID editor tool for the web-designers people to use when designing the View/GUI part. Thought of Dreamweaver, but I don't know if it can render the components (JSF core and Faces libs)?
What additional Faces library do recommend me to choose?
RichFaces seems suitable option. You can use JBoss Tools (Free) as WYSIWYG IDE. It is being actively developed and maintained. The new version 4, will work even better with JSF2.
To conserve bandwidth you may need to look at compression techniques on static resources.
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.
I am reading through the Public Review Draft of the Web Beans specification (JSR-299) and I am wondering why it is so 'tightly coupled' to JSF?
Especially the Conversation Context seems only be specified for JSF.
I understand, that it is a goal of WebBeans to integrate JSF and EJB3. But would it not make sense to specify the concept of conversations on a more general level (maybe for Servlets in general and not for a specific web framework)?
Is there any technical reason for this? I think it can hardly be, because Seam (which is some Kind of WebBeans-Prototype) does also support Wicket and provides the concept of conversations.
I think it would be helpful to have a Conversation Scope on Servlet level (injecting of conversation-scoped beans into servlets). In my understanding, this is not the case with the ciurrent specification (see chapter 8.5.4). Or am I misinterpreting something here ...
Just found this today. The reason why the ConversationScope is JSF based is simply because JSF is the standard UI framework for Java EE!
Beside this, most of the JSR-299 containers can provide Conversations for other UI technologies like e.g. Wicket too.
Otoh you can easily create your own Scopes which are even portable.
LieGrue,
strub
I think it's soley down to Gavin King picking JSF as his view technology for Seam and him pushing through the JSR as spec lead.
Clearly conversations go wider - for instance, Spring custom scopes have a facility for providing conversations:
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/Scope.html