On Thu, 18 Dec 2003, Craig R. McClanahan wrote: > Quoting Martin Cooper <[EMAIL PROTECTED]>: > > > Just to add a few more off the top of my head: > > > > * Make the Struts core independent of the Servlets spec and the Portlets > > spec, so that it can be used for both, and more. > > > > * Separate view-technology-specific code into separate components, so that > > the core is view-technology agnostic. So, for example, all JSP specific > > code, including all of the taglibs, would move to a JSP component. > > > > * Rework Tiles into two facets, so that the core is independent of the > > Servlets spec and JSP, and the JSP component is part of the view specific > > component described above. > > > > * Split out file upload handling into a separate pluggable component, with > > its own configuration. I noticed that this is still in the initial Jericho > > DTD, but I think it should not be. The file upload implementation is > > pluggable, and so should be able to have its own config definition. > > > > I know I have more in notes at home, but just wanted to throw these out. > > > > A sort of meta-question: When is Struts no longer Struts? I mean, how much > > change can we introduce in Struts 2.0 before it becomes so different that > > it's really a different framework? Do we need to decide on what Struts is, > > and is not, before we go too far down the path of Struts 2.0? Or do we let > > whatever falls out just fall out and deal with it later? > > > > Product names are marketing, not technology. Struts 2.0 will be Struts if *we* > call it Struts :-). > > More seriously, the amount of change between major product versions can be > pretty enormous in some cases (ask classic ASP developers if they think ASP.NET > is really the same environment or not). Innovation and revolution are > perfectly fine things to do (applying all the lessons we've learned along the > way), but we should also remember that there are thousands of apps based on a > Struts 1.x architecture that need continuing support. We need to have the > discipline to continue to work evolving a 1.2.x world while we're creating a > new 2.x one.
I think I need to elaborate on my thoughts some more, since I wasn't really clear the first time around... A great deal has happened in web application framework land since Struts came along 3-1/2 years ago. There is a boatload of frameworks out there now, and some of them have some great ideas. What I don't really want to end up with is a Struts 2.0 that is simply a reinvention of what other people have done, with a compatibility layer to make it accessible to Struts 1.x developers. So, what makes Struts Struts? What characteristics do we need to preserve in order to keep it Struts, and retain the greatness that has made it so amazingly popular? How far can we go before the decision to choose Struts 2.0, or not, is no different to a potential developer than the decision to chose any one of the other frameworks out there today? Obviously, compatibility is going to be very important, but I hope that's not all! > > Regarding 2.x, an important consideration will be base technology platforms -- > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the > presentation technology, etc.). +1 to a J2EE baseline. -- Martin Cooper > > > -- > > Martin Cooper > > > > Craig > > > > > > On Wed, 17 Dec 2003, Don Brown wrote: > > > > > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x > > > release work. :) I'll throw out some ideas here, then develop them later > > > in the wiki: > > > > > > - Make Inversion of Control central. By using an IoC framework to wire > > > Struts together, it makes it really easy to extend or improve Struts not > > > only for future development but for users as well. I'd recommend Spring's > > > IoC impl as it is small (>100k), really easy to use, and easily > > > extendable. If we wanted to remain more "agnostic", there are "meta" IoC > > > frameworks that let you plug in Pico/Spring/Avalon, etc. > > > > > > - Use XML Schema over DTD's. Give struts config its own default namespace > > > to make it easier for users to mix in elements of other namespaces. An > > > example would be adding custom documentation attributes and elements. Of > > > course the usual arguments for XML Schema over DTD's apply as well. > > > > > > - Replace paths with URL's, allowing for a default protocol. An action > > > path would look like "action://foo" or a tiles forward would be > > > "tiles://tilesdef" This would make it easy to plug in handlers to support > > > different presentation engines. If no protocol is specified, the path is > > > handled as usual. > > > > > > - As Ted said, contine with the wildcard theme. Struts should do > > > everything possible to cut down configuration. > > > > > > - Also, again totally agreeing with Ted, make everything interface based, > > > have default implementations, and free apps of HTTP. Ideally, I'd like to > > > see extra effort going into making it easy if not effortless to take a > > > Struts 2.0 app and use the code in a portlet or web service environment. > > > At least in my area, clients are wanting human and machine interfaces, > > > with the human interface generally being behind a portal. > > > > > > Anyways, those are my "brainstorming" thoughts. If any look interesting, > > > I'll write something up in the wiki. > > > > > > Don > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
