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: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: "Alan Mehio" <alan_mehio@yahoo.co.uk>
To: "Struts Developers List" <dev@struts.apache.org>,
	"Sean Schofield" <sean.schofield@gmail.com>
Subject: RE: 1.3 and ActionForm
Date: Mon, 10 Jan 2005 20:46:30 -0000
Message-ID: <JPEEJGAMGAGCOICIMFILOEKACEAA.alan_mehio@yahoo.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <2387fbc5050110092727f8f80e@mail.gmail.com>
Importance: Normal

The other way I see it is that, we are moving from dealing with HTML pages
into pure java coding with very clean architecture and separation of tiers.
All done in Java. Silver Stream Application server has the property to
generate client listener and so on. Now we have complete tools all done in
java.


> -----Original Message-----
> From: Sean Schofield [mailto:sean.schofield@gmail.com]
> Sent: 10 January 2005 17:27
> To: Struts Developers List; craigmcc@apache.org
> Subject: Re: 1.3 and ActionForm
>
>
> One way to look at the whole Struts vs. JSF issue is to think about it
> in terms of architecture and maintenance.  There are a lot of JSF
> features that one could easily respond to by saying "Yes, well Struts
> has that too."  This was my first reaction and the brand new stuff
> will obviously draw the most initial interest.
>
> As Craig has pointed out in the last post there are lots of
> similarities.  Even though there are some cases where JSF features are
> similar, I have found that they are often implemented in a superior
> fashion.  No suprise here as the JSF group was able to draw on lessons
> learned from Struts (and other frameworks.)
>
> One new feature that I love is the value change event.  This was
> something that I really needed in my struts apps.  When writing a
> webapp that is more "app" than "web" you're not just filling out forms
> and updating shopping carts.  Sometimes you'd really like to know when
> field x has changed.  In Struts I had to basically had to stored
> cloned copies of my beans in the form because I wanted to know which
> fields had changed and what the previous and new values were.
>
> Now in JSF, you just have to use the value change event.  No more
> implementing cloneable for every freakin bean (and member bean.)  Nice
> elegant solution.  The more stuff in JSF that I find like this, the
> closer I move towards implementing the next app w/faces (or Shale)
> instead of Struts.
>
> Anyways, that's just another way of looking at it.
>
> sean
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


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