[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-user
Subject:    Re: struts-faces
From:       "Craig R. McClanahan" <craigmcc () apache ! org>
Date:       2003-09-16 19:30:57
[Download RAW message or body]

On Tue, 16 Sep 2003, Sasha Borodin wrote:

> Date: Tue, 16 Sep 2003 12:35:22 -0500
> From: Sasha Borodin <sasha@whoissasha.com>
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> Subject: Re: struts-faces
>
> Thanks Craig.
>
> > You can, but the integration library lets you use Struts Actions on the
> > back end, creates form beans automatically, and so on.
>
> Reading through Sun's Web Services Tutorial section on JSF, things are
> starting to come into focus:  JSF provides functionality that overlaps that
> of Struts (my misconception was that JSF was strictly a UI component tag
> library).
>

Yep ... there's quite a bit of overlap, and JavaServer Faces is FAR more
than "a component tag library".

> .: Anyone know of a resource that summarizes/contrasts solutions provided by
> both frameworks?
>

I'll throw in a few short comments below, but caution you that this is
based on the EA4 release of JavaServer Faces.  Things are still evolving
rapidly.  (My comments ought to have at least a *little* relevance,
because I'm both the original author of Struts and the co-spec-lead for
JavaServer Faces :-).

> i.e.:
>     -UI Components

Struts doesn't really have any notion of components at all (the closest
thing is properties of a form bean), while JavaServer Faces has a fairly
rich component model that is accessible at both the Java and JSP levels
(JSP is not required), supports a separate rendering model (so you can
render something like a "select one" control as either a set of radio
buttons or a <select> element with one simple change) and is not tied to
HTML -- although the default render kit included will be HTML specific.
Out of the box, you'll get complex components like a grid and an editable
table, and there are already demonstration components for things like
trees and menus that (in a Struts world) require additional add-on tag
libraries.

For people who have existing Struts expertise and/or applications, this is
the key value add of integrating JavaServer Faces -- you can use the fancy
UI component model without having to change your back-end form beans or
actions.

>     -controller components

This is where Struts shines, and I assume you're familiar with that.
JavaServer Faces uses a somewhat different abstraction for navigation, and
defers the decision of what page to display next to a NavigationHandler
that is configured with a set of rules -- the next page is determined by
matching rules for:
* The page that is currently being displayed
* Which Action was invoked (for example, you can have
  multiple submit buttons on the page that do different things)
* Which logical "outcome" was returned by the Action that
  was invoked -- sort of like how Struts actions return an
  ActionForward.

JavaServer Faces is more flexible in how you organize your processing
logic -- you can maintain a Struts-like model of separate "form beans" and
"action classes", or you can combine them together (somewhat like how
code-behind pages work in ASP.Net).

Struts has a couple of framework features (Tiles and the Validator
Framework) that are beyond the current scope of JavaServer Faces -- but
one advantage of the integration library is that you'll be able to use
these sorts of technologies together.

>     -model components

Being presentation frameworks, both technologies are mostly focused on the
view and controller.  The important part becomes how the presentation tier
and model tier object communicate values:

* With Struts, you can use property expressions to navigate
  down a bean hierarchy -- something like:

    <bean:write name="customer" property="address.city"/>

* With JavaServer Faces, this is done with "value reference
  expressions" that use the same syntax as JSTL EL expressions.
  The equivalent tag to output a bean property would be:

    <h:output_text valueRef="customer.address.city"/>:

* In both technologies, it's possible to evaluate expressions
  like this programmatically in your Java code -- with Struts,
  you use the commons-beanutils package; with JavaServer Faces,
  you use the ValueBinding API.

* With Struts, the framework will automatically create form bean
  instances for you if you want.  If you're using DynaActionForms,
  you can also preconfigure the properties of the created form bean
  using the "initial" attribute.

* With JavaServer Faces, this concept is extended to support creation
  of *any* model tier bean (in any scope), complete with configuring
  the initial properties, using the Managed Bean Creation facility.
  In the example above, I can configure things such that if the "customer"
  object does not already exist, a new instance of a configured class
  will automatically be created, and have its property values also
  configured based on settings in faces-config.xml.

>     -Page Flow

Neither technology has direct support for page flows.  There are add-ons
for Struts already; I have no doubt that such things will emerge for
JavaServer Faces as well.

>     -etc.

Because Struts is a fairly popular technology, you'll find quite a lot of
support for it in development tools.  I expect to see the same sort of
thing happen for JavaServer Faces; indeed, at JavaOne this year both Sun
and Oracle did keynote previews of their upcoming development tools that
will be based on JavaServer Faces, and lots of other providers have
promised support for it as well.

>
> Thanks,
>
> -Sasha

Craig McClanahan

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]