myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: MyFaces+Struts+StrutsFaves -- again giving it a try!!
Date Tue, 30 Nov 2004 18:00:28 GMT
On Tue, 30 Nov 2004 09:38:17 -0800 (PST), No Galz <anshulpatni@yahoo.com> wrote:
> Hii Craig,
> 
> Thanks for your response and clarification.
> 
> I agree that the Struts-Faces library uses JSF URLs
> and for make them into use in my application, i need
> to change the handling.

Yep.

> 
> But, I have a very dull feeling about using
> Struts+Faces together. Moreover things are not going
> fine together with different implementations.

That's mostly a matter of ironing out bugs, not architectural
incompatibility.  I just wanted to set expectations correctly.

> Just for
> curiosity, How Shale is going to make use of JSF in
> View?? Isn't it be the same way?

Background on "Shale" for those not familiar with the term:

  http://wiki.apache.org/struts/StrutsShale

The use of JSF in Shale, versus the Struts-Faces library approach, is
very similar in the view tier (i.e. JSP pages or whatever) -- its the
rest of your code that is different.

Struts-Faces allows an existing Struts-based app, that has been using
the Struts HTML tags, to migrate (one JSP page at a time if desired),
to using the more capable and sophisticated JSF components that are
becoming available.  It accomplishes this task by putting the JSF
front controller "in front of" the Struts front controller.  That way,
JSF handles user interface events (like a tree control node being
opened or closed), but passes form submit events on to Struts, to be
handled by the traditional Struts request processor.  So, all your
back end stuff (form beans, actions, and so on) can continue to be
used unchanged.

Shale, on the other hand, adopts JSF's front controller as its basic
architecture, and encourages a "view helper" design pattern for your
server side Java code.  For application wide things that Struts 1.x
would do in the request processing pipeline, you can use servlet
filters (which we couldn't in Struts 1.0-1.2, because we wanted to
maintain the availability on a servlet 2.2 platform).

A JSP page with JSF components in it, then, will look almost the same
when using either Struts 1.x + Struts-Faces, or when using Shale. 
Where Shale helps improve usability, though, is that it reduces the
amount of configuration data you need to supply, and combines the form
bean, a setup action, and a processing action (the typical Struts
pattern for pretty much any transaction) into a single class with very
simple method signatures -- so simple, in fact, that it's very easy to
unit test them.

You can actually see how this all looks in code, because the canonical
Struts "mail reader" application has been implemented in each of the
two ways.  Nightly builds are available at:

  http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/

  http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/

> 
> Regards
> fargo
> 

Craig

Mime
View raw message