Why should i use JSF rather than Struts?

Question

What makes JSF useful than Struts? In my project I am using like
<h:commandButton action="#{loginbean.execute}" actionListener="#{loginbean.handleEvent}" ..../>
In the above commandButton as you can see that i am not exposing the beanName. However i am exposing the beanMethod which are execute and handleEvent. Is there any other way to hide the name of the method because
From what i understand is Presentation Layer should be shielded from whatever is going on in the backend. So, this doesn't do good right?
Please suggest.
How does Component and Renderers help. I am using encodeEnd() method in Renderer to render what the input or the output should look like. Do we need to switch to JSF from Struts just because of this... I don't see how and why components and renderers could help me..

Answer 1

srikanthradix wrote:
What makes JSF useful than Struts? In my project I am using like
<h:commandButton action="#{loginbean.execute}" actionListener="#{loginbean.handleEvent}" ..../>
In the above commandButton as you can see that i am not exposing the beanName. However i am exposing the beanMethod which are execute and handleEvent. Is there any other way to hide the name of the method because
From what i understand is Presentation Layer should be shielded from whatever is going on in the backend.You can use "binding" and define everything in Java code if you want. You can rename your method to reflect what you want to see in the front end if you want. You can use JSFTemplating to use handlers which can be mapped to any name you want to see and do not have to match the method name of the java class (although I suspect this is the opposite direction from what you are suggesting you want).
EL in jsf (i.e. #{bean.login}) is meant to do the mapping in JSF pages rather than externalize this in a separate file and force the page developer to edit multiple files for simple tasks. Although in some cases navigation is broken out into a separate file (i.e. faces-config.xml file using the default NavigationHandler navigation rules), this can also be done inline. It's a different way of doing development and has its pros and cons (easier, but mixes up presentation and controller somewhat). That said... JSF is very flexible, it CAN externalize any of this information, it just requires you to provide a different ViewHandler information that allows you to enter the data the way you like to see it (imo, you won't realize any benefit from the separation, though -- I used to think it was worth doing but have changed my opinion).
So, this doesn't do good right?Perhaps in theory... but in practice, I don't think it really has a drawback. One caveat, I like how I implemented event handling in JSFTemplating as opposed to action/actionListener attributes which are not configurable and are more opaque than I prefer. My parameterized handlers allow for better code-reuse, but arguably mix up presentation and controller code even more (depending on how they're used).
Please suggest.
How does Component and Renderers help. I am using encodeEnd() method in Renderer to render what the input or the output should look like. Do we need to switch to JSF from Struts just because of this... I don't see how and why components and renderers could help me..The idea of a component helps tremendously as someone else can create a component for you and you can benefit from it. There are many great component sets available on the market (for free and for purchase). For example: Woodstock (which has drag/drop support inside NetBeans), RichFaces, IceFaces, Tomahawk, Scales, etc.
Renderers allow you to cleanly separate the presentation of a component with the data of the component. You can then switch out the presentation to support multiple markups (i.e. client devices). In addition, JSF's rich lifecycle provide logical places for certain types of operations to occur, the renderers participate in this so that they are performing their tasks at a well defined time. And finally, many different components may re-use the same renderer, or a single component may use one of several renderers. The separation of data and display (model and view) makes this very clean.
JSF is not Struts. If you expect it to be struts, you may be disappointed (or if you expect struts to be JSF, you'll be disappointed). JSF has a lot to offer (as does struts), you have to decide what is important to you and your organization. Some things to consider wrt to JSF: very strong vendor support; many large set of components to choose from; multiple standards-based tools to choose from; very flexible (most parts of the framework are pluggable); active growing development community; component-based model which encapsulates complexity for things like Ajax, pagination, and other things (often complicated in a non-component architecture); good integration with other frameworks.
I don't know if this makes your decision any easier, but hopefully it helps clarify how you should be viewing JSF & Struts.
Good luck!
Ken Paulsen
https://jsftemplating.dev.java.net