Does anyone (I mean "anyone") believe that Shale is a potential future. Don't even its most avid advocates see it as a temporary transition to some JSF deal?
On 12/2/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
