On Sat, 20 Mar 2004, Nadeem Bitar wrote: > 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.
Such as? What kinds of innovations are you looking for, and specifically what kinds of things are you seeing other frameworks use that Struts could benefit from? -- Martin Cooper > > > + 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
