On 12/5/05, Preston CRAWFORD <[EMAIL PROTECTED]> wrote: > > I think that's part of the confusion, though. > > Correct me if I'm wrong, but this is how I see it after this > discussion. > > Struts = Legacy Struts 1.2.x - Action based architecture > Struts Shale = Framework that leans on JSF and has a compatability > layer written so it can support 1.x Struts apps > > See the confusion?
It's really very simple. The Struts brand is expanding to cover more technologies than just the original action-oriented framework. Note -- in order to avoid confusion, though, please listen to what the Struts *committers* are saying, and doing. There are lots of off the wall comments on this thread (and others like it) that represent personal opinions about what is happening, versus what the committers have agreed to and are actually doing. #1 - If there is a 1.x compatability layer (keep in mind that I'm > trying to think as a CIO type decision maker, less technical, more > concerned about where the market is headed for both tools and > developers) why would I ever choose Struts classic once Struts Shale is > out? Struts Shale can do component AND action based development. Why > bother with core Struts. For new development, that will be a very interesting question -- but even if you believe component oriented development is the future (and I'm in that camp as a general principle), you still need to be in a position to train up your team if they are not JSF-savvy yet. And you still need to ensure that a component based solution supports all the other functionality you might be plugging in today (security, validation, layout, whatever) before you can jump to it. However, there are lots and lots and LOTS of existing applications based on Struts 1.x. The owners of those apps (and it sounds like you're one of the thousands of people in that position) have to be caring about how they are going to maintain and evolve those apps in the future, knowing that it's virtually impossible for schedules and budgets to allow a complete rewrite onto a new technology, even if that new technology was the greatest thing since sliced bread. The next generation technology that provides forward *migration* for these apps, without forcing a complete rewrite, is going to have a huge head start on market acceptance, totally independent of technological merits. The Struts Action Framework guys should have an easier time of this, but if they don't make it a high priority then the component oriented guys will have time to create a graceful migration solution first :-). #2 - What does it mean that Shale (which is really not action based) > branded with the Struts brand which IS action based, but is being phased > out? What's being phased out? Struts 1.x is being evolved to add capabilities and simplify development. >From a marketing perspective it's a bit untidy. It would be better if > Shale were it's own project, not tied to the Struts name and Struts core > was allowed to ride off into the Sunset. This would be less confusing to > the business decision maker, I believe. What it means is that all the effort you went to to get your management to buy into the radical idea of depending on a bunch of open source developers for key infrastructure just paid off big time. Now, that same group of developers (already on your IT department's approved list) are bringing you some additional technology that you can bring to bear on additional problems -- without having to go through the effort to qualify another vendor. Preston Craig (PS: happy to be a resident of Oregon, by the way :-)
