struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Mills <duncan.mi...@oracle.com>
Subject Re: Here's a question for yous...
Date Thu, 03 Mar 2005 16:06:48 GMT
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: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
>
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message