On Tue, 01 Feb 2005 11:09:22 -0800, Michael Oliver wrote: > Well Ted, Craig certainly wasn't singing that tune, although that > doesn't mean you are wrong either.
Craig believes that Shale is the best way to write new web applications for Java. And he may be right. But, I don't think Craig is suggesting that thousands and thousands of teams all over the world should stop everything and migrate perfectly good Struts applications to Shale. :) For the past five years, we've been saying that Struts and MVC are cost-effective because it makes web applications cheaper to *maintain*. Now, that so many of us have our application in cheap maintenance mode, it would be silly to suggest people are suppose to fix things that aren't broken. Just because Shale might be a better way to write *new* applications, it doesn't mean existing applications are suddenly obsolete. Obsolete means it would be cheaper to rewrite it than to maintain it. I doubt that anyone is suggesting that it would be cheaper to rewrite a stable application in Shale rather than maintain it in Struts. If a poorly-written Struts 1.x application were due for a major upgrade, sure, *someday* it might be cheaper to rewrite in Shale. But a well-written Struts 1.x application is still going to enjoy a long lifecycle. And, probably several upgrades, as there is worked planned for Struts 1.3, 1.4, 1.5, 1.6, and so on. :) [http://struts.apache.org/milestones.html] > As you and I discussed back when we tried to solve the problem of > opening existing Struts applications to Axis/SOAP with Axis4Struts > so a SOAP Actor can be just another View into Struts Applications, > it would seem natural for Shale to have at least some vestige of > interoperability, be that some interfaces or some "gateway" > Actions, so the baby of existing production Struts Applications can > take advantage of JSF/Shale without being thrown out with the > bathwater. Web platforms are very flexible, and Java platforms doubly so. I've mixed and matched workflows with things like Struts and Maverick, and I'm sure you could do them with Struts and Shale too. Or Shale and Tapestry. Or name any combination of frameworks. :) Web services are a horse of a different color. But, as far as mixing-and-matching web frameworks goes, it would not sound like a good long term solution. The key advantages of Shale are best realized by new development. But, since Shale is unreleased software, the better place to discuss such things would be the dev@ list. -Ted. > > Michael Oliver > CTO > Alarius Systems LLC > 3325 N. Nellis Blvd, #1 > Las Vegas, NV 89115 > Phone:(702)643-7425 > Fax:(520)844-1036 > *Note new email changed from [EMAIL PROTECTED] > > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 01, 2005 10:41 AM > To: Struts Users Mailing List > Subject: Re: Shale <--> Struts 1.n > > On Tue, 01 Feb 2005 09:44:43 -0800, Michael Oliver wrote: > >> What are the plans for migration and/or interoperation for Shale >> and Struts 1.n? >> > > There's been some talk on the dev list about using both frameworks > together, on a temporary basis, but it's not recommended. > > It's a lot like asking what are "our plans for migration and/or > interoperation for Tapestry and Struts 1.n?" > > They are two different frameworks, and there really isn't much > reason for them to interoperate. > > Eventually, after Struts Shale ships, I'm sure people who migrate > applications from other frameworks will beat a path and document > some tips. > > But, right now, Shale is seen as a tool for new development for > teams standardizing on JavaSererFaces, not as a successor to Struts > 1.x. > > Like everyone else, most of the committers have significant Struts > 1.x applications in production and see no reason to migrate them > anytime soon. > > -Ted. > >> Michael Oliver >> CTO >> Alarius Systems LLC >> 3325 N. Nellis Blvd, #1 >> Las Vegas, NV 89115 >> Phone:(702)643-7425 >> Fax:(520)844-1036 >> *Note new email changed from [EMAIL PROTECTED] >> >> >> ------------------------------------------------------------------ >> -- - 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] > > > -------------------------------------------------------------------- > - 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]
