There are some things that I certainly agree with michael on and this is one of them.
I think ( and i'm not alone in thinking this ) that struts needs a complete overhaul. At present the only reason I use it is because all the existing tooling supports it. eg m7 nitrox, WSAD, MyEclipse etc etc etc If the spring tooling was as mature as this I would use it instead. The project has a reputation for inflexibility, complexity and a lot of unnecessary inheritance. These are all hangovers from EJB with it's multiple interfaces and fixed inheritance approach with the associated difficulties of testing, slow development cycle etc. Struts has done a superb job in the past otherwise it wouldn't be so popular and there is a fantastic pool of talent in the struts development team but it does seem like you are loosing mind-share. If this were not the case there wouldn't be so many copy cat web MVC frameworks springing up. Perhaps it is time for an overhaul of struts. Rather than moving your codebase to subversion perhaps you should leave your 1.* development on CVS and start a completely new attempt for your 2.* series on a fresh server. I do think that struts is a great product and I am a big fan of it's tag libs and the MVC approach in general but I do think that it may be time for a rethink .... Everything is going POJO, attributes are the way forward. 1.5 will mean that collections are no longer unknown bundles of objects. A lot of people also want AOP features like declaritive behaviour and easier testing. People also want things to be more flexible and have shorter development cycles. I've been a developer for 6 years now. Programmed in about 5 languages and still I find the slowest part of the development cycle is handling the presentation layer with it's multiple reloads etc. I mean i could write a desktop application now with remoting to do the same job quicker than i could write the web interface. That doesn't seem to be the promise offered when people first started developing web applications. And I remember that far back. One thing that I am certainly not suggesting and I want to make this clear is that I am not suggesting that anyone fork the codebase. There is certainly too much clutter surrounding the project at present. It's better if you make it easier to do the difficult stuff rather than vice versa and having everything but the kitchen sink thrown in there doesn't make it any easier. --b approach On Mon, 20 Sep 2004 06:31:24 -0700, Michael McGrady <[EMAIL PROTECTED]> wrote: > Open source and painting are connected in someways. The biggest mistake > of the amateur painter is to keep adding colors when the painting is > done. The result is always that murky, dark, ugly, look. Likewise, > open source, filled with people with egos, sometimes does not know when > something is done, finished, damed good and certainly good enough. > > I have a real concern that Struts is going to continue to be bloated > with what are not Struts, not part of the framework, but what are > instead really very useful uses of Struts. DispatchAction and its > progeny are just one example of this. I would suggest that such > offerings would better be managed in a separate application called > something like "Struts Patterns" or "Struts Best Practices". Perhaps > such classes could be released as classes and either maintained (or > preferrably not) independent of Struts? > > I would hope that by the term "bloat" I don't convey that such classes > are not wonderful ideas and their authors are stellar citizens. It just > seems to me that a framework ought to be maintained as a FRAMEWORK and > that allowing USES OF THE FRAMEWORK to become part of the framework is a > groundwater mistake. Generally, I think it might be better if the > actions package were distributed outside Struts proper. > > As a framework, there comes a time when something like Struts is done, > and we need to move on to other things except diligent maintainence and > creating clever uses. My present predeliction is to save what presently > exists, clean it up by jettisoned what is not needed, and to watch for > good ideas that might arise in uses. This is just a thought. > > There needs to be, I think, a clear separation of Struts patterns or > clever uses of Struts and Struts itself. I would suggest that something > formal be instituted. Thanks for your ears/eyes on this. > > Michael McGrady > > --------------------------------------------------------------------- > 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]
