I totally agree - let me clarify. I think Struts 2.0 could use an IoC framework like Spring to help improve its internal structure. Any configuration files should be stored in the Struts jar, but be able to be overridden by specifying an alternate IoC configuration path. This lets advanced users easily modify the structure of Struts itself, but not add complexity for the casual user. Of course, Spring and probably other frameworks allow you to easily customize the configuration process.
Don On Thu, 18 Dec 2003, Martin Cooper wrote: > 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. > > I'm a little hesitant to start depending on other frameworks. It's not > that I think they don't have anything to offer us, it's just what it does > to the newcomer to Struts. If someone has to learn Struts *and* Spring > (for example) to get going, then we've set the bar much higher. > > If we do end up deciding to depend on something like this, I believe we'll > need to put in the work to make it "look" like Struts. Taking Spring as an > example again, the substantial difference in the "character" of the XML > config files would easily confuse a newcomer trying to get his/her head > around the syntax. If we could make those files "look" like Struts config > files (or vice versa, for that matter), that would help, though. > > -- > Martin Cooper > > > > > > - 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]
