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? -- Martin Cooper 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]
