I favor a evolutionary approach to getting to the Next Generation of Struts. As apposed to scrapping every piece of code we have. This would entail aggressively deprecating functionality.
The advantages are we would most likely always have a working framework, which would encourage user participation, usage, testing. That means we could use it in our paying jobs. Some of us may even be able to justify working on Struts 2.0 on our paying Jobs time. I am concerned where all the energy, time, code, documentation, and testing will come from with a clean start. I strongly believe one of the reasons Struts is so popular is that we were big on compatibility between releases, and so staying up to date with the latest Struts release or nightly was not very painful. The disadvantages are that it might seem like we would have to do extra work in gradually refactoring Struts into the next version. Any code base that starts from scratch has to undergo the painful process of setting up the initial classes, tests etc... Again user participation, in usage, testing, and contributions played a major, no, critical role in struts's development, and we'll need that same input again. However, now days there are many other frameworks with which to choose. Bottom line is I believe like you do that we are smarter now and know better ways to do things. Look up Erick Hatchers comments he made a few months ago on Struts, and ways to improve it as an example. -Rob > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 17, 2003 09:22 PM > To: 'Struts Developers List' > Subject: Re: Struts 2.0 Discussion Forum > > Don Brown wrote: > > Is there one? I have several ideas I'd like to toss into the > > discussion. > > > > Don > > There's a Whiteboard page in the Wiki. > > http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard > > I'll be posting more about Jericho, but wanted to get what I had so far > (a starter DTD) under CVS. > > One other idea that I've been meaning to bring up in the wake of > wildcard Mappings, is the idea of merging context attributes into > ActionForward paths. For example, we could do something like > > <forward name="lookup" merge="true" path="/lookup.do?key={key}" /> > > and have it replace {key} with request.getAttribute("key") (or session > if not found). > > -Ted. > > > > > --------------------------------------------------------------------- > 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]
