David - I was going to give a run through on Shale at the Struts London
Meetup <http://struts.meetup.com/4/> on the 15th I appreciate you may
not be able to make it but I'll post the sides up somewhere after the
event and push that into the Wiki.
Duncan Mills
http://www.groundside.com/blog
David G. Friedman wrote:
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:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 1:31 AM
To: [EMAIL PROTECTED]
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
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
