On Sat, 2004-03-20 at 20:41 -0800, Craig R. McClanahan wrote:
Quoting Thomas L Roche [EMAIL PROTECTED]:
David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of
his remarks include
- Is JSF a replacement for Struts? Yes!
- JSF is a standard. Struts will never be a standard.
which I believe to be pretty-nearly-direct quotes. I'm assuming he
really meant
+ JSF 1.0 can do pretty much everything Struts 1.1 can.
There is definitely substantial overlap, especially in the HTML tags area, as
well as things like outcome-based navigation handling and creating form beans.
The design of JavaServer Faces benefited tremendously from the experience we've
had with Struts, and the design in these areas exceeds the current
functionality of Struts in many respects.
Two particular features of Struts that are not present in JavaServer Faces 1.0
-- Tiles for layout management, and the Validator Framework for creating client
side JavaScript to enforce the rules (in addition to enforcing them at the
server). Fortunately, however, you can use these Struts features in
conjunction with JavaServer Faces by using the Struts-Faces integration
library.
With JSP2.0 attributes and fragments you can do advanced layout and
templates without tiles. I am sure the validation would also be
addressed with time.
There is a huge amount of momentum around Struts, and it's not going to go away
any time soon. That being said, however, it's time for Struts to start doing
some more innovation instead of incremental improvements, in order to remain as
popular for new development.
That is my point exactly and I am hoping that struts would innovate and
implement some of the things other frameworks use.
+ JSF is a JSR, and Struts will never be a JSR.
but I'm wondering about that last statement. What prevents Struts
from undergoing the JCP? Are there circumstances under which you
might consider this?
For those not familiar with it, some brief background on the JCP would be
useful
here. More details are at the JCP web site http://jcp.org.
Anyone who is a JCP member can propose a JSR. To be accepted, it would to be
accepted by the 16 members of the Executive Committee for the J2SE/J2EE
platform (note that Sun has one of these 16 votes -- people who believe that
Sun could veto a JSR proposal for something like this, even if Sun wanted to,
are misinformed; that veto ability only applies to language changes or uber
JSRs like the ones for the entire J2SE and J2EE platforms). The person(s) or
organization(s) proposing the JSR would need to plan on (if it's accepted)
providing a specification documenting the Java API or technology to be
standardized, a Technology Compatibility Kit (TCK) against which other
company's implementations of the technology can be tested, and a Reference
Implementation (RI) -- which must pass the TCK -- proving that the technology
can actually be implemented.
If by the you in your question you are referring to the Struts committers, we
could indeed propose such a JSR (Apache is a JCP member, and is currently also
a voting member of the Executive Committee). But it wouldn't really be a JSR
to standardize Struts ... at most it could be a JSR to standardize the APIs
supported by Struts. After all, the JCP is really a standards organization
that creates specifications to be implemented by others. Struts (and many
other open source projects) are often not implementations of some standard --
they can be seen as sort of a combination of spec and implementation rolled
into one. If the long term goal is that everyone continues to use the one and
only implementation, then the JCP is not really the right development approach.
Beyond that, the Executive Committee members will tend to not desire multiple
JSRs with large amounts of functional overlap -- which would definitely be the
case if someone tried to propose the Struts APIs. After all, these are
companies that would need to fund the development of their own versions of the
hypothetical standard Struts, and the cost of integrating it into their own
products. It is much more cost effective (as well as less confusing and costly
for users) to support a single standard in each technology area, and add
functionality in future versions as it makes sense to standardize.
As such, it seems much more likely that the Executive Committee would accept a
JSR for some future version of JavaServer Faces that built on top of of the 1.0
version than a JSR for a different way to solve many of the same problems. The
planning for the next steps in this direction, in fact, is already in
progress.
We as Struts developers, then, should focus on adding additional functionality
to our platform, to maintain and enhance its usefulness. Not being
constrained by a standards process, we can proceed at a pace solely limited by
our capabilities to imagine the new things and
