Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (hermes.apache.org: domain of craigmcc@gmail.com designates
 64.233.170.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=haqFpW3qLhr9JksMnj/QaQ1SKVwUTu7VcqQT/qPI04nFXVoYENv3IbWFfkOMhO2N9ea6Qzb8vwEWfFP3MbCFjZWoaMaAc+BS+fqXZwP7lihGUj2+zX+oJkmGP351FoXbxSRsNr4XAk1auvuOHal/oBH2ysTjSSY+rxR6IdUUzxg=
Message-ID: <f8b39ace041224071361fbe32f@mail.gmail.com>
Date: Fri, 24 Dec 2004 07:13:58 -0800
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: craigmcc@apache.org
To: Struts Developers List <dev@struts.apache.org>,
	Dakota Jack <dakota.jack@gmail.com>
Subject: Re: [struts-faces] JSF integration into Struts
In-Reply-To: <e030143004122322243a6ff880@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41CB2B17.1060603@twdata.org>
	 <e030143004122322243a6ff880@mail.gmail.com>

On Thu, 23 Dec 2004 22:24:28 -0800, Dakota Jack <dakota.jack@gmail.com> wrote:
> I think, Don, that this "integration" is a bit smoke and mirrors
> Really what the integration is, if I understand it right, is just a
> switch to use either JSF or Struts.  They really cannot work together
> because JSF has a page based controller which is inconsistent with
> everything Struts as we know does.

Sorry Jack, you don't have it right at all.  The current integration
library absolutely lets you use JSF components in an application based
on Struts 1.1 or 1.2.  Plus, far from being smoke and mirrors, the
code actually exists too -- unlike some proposed approaches :-).

  http://svn.apache.org/builds/struts/nightly/struts-faces/

Of course, this approach doesn't leverage anything of JSF other than
the visual components, but that's OK if it floats your boat.

Don's question was primarily around whether you put JSF in front of,
or behind, a flow-through controller (the page based part isn't really
the important issue -- the part about wanting to be in front, and
processing *all* requests first, is the key one).  The integration
library currently puts JSF in front (for user interface events only),
which I believe is the better architecture -- a particular request
penetrates into the system only as far as it makes sense.  There's no
reason, for example, for any business logic action to get involved in
a purely visual change like expanding or contracting a tree node. 
Putting JSF in front lets that happen; the current Struts architecture
doesn't.

As for the future, the queston that Struts 1.x developers need to ask
ourselves is "what's the value add of a flow-through controller" in a
JSF environment.  Others have already shown, for example, that you can
use Tiles and Commons Validator directly with JSF (without using the
Struts controller architecture) -- and these are capabilities I
already know how to integrate into Shale.  Servlet Filters let you do
all the overall per-request type things you might want to do; no extra
infrastructure is needed for overall control things like "is the user
logged in" checking.

It's also quite pleasant to be done with form beans (JSF components
already do the stuff we used to need them for); to have the logic to
set up a page and process it's input next to each other instead of in
two actions that have to be chained; to not need "configuration beans"
at all; to be able to manage multi-request dialogs more gracefully
(stay tuned for a Shale example next week); and to be able to use JSF
components from multiple libraries; but I digress ...

> 
> Jack
> 

Craig

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