On Wed, 17 Dec 2003, Joe Germuska wrote: > >- 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. > > Personally I suspect that a meta framework is more trouble than it's > worth, although I haven't really looked at any too closely. (Have > any pointers) > > So then, with specific frameworks, I don't understand how Pico's > orientation towards constructors works in an environment where beans > need to be dynamically instantiated, but perhaps I just haven't > thought about it hard enough. Avalon seems too heavy, which leaves > us (or me at least) with Spring and HiveMind. I haven't developed > with either but so far the docs for Spring give me a warm fuzzy > feeling while the HiveMind docs kind of scare me.
HiveMind, from what I've read, is more service-oriented. I've been using Spring for a few months now and totally loving it. It completely stays out of your way, leaving your code with little or no Spring dependencies. Furthermore, it supports both javabean and constructor-style dependency resolution. > >- 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. > > XML Schema?! Naw, RelaxNG!!! After all, it is "now an international > standard" > (http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html) Doesn't matter to me as long as I get namespace support :) > >- 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. > > I'm a little sketched out about assigning schemes of our own. I see > the motivation, and think the goal is good. Wonder if we could find > another mechanism. Well, I've seen it used particularly in Forrest to good effect. The key is keeping the number of "protocols" to a small number, but allowing the user to develop more if they feel the need. Don > > >- As Ted said, contine with the wildcard theme. Struts should do > >everything possible to cut down configuration. > > hear, hear! (, hear, hear, hear!!) > > >- Also, again totally agreeing with Ted, make everything interface based, > > a few more hears here ;^) > > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "We want beef in dessert if we can get it there." > -- Betty Hogan, Director of New Product Development, National > Cattlemen's Beef Association > > > --------------------------------------------------------------------- > 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]
