+1 on Don's serious message below (API compatibility is the key), but in a somewhat more whimsical way in light of the [FRIDAY] prefix.
On 12/1/05, Don Brown <[EMAIL PROTECTED]> wrote: > > While you are certainly entitled to your opinion, I'd ask that you reserve > judgement until at least the first Struts Ti release. Yes, we plan to > seed > Struts Ti with WebWork 2.2, but that doesn't mean it will stay that way or > that Struts Action 1.x users and even code aren't important. I just > started > working on the Struts Action 1.x compatibility layer tonight so its too > early to say, but my goal is to be able to run most Struts Action > 1.xapplications unchanged on Struts Ti. Struts Ti was born with the > idea of > filling the gap between a new development frame of mind with JSF and > Struts > Action 1.x, providing Struts developers a powerful new framework that > leverages their Struts knowledge, not negates it. > > Furthermore, it has been said before and I'll say it again - Struts Action > 1.x isn't going anywhere. Just as development continued when Shale was > born, development will continue today. I have at least one major Struts > Action 1.x application myself that will never see a rewrite, so if for > some > reason Struts Ti doesn't have full Struts Action 1.x compatibility, it'll > stay on the stable, supported Struts Action 1.x. > > This is open source - if you are convinced Struts Action 1.x is the one > true > way, feel free to jump in and contribute. Just because Struts Ti may be > right for me, it may not be for you. > > Don > > On 12/1/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > > > Maybe I do not know how to do business. Heck, I do not have MBA. But > > for some reason I have a sour taste in the mouth. If > > StrutsTi/Struts2.0 is so heavily based on WebWork code that one did > > put an equal sign between the two, then Struts2.0 is not Struts > > anymore. It would be honest just to say that Struts ran out of steam, > > it is crusty, it sucks, its development is concluded and everyone is > > welcomed to switch to shiny WebWork. I would get that. I would accept > > that. At least I won't feel being fooled. > > > > In case of DaimlerChrysler one has an option to go and buy an original > > product. There is no such an option in Struts/WebWork case. How do you > > think you will explain to those who "know" that Struts sucks that > > Struts 2.0 is not Struts 1.x they knew (or actually did not know) > > before? Will you be telling them that this is actually WebWork, which > > is so much better? Now that would be fun. > > > > I have nothing against WebWork, I had looked into it once or twice, it > > is surely a nice framework, but I will not buy WebWork skinned as > > Struts. > > > > Michael. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > If I am a user of an API, my dependency on that API is primarily in terms of the interfaces and classes that I import, and the semantics of the methods I use. (Side note -- this is one of the issues that motivated me to call out which Shale APIs are *intended* to be used by application developers, versus those used only if you're planning on extending the functionality of the framework itself). For Struts 1.x, the vast majority of an application's dependencies are wrapped up in ActionForm and Action APIs. When Struts 1.0 came out, the logic of the request processor was embedded inside ActionServlet. In 1.1, we factored that out into a separate RequestProcessor class (so you could specialize it more easily, and to support the new feature of application submodues). But we didn't break the Action or ActionForm APIs (yes, we went from perform() to execute(), but 1.1still supported perform()). Was 1.1 still "Struts"? You bet it was. In 1.2, the internal changes were less dramatic, but still real. Is 1.2still "Struts"? Yep, for the same reason. In 1.3, the internal architecture is getting changed yet again, and even more radically, to allow very fine grained customizations of the request processing lifecycle. But, and this is critically important, Action and ActionForm *still* work. Yes, in each of these transitions, there has been a very small number of required changes (usually lagged by a release to give everyone time), but the fundamental code of a Struts 1.0 app that has been ported to 1.1/1.2/1.3 is still recognizable as a "Struts application". So, what's going to happen with Struts Applicaton Framework 2.0? As Don points out, it's too early to tell ... but I have a very high degree of confidence in the folks working on this that a robust compatibility layer can be created. That won't be the *only* way to build a SAF 2.0application, but again ... if a 1.0 "Struts appication" is still recognizable, and can still work with zero-to-minimal changes, then I'd say you are wasting your time looking under the covers to see if it's implemented the same as it used to be. Of course it's not! That's pretty much a given as long lived software evolves. But the fact that Struts has always stressed backwards compatibility of the key APIs as a fundamental principle is one of they key reasons that it has been successful. Indeed, I believe that this focus on backwards compatibility has been the single most important reason that Struts is as successful as it has been. Put another way, my application depends on a Duck API, with methods like drumstick() and bill() and foot() that do things for me. Am I going to care if the internal implementation morphs into a Goose instead of a Duck? Naw ... I might appreciate the fact that I have some additional choices now, but as long as the framework has modes that walk like a duck and talk like a duck, I'm going to be satisfied. Craig
