On Sat, 13 Sep 2003, Ted Husted wrote: > Date: Sat, 13 Sep 2003 17:12:51 -0400 > From: Ted Husted <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: Re: Where is Struts 2 going? > > > On Sat, 13 Sep 2003, Niall Pemberton wrote: > >>I may have got the wrong end of the stick, but doesn't Struts overlap to > >>some degree with JavaServer Faces and wasn't there talk of perhaps Struts > >>evolving to be a implementation of JavaServer Faces? > > Craig R. McClanahan wrote: > > That's certainly a possibile evolution (or perhaps even a subproject), if > > enough developers are interested. Thanks in large part to Apache's > > advocacy and influence, the JCP process has been modified so that we > > (Apache) can even qualify for the certification scholarship (for > > nonprofits) and access to the TCKs and certify that our application is > > compliant. > > > > If we were to do that, it wouldn't be the *reference* implementation, of > > course, but it would certainly be an Apache-licensed open source > > implementation. > > Personally, I would suggest that if people were interested in an Apache > implementation of JavaServer Faces, that it begin in the Jakarta > Commons.
There's an issue of scale here, which makes Commons IMHO not a good place for a JavaServer Faces implementation. The current RI is roughly the same size as the current Struts Core + Taglibs, and indeed has a roughly similar scope of applicability. This is a very different sized thing than something like BeanUtils or Resources or Digester. There's a precendent with Jelly, who used commons-sandbox as an incubator but then chose to graduate to Commons Proper instead of a separate project. IMHO, this was a mistake that has held back developing a larger community. > Many Java frameworks now support JSP and will certainly want to > support JSF in the future. [Of course, for Struts, the future is now, > since we already have a JSF taglib ready to rock. =:0)] > > By exposing "Jakarta Faces" at the highest possible level, the greatest > number of projects and teams will consider using the product and joining > its community. > There are at least four rational ways that such a thing could be created within Apache organizationally: * As a "side project" of the Struts subproject of Jakarta. This is not ideal (because by itself it's roughly the same size, and will need some focused development, and would need more visiblity to attract additional developers). * Morph Struts itself into being "Jakarta Faces plus other stuff". Since we're willing to look at breaking backwards compatibility in Struts 2.0, this is a viable technical option, but may be too narrow a basis if we really want to grow beyond the presentation tier. * As a completely new and separate project, commissioned through the Apache incubator process, with an ultimate destination of either Jakarta (as a subproject parallel to Struts) or as a completely separate "Apache Faces" project with its own PMC (like Ant, Avalon, and James). * Graduate Struts into a top-level Apache project with some sort of charter around frameworks/tools for web applications, and commission "Struts Faces" as one of the subprojects, which would become parallel to other subprojects created by splitting our current Struts work into at least two pieces (core framework and taglibs). If there are enough interesting things to do in the "frameworks/tools for web applications" space (and I believe there are), the last option would be pretty interesting. Also intersting would be the discussions with the Tapestry and Turbine folks on combining forces on at least some of the common technologies (i.e. the types of things that have often become Jakarta Commons projects in the past), and perhaps on more fundamental combination of efforts. > In this way "Jakarta Faces" could focus on being a "by the book" > implementation of JSF. Meanwhile frameworks like Struts could offer > (yet to be determined) "value add" features that go beyond the formal > specification. "Jakarta Faces" might not be the reference > implementation, but that doesn't mean we can't treat it like one =:0) <side-note>It's been quite interesting to watch how the term "reference implementation" has been morphed from a pejorative complaint several years ago -- an implied "it's *only* the reference implementation" -- into a perception of high quality :-)</side-note> Under any organizational arrangement, we would definitely want to separate the "by the book" implementation from Struts-provided value adds. Among other reasons, it is possible/likely that a JavaServer Faces implementation might become a requirement for J2EE > 1.4, where it would be built in to the container rather than needing to be carried along with your webapp. We'd want our value add stuff to work seamlessly in such an environment, without our own "by the book" JavaServer Faces implementation included. Fortunately, the architecture of JavaServer Faces makes this sort of separation very easy to maintain, as long as we think about it from the beginning. > IMHO, the true value of Struts has been the way it helps people "put the > pieces together" by leveraging existing technologies like JavaBeans, > JavaServer Pages, JDBC, Localization, and so forth. So moving forward, I > see JSF as one more link in the chain. Once people start rolling out > applications based on JSF, I'm sure there will be plenty of "missing > links" for frameworks like Struts to provide. > There will definitely be such gaps. Two of them we can already fill (Tiles and the Validator Framework). Others will involve frameworks for multi-request transactions, non-HTML markup languages (building on top of Faces for things like XUL or XForms or SVG is easy), non-JSP rendering technologies (pretty much anything that has a way to mark where dynamically created output goes can be adapted), libraries of prebuilt components above and beyond the built-in standard ones (such components work equally well in JSP and non-JSP environments), and all the non-human-UI things based on XML technologies. To say nothing of the fact that we could start to provide useful design patterns and implementations for the business logic tier as well as the presentation tier (like what Ted has done with Scaffold). > -Ted. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
