For what it is worth: After looking at the actual code examples vs the early rumors and speculations and my jumping to conclusions, I found MUCH to like about the actual JSF samples posted in Developers Connection Early Release.
My apologies for the prior flame posts! basicPortal for one will deprace the the html tag in favor of the h tag asap (it already does not use logic or bean tags in favor of JSTL). Again, please allow me to reverse 180, I found much to like in JSF samples, and will try to be an early adapter and have a few early clients on it (some of my clients have VERY large # of concurrent users, much more than 10,000 concurrent users on Struts). We should have a JSF with DAO example very soon on sourceForge. Vic (I am curios about multi row updates, multi row validation, I warped my beans with collections in past to get MasterDetail working; Also, I wish validation was in the bean, since bean could be used by services, SOAP, etc. and you want client side validation outside of JSP, but.... let me shut up, but I can hardly wait for the Struts-JSF jar) > 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. > > * 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). > > > 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
