> -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: 05 December 2005 12:55 > To: Struts Users Mailing List > Subject: Re: [FRIDAY] Struts 1.x is Struts Classic after all > > > On 12/3/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > > Ted Husted on 02/12/05 04:29, wrote: > > > We have two because JSF is fundamentally incompatible with > > > action-orientated frameworks. (As stated on the Struts home page.) > > > But, that will not be the case for Ti. We plan to create > a clear and > > > relatively painless migration path, so that investments > in skill sets > > > and working code will be retained. (Including our own.) > > > > There is nothing preventing Struts X.x offering both 'incompatible' > > frameworks. Struts 1.x, the 'action'-based framework and other > > 'component'-based frameworks are composed of perhaps code that is or > > could be 75% 'action' or 'component'-agnostic. > > We are already sharing the the "agnostic" code via Commons components > that both Action and Shale use. After we extracted the Commons > componetns in the 1.1 era, all that's really left in Struts Action is > code that overlaps with JavaServer Faces. Since Shale leverages > JavaServer Faces and Commons, there's very little left that the > frameworks could share. And, if we found something they could share, > I'm sure it would quickly be moved to the Commons or to its own > subproject (witness Tiles). > > > > > Why burn bridges? It would be better to incorporate to cut down the > > central component of the struts action and move all > agnostic material to > > the side, pretty much as Shale is now. > > > > At that point Struts could then incorporate a 'component'-based > > framework module to match the action-based framework. > > > > Don't forget, 'Struts' means 'A structural element used to brace or > > strengthen a framework [...]' not 'foundation stone'. > > Yes, we've aggressively moved the Action foundation classes to the > Commons. What's left here is glue code that connects the Digester with > Bean and Collection and Chain, and cobbles together Action-specific > ideas like the Request Processor.
A lot of the code has migrated from the ActionServlet to the RequestProcessor and then onto Commons Actions in 1.3.0. The interesting thing in the future will this work make programming action-oriented frameworks easier and better or actually worse? I get the feeling that it will be better because actions or commands will be more coarse grain, and most of the business database code can be transfered out of actions to the data layer. The data layer can itself be composed of it's own chain of commands. > > Struts has always been about providing the glue, or "struts", between > existing standards. And, unsurprisingly, that's exactly what Shale is > trying to do. AFAICT, Shale is about as Struts-like as JSF can get. At > least without sacrificing the intent of the JSF architecture. > > Meanwhile, the great thing about WebWork is that our communities have > the same perspective. WebWork integrates several foundation packages, > like XWork, OGNL, and FreeMarker, into a coherent framework that any > Struts developer will find familiar. (Especially if you've been > tinkering with 1.3.) > > IMHO, I don't see the engineering value-add of a "one size fits all" > framework. A framework is a semi-complete application, and action/page > applications are built differently than event/component frameworks. > Since the applications are different, the frameworks should be > different too. IMHO what attracted lots of developers to Struts was it was pretty focused already. It did one thing very well, a model 2 blueprint MVC framework for Java. It was a also lightweight enough for other to embed it in a bigger valid-add framework, e.g Expresso, or supply additional valid-add extensions Tiles, Workflow, et etc. The problem is always trying to anticipate change and innovation, keeping an implementation robust and solid, but providing enough abstracts and interfaces to allow flexibility. Struts was never perfect in the first place, so it could never taken as one size fits all. Richard Oberg took what Struts and fixed some of the architecture critism with Struts for his own framework, WebWork 1.x. In fact Rod Johnson in first EJB Expert book had a right-go (severe critique) at Struts, and attacked the fact that ActionForm was not an interface, and that Action was not an interface. It is good thing to fix Struts architectural problems. The second problem is that of productivity. Struts 2.x, I feel, much bring some productivity gains for web developers, as Rick Reuman bemoaned, in order to get it to the next level. > > Some people in our community want to dive into JavaServer Faces, and > others want to pursue the tried-and-true action-orientated approach. > Rather than burn bridges, we're built a bigger roof :) > Yep There are two web application architecture out there co-existing and competing 1) Component-Oriented 2) Action-Oriented If you can bridge these two then you're probably onto a winner, but it is very unlikely ==////== -- Peter Pilgrim :: J2EE Software Development Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
