Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
From: "David G. Friedman" <humble@ix.netcom.com>
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: RE: Here's a question for yous...
Date: Tue, 1 Mar 2005 08:51:43 -0500
Message-ID: <OJEDJMPOKIPEHGNAFOPJOEEFFCAA.humble@ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <f8b39ace05022822312b493ab4@mail.gmail.com>
Importance: Normal

Craig,

Is there a tutorial or walk-through explaining Shale?  I didn't see that in
the nightly download.  I have no clue about JSF and skimming through the
Shale code made little sense to me (at this time).  I.E. Conceptually, I'm
interested but programmatically, it's still over my head for some reason (I
could just be in the wrong place whenever I go look at it).

Regards,
David

-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@gmail.com]
Sent: Tuesday, March 01, 2005 1:31 AM
To: fzlists@omnytex.com
Cc: Struts Users Mailing List
Subject: Re: Here's a question for yous...


On Tue, 01 Mar 2005 00:52:07 -0500, Frank W. Zammetti
<fzlists@omnytex.com> wrote:

> I sometimes wonder if we (the generic we I mean) don't sometimes think
> at too high a level... We try to build so much flexibility into our
> designs, but every time I hear "a new API" or "a new interface" or
> "another abstraction layer" or any of those somewhat similar terms (you
> know, the ones spewed forth by enterprise architects ad nauseum!), I
> wonder if the cost of the added flexibility isn't too high in terms of
> overall complexity.

I can appreciate that feeling.  That's why Shale is focused on
(compared to something like classic Struts) *reducing* the number of
abstractions you have to care about:

* No more configuration beans (so developers can configure properties
  on the equivalent of an <action> and have it do what they really
expected).

* No more form beans (JSF takes care of the reason form beans exist in the
  first place, but lets go further and combine the "form bean" and "action"
  concepts in a thread safe request-scope object, like WebWork does it,
  as well as take advantage of JSF's support for a basic IoC framework
  using the setter injection pattern).

* No more RequestProcessor or corresponding Chain implementation (the
  application developer should think solely about responding to view tier
  events, not how their code fits in to the "big picture".

Of course, there are still use cases where you need traditional "every
request flows through this pipe" sorts of control.  But the current
servlet API provides that for us (javax.servlet.Filter) -- there is no
longer any reason for an application framework to reinvent that sort
of thing.

Craig

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


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