Can you compare the advantages and
disadvantages of JSF vs. Struts. Both now, and from what you may know of
futures, how and if JSF will evolve into a superior technology vs.
Struts? Include how WSAD plays into the comparison if it will help
differentiate the two.
This is a very popular question these days. In general, JSF is still
fairly new and will take time to fully mature. However, I see JSF being
able to accomplish everything Struts can, plus more. Struts evolved out
of necessity. It was created by developers who were tired of coding the
same logic again and again. JSF emerged both from necessity and
Struts has several benefits:
* Struts is a mature and proven framework. It has been around for a few
years and deployed successfully on many projects. The WebSphere
Application Server admin console is a Struts application.
* Struts uses the Front Controller and Command patterns and can handle
sophisticated controller logic.
* In addition to the core controller function, it has many add-on
benefits such as layouts with Tiles, declarative exception handling, and
There are disadvantages:
* Struts is very JSP-centric and takes other frameworks to adapt to
other view technologies.
* Although Struts has a rich tag library, it is still geared towards
helping the controller aspect of development and does not give a sense
that you are dealing with components on a page. Therefore, it is not as
toolable from a view perspective.
* Struts requires knowledge of Java™. Its goal was to aid Java
developers, but not to hide Java. It does not hide details of the Java
language to Web developers that well.
* ActionForms are linked programmatically to the Struts framework.
Therefore, to decouple the model, you need to write transfer code or use
utilities to move data from Action Forms to the Model on input.
JSF is an evolution of a few frameworks, including Struts. The creator
of Struts, Craig McClanahan, is one of the JSF specification leads.
Therefore, it is not by accident to see some overlap between Struts and
JSF. However, one of JSF's major goals is to help J2EE Web applications
to be easily developed using RAD tools. As such, it introduces a rich
component model. JSF has several advantages:
* JSF is a specification from Sun® and will be included in future
versions of the J2EE specification. All major vendors are pledging
strong support for JSF.
* JSF uses the Page Controller Pattern and therefore aids in Page rich
applications. Components can respond to event from components on a page.
* JSF has a well-defined request lifecycle allowing for plugability at
* One powerful example of plugability is building your own render
toolkit. The ability to separate the rendering portion from the
controller portion of the framework allows for wonderful opportunities
of extensibility. Component providers can write their own toolkits to
render different markup languages, such as XML or WML. In addition, the
render toolkit is not tied to JSP.
* Because JSF has a rich component model, it favors a RAD style of
development. I can now build my Web pages using drag and drop
technology. In addition, JSF gives me a way to link visual components to
back model components without breaking the layering.
JSF has disadvantages:
* JSF is still quite new and evolving. It will take some time to see
successful deployments and wide usage. In addition, as vendors write
components, they may not do everything you want them to.
* JSF by hand is not easier than Struts. Its goal was more oriented to
RAD. Those who prefer to do things by hand (for example, the vi type guy
who does not like IDEs) may find Struts easier to develop.
* Struts navigation may be a bit more flexible and adhere to more
complex controller logic.
One of the shortcomings in Struts 1.0 is manageability of the
configuration file (commonly known as struts-config.xml) when the
development of the application involves a sizable team. This problem
arises because a Struts-based application must run under one controller
servlet, the ActionServlet, and the ActionServlet can use only one
struts-config.xml. It is not an issue when the project is relatively
small and the team consists of a couple of developers; however, when the
project size becomes significant and the project involves a large number
of developers, maintaining all the mapping information in a single file
becomes increasingly problematic.
Struts 1.1 solves this problem nicely by introducing multiple
sub-applications. In Struts 1.1, each sub-application has its own
struts-config.xml file. A large Struts-based application can thus be
easily partitioned into largely independent modules, i.e.
sub-applications, and each sub-team can maintain their struts-config.xml
The sub-application scheme is a natural extension of the servlet context
mapping scheme of the URI paths used by servlet containers. According to
the Servlet standard, when the servlet container receives a request with
a URL, the servlet container will try to match the prefix of the URI
path to a deployed web-application in the container. What Struts 1.1
does is it maps the second prefix of the path to a sub-application. In
effect, this prefix mapping scheme creates another level of namespace
for each sub-application. For example, for the URI,
/myApp is the context path for a web-application called "myApp" and
/module2 is the sub-app prefix for a Struts sub-application called
DynaBean and BeanUtils
Another major complaint usually heard amongst Struts 1.0 users is the
extensive effort involved in writing the FormBean (a.k.a. ActionForm)
Struts provides two-way automatic population between HTML forms and Java
objects, the FormBeans. To take advantage of this however, you have to
write one FormBean per HTML form. (In some use cases, a FormBean can
actually be shared between multiple HTML forms. But those are specific
cases.) Struts' FormBean standard follows faithfully the verbose
JavaBean standard to define and access properties. Besides, to encourage
a maintainable architecture, Struts enforces a pattern such that it is
very difficult to 'reuse' a model-layer object (e.g. a ValueObject from
the EJB tier) as a FormBean. Combining all these factors, a developer
has to spend a significant amount of time to write tedious
getters/setters for all the FormBean classes.
Struts 1.1 offers an alternative, Dynamic ActionForms, which are based
on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs
(think HashMaps) but behave like normal JavaBeans with the help of the
BeanUtils library. (Both the DynaBeans and the BeanUtils library were
found to be useful and generic enough that they have been 'promoted'
into Jakarta's Commons project.) With Dynamic ActionForms, instead of
coding the tedious setters/getters, developers can declare the required
properties in the struts-config.xml files. Struts will instantiate and
initialize Dynamic ActionForm objects with the appropriate metadata.
From then onwards, The Dynamic ActionForm instance is treated as if it
is an ordinary JavaBean by Struts and the BeanUtils library.