You know, I can't believe I'm about to say this given some of the comments I've made in the past, but here goes anyway...
I think the compatibility later is almost pointless and maybe the effort isn't worth it. The reason I say this is that many people have the opinion that Struts is old news and needs to evolve. Many people also believe it is already pretty far behind the times. When situations like that arise, it is often best to simply start charting the new territory without concern for supporting the old. Now, I don't mean drop support for Struts 1.x... as others have said, 1.x isn't going anywhere and there are people willing to continue to support it and even evolve it, me included. What I'm asking is if there really is any good reason to make Struts Ti compatible with the 1.x world, or is it time for a whole new world? Shale was, and I presume still is, suggested as a possible Struts 2.0 direction. People are willing to accept that as a possibility, and there's no promise, that I'm aware of anyway, of a Strtus 1.x app ever being able to run under Shale. And what would be the point of even trying to allow for that? I'd would suggest none. People with existing 1.x applications aren't too likely to upgrade to Ti anyway. Some will of course, but by and large I'd say it won't be a common occurance. It's the *new* projects that will or will not latch on to it, and they won't have a compatibility concern. But if Struts Ti is going to be a relatively big departure from what Struts is now, and it sounds like that might be the case, and given that 1.x isn't going anywhere, is there really a point to a compatibility later? Further, might it even hurt the cause to some degree? Now, it sounds like Don has a relatively easy way to accomplish it, and if that's true than that fact takes a bit of the wind out of my comment here. I mean, if a compatibility layer isn't a big deal to implement, then there's obviously no *harm* in doing it. But still, I wonder if it might not be better to simply offer people a (potentially) incompatible choice, much like they have now when choosing between Struts and JSF... the integration library notwithstanding, they really are two fundamentally different, competing views on web development. And that's OK, it's a choice. I'm starting to think that maybe the best course for Struts is one where 1.x is allowed to continue to evolve, to the extent the community supports and contributes to it, and Struts Ti goes off, without worrying about compatibility, and just tries to be as good as it can be. I don't know, I'm just tossing out some thoughts here. I'm not sure I completely agree with myself :) Just some talking points I guess. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Fri, December 2, 2005 1:00 pm, Pilgrim, Peter said: > >> -----Original Message----- >> From: Don Brown [mailto:[EMAIL PROTECTED] > ==////== >> >> >> 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. >> > > I have been at at three investment banks in London where I > build Struts applications. I think that these applications > will not be radically changed in the future regarding > moving from Struts to another web framework e.g Spring MVC, Tapestry > or JSF. > > What I do envision is that they may be refactored, particular > if the underlying framework makes it easier? > > I think Don's Struts compatibility layer will make or break > the adoption. If it is a very good piece of engineering > that makes it easier to enhance, develop, and more importantly > maintain Struts application, then that would be a big seller. > > On the otherhand if the layer is piecemeal, and there no obvious > quick win here and there. For example you still have to fight > with code and javascript all over the place, and base actions > and action forms, and you have to set validation manually, > and incorporate application resources, download > ApplicationResources.properties > with `error.required' from the net, then I can see it wont > work very well. > > I am not saying that it should be Ruby on Rails with active > database dynamic records, but it could be a lot be easier > for developer to get a basic web application up and running, > but still have extensibility. One of the secrets of Struts > wide adoption is that it didn't try to be the jack of all spades > and stuck cooly to MVC Model2. Now it has to grow with the > trend for metaprogramming, which is not as easier to do > with Java as it is with other languages. > >> 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. > > > > -- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
