Wednesday, October 05, 2005

[itsdifferent] Top Ten Reasons to Prefer JSF to Struts

Hi friends,

This is for Java Guys working on web development frameworks..
---------------------------------------
Top ten Reasons to Prefer JSF to Struts
---------------------------------------

Components
Render Kits
Renderers
Value Binding Expressions
Event Model
Extensibility
Managed Beans (Dependency Injection)
POJO Action Methods
JSF is the standard Java-based web app framework
There's only one Struts

#10: There's only one Struts

Struts is an open-source product, whereas JSF is a specification.
That's a subtle distinction, which is often lost on JSF newcomers,
but it's significant because we can have numerous JSF
implementations. As young as JSF is, we already have two excellent
JSF implementations to choose from: the Reference Implementation from
Sun and MyFaces, from Apache. On the other hand, there's only one
Struts.

#9: JSF is the standard

JEE 5.0 containers must provide an implementation of JSF, which means
that JSF will soon be ubiquitous. That might not matter to you, but
it matters to tool vendors. With approximately 50 Java-based web app
frameworks, tool vendors have been reluctant to support a particular
framework, but a standard is something tool vendors can, and have,
rally(ied) behind. But it's not just vendors: open source projects
are rallying around JSF with such dizzying speed that they're
stepping over one another to implement the same features. For
example, I hadn't even heard of Facelets until we were done
implementing essentially the same functionality with Shale's Tapestry-
like views. (I believe that redundancy is a good thing and will serve
us well in the long run)

#8: POJO Action Methods

Struts actions are tied to the Struts API, but JSF action methods can
be implemented in Plain Old Java Objects. That means you don't have
to implement an additional layer of actions that mediate between your
forms and your model objects. btw, notice the careful wording of this
item: there are no action objects in JSF because actions are
typically implemented in model objects. But also note the careful
wording of that last sentence: you can certainly create separate
action objects if you want with JSF. Also with Struts, you have a
form bean and an action bean. The form bean contains data and the
action bean contains logic. OO purists want to put them together, but
you can't with Struts. In JSF, you can spread out your data and
logic, or put them in one object. The choice is yours.

#7: Managed Beans

Like Spring, JSF uses dependency injection (or inversion of control,
if you will), for instantiating and initializing beans. It's true
that Struts creates action beans and form beans for you, but JSF
generalizes that concept and adds the ability to initialize managed
beans—of any type—created by the framework.

#6: Extensibility

This is huge. JSF has 6 objects that implement much of the
framework's capabilities and you can easily replace those objects by
decorating the default implementations. That makes it ridiculously
easy, for example, to add your own custom variables to the JSF
expression language. It also makes it easy, for example, to plug in
your own view handlers, perhaps a view handler that implements
Tapestry-like views so you can truly separate components and HTML. In
fact, Shale, does both of those things. As if that weren't enough,
JSF gives you numerous hooks into the JSF lifecycle to inject your
own voodoo. Shale gives you even more.

#5: Event Model

JSF has an event model that lets you react to value changes, actions,
and phase changes in the JSF lifecycle. In JSF 1.1, those events are
handled entirely on the server, a sore point to be sure, but JSF 2.0
plans on supporting client-side events as well. Stay tuned.

#4: Value Bindings

With Struts, you are responsible for ferrying data from your forms to
your model objects. You implement an action with an execute method
that takes a form bean as an argument. Then you manually pull data
out of that form bean and push it to your model. For every form in
your application. Ugh. With JSF, you do this: #{model.property}.
That's all. JSF takes care of the rest.

#3: Renderers

Have you ever looked at the source code for Struts tags? They
generate HTML directly. JSF component tags, OTOH, don't generate
anything; instead, they refer to a component-renderer pair on the
server. The component maintains state whereas the renderer is in
charge of rendering a view. The point here is that renderers are
pluggable: you can replace the default renderers with your own
implementations; for example, in my Felix talk at NFJS, I illustrate
how to implement a custom label renderer that adds asteriks to labels
that represent required fields. You plug in that renderer, and JSF
will automatically use it throughout your application. Sweet.

#2: Render Kits

I had a Struts consulting job a few years ago where we had to support
both a browser-based interface and radio frequency devices, and it
was painful. That task would've been greatly simplified with JSF
because you can create your own render kit—a collection of renderers
for a particular display technology—and plug it into JSF.

#1: Components

Components are the number one differentiator between Struts and JSF.
Like Swing, JSF provides a rich infrastructure for developing
components in addition to a standard set of components. That
infrastructure makes it relatively easy to create your own components
and share them with others. Already, we're seeing custom components
popping up all over the place, for example with Oracle's ADF and
MyFaces, both of which provide a rich set of components such as
JavaScript-powered calendars, trees, etc. Of course, components are
only half the story; typically, components delegate rendering to a
separate renderer, which provides substantial benefits (see item #3
above). But, as with most things in JSF, you are not forced to adhere
to the party line. If you want, you can implement components that
render themselves, although if you do so, you will loose the ability
to plug a different renderer into your component.


Regards,

Ravindra Ghetia
CMCLtd,
ravindra.ghetia@gmail.com






Note: This Group is not a Job Searching Group, so please co-operate and dont transfer any kind of job related material across this Group.AnyOne doing so can be banned from the Group
Thanx , Group Co-Ordinators




YAHOO! GROUPS LINKS




No comments: