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.
>
> * 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]>
