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]
