First of all, thanks for your comments on this mailing list and JDC JSF forum. I also made some comments below. > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 1:09 AM > To: IAS > Cc: [EMAIL PROTECTED] > Subject: RE: [Forward-Looking] Struts and JavaServer Faces > > > > On Mon, 14 Oct 2002, IAS wrote: > > > Date: Mon, 14 Oct 2002 15:13:45 +0900 > > From: IAS <[EMAIL PROTECTED]> > > To: 'Craig R. McClanahan' <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Forward-Looking] Struts and JavaServer Faces > > > > AS I posted some question on > > http://forum.java.sun.com/thread.jsp?forum=427&thread=308727, > > I have been very curious about how Apache Jakarta Project will > > respond to JSF. > > > > According to your comments, struts-faces.jar seems like a JSF > > implementation provided by Struts project, therefore it is open > > source and subject to Apache Licensing. What interests me is whether
> > struts-faces.jar will become (de facto) RI for JSF like Tomcat for > > SRV/JSP or not (meaning struts-faces.jar is just a component of > > struts for supporting JSF). > > > > The struts-faces.jar library is ***not*** an implementation of JSF -- > it is simply an adapter layer that lets you use Struts with any JSF > implementation, plus a couple of Struts-specific JSF components. > > Calling struts-faces.jar a JSF implementation is not only taking my > words way out of context, it is also distorting the meaning of what I > did say. > > > Thanks in advance for your opinion. > > > > IAS > > Craig > > > > > > Indepedent Java Technology Evangelist http://www.iasandcb.pe.kr > > > > Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org > > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 19, 2002 3:10 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: [Forward-Looking] Struts and JavaServer Faces > > > > Many folks on both the STRUTS-DEV and STRUTS-USER mailing lists, > > have wondered at what the future holds for Struts, now that the > > initial early access release of JavaServer Faces has become > > available. Here is a snapshot of my current thinking on the > > subject. > > > > > > BACKGROUND: > > ========== > > > > JavaServer Faces (JSF) is being developed as JSR 127 under the Java > > Community Process, with the goal of creating a standard framework > > for user interface components to be used in web applications. > > Included will be the > > following basic features: > > > > * User interface component model > > > > * Event handling model > > > > * Validation framework > > > > * Flexible rendering model (plugin support for rendering different > > kinds of HTML, or different markup languages and technologies) > > > > * A standard RenderKit (and associated Renderers) for generating basic > > HTML/4.01 markup. This library is primarily for making JSF useful > > out of the box, and allow apps to be portable across JSF > > implementations. However, we expect a lot of innovation in this > > area among competing JSF implementations. > > > > All of the above functionality is available via standard Java APIs, > > and is thus not tied to JavaServer Pages (JSP). However, because a > > large majority of JSF users will also be using JSP, an additional > > set of requirements is included in the JSF specification, including: > > > > * A standard tag library for generic things that are independent of > > the specific RenderKit in use (such as adding a validator to a > > component). > > > > * A standard tag library for the basic HTML RenderKit, with a tag for > > each combination of a component type and a method of rendering that > > component type. An example will make this clearer -- consider the > > UISelectOne component, which represents a list of options, and allows > > only a single option from the list to be selected. Such a component > > can be rendered in three different ways (in the basic HTML RenderKit), > > each with a different Renderer and a corresponding custom tag: > > > > <h:selectone_listbox> Display a list of all the possible > > options (expanding the box to include > > all of them so that no scrollbar is > > required). > > > > <h:selectone_menu> Display as a combo box (the traditional > > HTML <select> element with > > size="1"). > > > > <h:selectone_radio> Display as a set of radio buttons and > > corresponding labels. > > > > Note that the application developer doesn't know or care which > > mechanism was used to display this component -- that's up to the > > page author, who will pick the desired representation by virtue of > > which tag he or she selects (at the Java API level, you make this > > choice by setting the "rendererType" property on the component > > instance). This is one of the many advances that JSF provides over > > Struts tags, where there is one and only one way to render each > > individual element. > > > > There are also provisions for creating more complex components like > > grids, tree controls, and the like -- a common theme you will see is > > "compose complex things out of little things" -- that is > > accomplished in JSP by nesting component tags inside each other, > > just like you nest HTML <input> > > elements inside a <form> element. > > > > For more information about JavaServer Faces, and an early access > > draft of the specification (and an early access version of the RI > > that corresponds > > to an even earlier draft of the spec), you'll want to bookmark: > > > > http://java.sun.com/j2ee/javaserverfaces/ > > > > In addition, there is a forum on the Java Developer Connection (free > > registration required) focused on JavaServer Faces, so please ask > > your general Faces-related questions there instead of here. Here's > > a direct link to the forum page: > > > > http://forums.java.sun.com/forum.jsp?forum=427 > > > > Note that JavaServer Faces depends on Servlet 2.3 and JSP 1.2 (i.e. > > J2EE 1.3 containers). > > > > > > HOW DOES THIS AFFECT STRUTS? > > =========================== > > > > At first glance, the low level components sound a lot like the > > struts-html tag library that Struts users know and love. Indeed, > > there is a very substantial amount of overlap. So, what's going to > > happen? > > > > In my JavaOne BOF on Struts (March, 2002), I made the statement that > > Struts would have a very clean integration with JSF, so that you can > > use JSF components in your user interface, but continue to use the > > controller, Actions, and associated business logic. Indeed, I > > stated that it will be > > possible to transition your application from using Struts HTML tags to > > using Faces component tags, one page at a time -- in most cases, with > > zero > > changes to the business logic or Action classes and minimal changes to > > the > > <forward> elements in your struts-config.xml configuration file. > > > > Along with developing JavaServer Faces itself (I am the > > specification lead for JSR-127), I have been working on just such an > > integration library for > > Struts (1.1 only; sorry in advance to 1.0 users). While not completed > > yet, it is clear that the goals stated in the previous paragraph are > > achieveable with the current evolving design of JSF. While things can > > always change in the future, many JSR-127 expert group members consider > > high quality integration with Struts to be an important success factor > > for > > JavaServer Faces to be accepted. Therefore, I do not expect that JSF > > will > > evolve in ways that make this kind of integration difficult or > > impossible. > > > > >From the developer's perspective, you will need to do only the > following > > to start using JSF components in your pages: > > > > * Add a new struts-faces.jar file, and the JAR files for an > > appropriate JSF implementation, to your /WEB-INF/lib directory. > > I admit that I mistook some of your words. Now I'm clear on the fact that struts-faces.jar is an adaptor for struts and JSF to co-work. > > * Note that JSF and the JSP Standard Tag Library (JSTL) interoperate > > very nicely, so you will also be able to use JSTL tags in your > > new pages if you wish to. > > > > * Add a couple of elements to your web.xml deployment descriptor, > > corresponding to the requirements outlined in Chapter 9 of the > > JSF specification. > > > > * Transition one page at a time to use the new tag libraries, > > making an appropriate modification to the <forward> elements > > for your pages (the URL needs to change to meet Faces > > requirements). > > > > The integration library will be available as a separately packaged > > download that runs with Struts 1.1, and will include a converted > > copy of the canonical struts-example web application so that you can > > see exactly what had to change in order to use Struts with JSF. > > > > Besides the integration classes themselves (primarily an > > implementation of the JSF ApplicationHandler API), the library will > > include some Struts-flavored components and renderers that provide > > functionality similar to that provided by the existing struts-html > > tags, when this is not provided by the standard JSF components. For > > example, there will be a > > Struts version of the UIForm component that accepts an "action" > > attribute > > that looks up the corresponding action mapping, and creates the form > > bean > > as needed, just like the <html:form> tag does today. > > > > The good news -- development of this integration library is well > > under way. > > > > The bad news -- you can't see it quite yet. This is primarily > > because it relies on changes to JSF that have occurred since the > > early access release > > of the RI was published, so you wouldn't be able to use it anyway. > > However, as soon as it is feasible, this library will be added to the > > "contrib" folder of Struts, with the sources (and downloadable > > distributions) available under the usual Apache license terms. (The > > source code will also give you a head start at creating your own JSF > > components, too). > > I'm sorry, but actually the above part confused me to think of struts-faces.jar as a JSF implementation because it seemed to take a role of demonstrating JSF component creation. Now I fully understand what you mean as you've written. > > > > SO WHAT USER INTERFACE TECHNOLOGY SHOULD I CHOOSE? > > ================================================= > > > > Everyone's functionality and schedule requirements are different. > > However, the following points summarize my basic recommendations and > > thoughts about the future: > > > > * If you have existing Struts-based applications that use the existing > > HTML tag library, feel free to continue to use them if you wish. > > Struts 1.1 offers full support for this existing functionality. > > > > * Once the integration library becomes available, you should do some > > experimenting and prototyping to determine the effort required to > > migrate your apps to the new JSF component architecture (I'm betting > > that the extra functionality you gain by doing this will be well > > worth the effort in many cases). As described above, the actual > > migration can be done piecemeal -- it doesn't need to happen all > > at once. > > > > * For applications now (or about to be) under development that have > > relatively short term schedules (i.e. the next few months), you > > should probably stick with the existing HTML library. > > > > * For applications with a longer lead time, seriously consider waiting > > for the ability to use JSF components instead of the Struts HTML > > tag library. Doing this will let you leverage not only the standard > > HTML components that come with JSF out of the box, but also the rich > > libraries of JSF components likely to be created by third parties in > > the future (including Struts developers). > > > > For Struts after 1.1 is released, the developers haven't yet had > > formal conversations (which will happen on STRUTS-DEV) about what a > > future Struts will look like. However, I'm going to continue to > > advocate a long term migration to using standards like JSF and JSTL > > when they are available, and de-emphasize the further development of > > the Struts proprietary tag libraries. > > > > The Struts tag libraries have had a tremendous positive impact on > > the development of the standard Java APIs for user interfaces. I > > joked with the JSTL spec lead that Struts users would *never* accept > > JSTL without an expression language at least as powerful as the > > Struts one; and there is more than a little truth to that statement > > :-). The same thing is happening now for the HTML tags -- and it's > > time for us to start migrating > > to the standards, which gives us the time to focus on extending Struts > > in > > other directions in the future. > > > > Comments? Questions? If it's about Struts, or Struts/JSF > > integration, feel free to ask about these issues on STRUTS-DEV or > > STRUTS-USER (although I'm going to be relatively incommunicado over > > the next week; I'll be in Yokohama at JavaOne Japan and only > > intermittently connected to email). Questions about JSF itself > > should be addressed to the JSF forum at the URL > > listed above. > > > > And thanks to all of you for your continued support and use of > > Struts -- the community that has developed around this framework > > continues to amaze and humble me. > > > > Craig McClanahan > > > > > > > > > Still I have a few things to write. Please look at the below stack diagram. JSF implementation ------------------- Struts-faces.jar ----------------- Struts -------- Servlet If someone likes to develop a JSF-based web application accompanying with struts, he or she needs somehow a JSF implementation, which is not in struts area currently. Does it imply that from time being Jakarta project have no plan to deliver a JSF implementation and says "always chances are open"? If we want a JSF implementation from Jakarta, must we propose a new subproject or wait for someone to do so? Is there any possibility for Jakarta to bring JSF RI like Tomcat for Servlet and JSP? IAS Independent Java Technology Evangelist http://www.iasandcb.pe.kr Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org IAS Independent Java Technology Evangelist http://www.iasandcb.pe.kr Jakarta Seoul Project Coordinator http://jakarta.apache-korea.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
