Yep. Quite interesting. Sorry if its a bit rambling - dont have time to edit it - but heres my 2 cents worth:
The article doesnt mention it but Scioworks is the company behind Camino , a powerful RAD tool for struts so its a good bet to say that he certainly knows the technology and the area quite well (unlike many commentators). Id have to say I agree with the opinion to a certain extent - though in my view 3 years is a very long time in IT! ;-) JSF scratches many of the same itches as struts, only better, and given that Craig is spec lead for JSF thats hardly a coincidence. Perhaps we could consider struts the practice run? ;-) Craig & co. say that there will be a future for struts in the JSF generation, but Im not sure I fully grok what that future is yet (havent had a chance to play with the jsf struts integrated stuff yet) but at the least it should involve an upgrade path for existing struts stuff? I dont really see what the fuss about 'protecting investment' is - its not like struts is rocket science to work with and unlike commercial products you've always got the source to look at if the docs arent clear enough! If the product your maintaining uses struts its still going to be a hell of a lot easier to maintain than one that went with a model 1 approach. After all, when struts was created there simply wasnt a suitable webapp framework standard to plug the gap between the low level servlet api stuff and higher level application oriented patterns, and if we extrapolate from this to other new areas where opensource is paving the way, are we to say that managers shouldnt use such opensource initiatives because they dont comply to standards that have yet to be drafted? What then? Homebrew frameworks? - if its early in the technology these may be the best way of meeting your needs while opensource efforts mature - but usually thats not the case. Ignore the new area till someone comes up with a standard framework? Not really an option given commericial pressures. At the end of the day its a case of going with whatever framework is available and choosing the one that will cost you the least and give you the most mileage. In hindsight for J2EE webapps that would be struts, and even right this second it would still be struts. JSF isnt ready for general use yet - so unless you want to delay your project till it is what are you going to do? The answer of course is to choose a framework that will give you the easiest upgrade path as new standards come along. A framework that quickly moves to support standards as they emerge. In the webapp arena this is of course struts - and in the past the upgrade path has always been there - for jstl there were both the struts-el library and of course the fact the jstl and struts play very nice with each other. With JSF I believe that whats been done to integrate struts and JSF will provide a good path. The next (or soon after) version of struts will I gather also play nice with the portlet spec, etc... Basically what the article is saying is that these are the issues that managers need to consider carefully. Its certainly not saying dont go with struts/opensource, but rather saying that one day they may be obsolete - but its not like theres a real alternative - so pick the one that looks like its going to cost you the least in the long term! To quote: <snip> Am I suggesting shunning those open-source projects? Not at all. These are solutions you can deliver now, and the lack of support may happen in the future. I believe the value gained from using these open-source technologies outweighs the risk. </snip> -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 1 October 2003 22:09 To: Struts Users Mailing List Subject: Editorial on Struts' Long Term Future You may find this editorial on J2EE/JSF/Struts interesting. http://www.sdtimes.com/opinions/guestview_087.htm --------------------------------------------------------------------- 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]
