struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From souravm <SOUR...@infosys.com>
Subject RE: Is Struts still a better choice over JSF as on today ?
Date Sun, 29 Jul 2007 19:01:06 GMT

Hi Frank,

Thanks again for the detailed response.

I think I've got your points. Yes I'm aware of Swing/VB technology and that analogy helped
me a lot to understand the perspective.

However, I'm still not very sure whether the design approach of Swing/VB is a right fit for
a scenario where the underlying technology is http. They are good for a thick client scenario
where most of the event handlings happen in client machine (except the events which has to
communicate with server). So though design/development wise the component framework may help
a lot (after the initial learning curve), efficiency wise how the things will perform (and
of course lost of it will depend on the vendors implementation of JSF specification) is a
big question to me.

Regards,
Sourav

-----Original Message-----
From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
Sent: Thursday, July 26, 2007 9:25 PM
To: Struts Users Mailing List
Subject: Re: Is Struts still a better choice over JSF as on today ?

souravm wrote:
> Regarding going for JSF due to componentization, I'm again not sure what additional componentizations
JSF does compared to struts.

JSF is inherently a component-based framework, meaning you aren't really
thinking in terms of pages, your thinking in terms of components of a
"view".  Struts doesn't really offer this, although S2 gets closer to it
in many ways (and yes, there's some JSF support in S2 is you want it,
although I'm not too familiar with it myself).

 > Apart from the fact that JSF does not need a layer like Action
Classes, all other components (validator, managed bean, html tag libs
etc.) are already there in Struts. May be I'm missing something here.

I think your looking at the pieces and comparing them rather than
looking at the overarching paradigm of one framework vs. the other.  The
distinction has been diminished a bit with S2, but it's still there.

A component-based approach means your looking at individual elements
that make up a a particular view and thinking in terms of the
interactions the user can have with each.  You don't think in terms of
state transitions, you think in terms of events.

With Struts, it's about state transitions.  The user submits a form and
transitions to a new application state entirely.  I'm throwing AJAX out
of this for the moment of course :)

> Also, I'm yet to appreciate the real value add event handling mechanism of JSF can bring
in a web application scenario.

It's the ease, in theory, that it provides, and the fact that your
inherently thinking along those lines, rather than shoe-horning it in.
That's the value-add IML (in theory!)

 > Especially given the fact that all those events (associated with a
single http request) would be fired only in a sequential way at server
side.

I'm not quite sure what you mean by that...

 >
I really cannot think a usage scenario of multiple event handler feature
of JSF. Even in case of RIAs, I believe what is more required feature is
dynamic loading of part of a html page (which is currently the space
where AJAX is becoming popular). So any further explanation/example on
how you have found this feature of JSF to be useful for RIAs would be
helpful for me to understand your point.

It's not just about partial page loads, although that's clearly a big
part of it.  As I was describing before, it's more about the approach to
developing the application.

Are you familiar at all with Visual Basic?  If so, let me try and make
this analogy... working with JSF is more akin to developing in VB than
in Struts because your creating a given view that is a collection of
components, and then determining what events each component can trigger,
and coding for them.  When you write a VB app, you aren't typically
thinking in terms of this form leads to that form which leads to another
form (unless your talking a wizard flow, but that's a specialized case).
With Struts, it's always about a transition from one view to another,
from one form to another in VB, triggered by some user input (again,
putting AJAX aside for the moment).  The VB paradigm, is frankly more
logical to most developers.  It's more like Swing too if you think about it.

Now *with* AJAX in the mix, and with client-side component libraries
coming fast and furious, a lot of what made JSF potentially attractive
has, again IMO, been significantly diminished.  People have realized
that you don't need the full JSF stack, so to speak, and you can do
components without JSF too, so maybe it's not as valuable.  Now, JSF
still provides value there because it gives you a standardized component
model, something that is sorely lacking in client-side component
libraries these days (i.e., Dojo widgets and YUI widgets and APT widgets
aren't generally compatible, and certainly aren't designed to some
common pattern).

That's kind of what's happened in Struts land too... there's been a bit
of a melding of the component paradigm and the non-component paradigm,
largely with AJAX as the catalyst.

> Regards,
> Sourav

Frank

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
  (2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
  (2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
  Supplying the wheel, so you don't have to reinvent it!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of
the addressee(s). If you are not the intended recipient, please notify the sender by e-mail
and delete the original message. Further, you are not to copy, disclose, or distribute this
e-mail or its contents to any other person and any such actions are unlawful. This e-mail
may contain viruses. Infosys has taken every reasonable precaution to minimize this risk,
but is not liable for any damage you may sustain as a result of any virus in this e-mail.
You should carry out your own virus checks before opening the e-mail or attachment. Infosys
reserves the right to monitor and review the content of all messages sent to or from this
e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys
e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message