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 then implement and test them. > > Craig McClanahan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
