I've got a good example, check out springworkflow ( sourceforge ) and it's chaining system.
http://www.competities.com/springworkflow/chaining.html Chaining is quite frankly a pain with the existing model. The (struts) design needs to be parred down in order to support development according to more complex business requirement models. --b On Mon, 20 Sep 2004 16:37:07 +0200, bryan <[EMAIL PROTECTED]> wrote: > 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]
