As I was putting in place the code for populating controllers with extra parameters specified in the configuration file, I realized that I'm not especially happy with the way controllers are created.
I'm wondering if there would be value in allowing the ControllerFactory to be configured in much the same way that ViewFactory and TransformFactory objects are. The upside of doing this would be that the bean population (and validation, etc) code can be eliminated from the controller base classes and placed in the pluggable factory modules instead. Presumably the factories would be free to do all kinds of crazy things... including build Struts Actions, which would be pretty weird but I'm sure somebody will think it's cool :-) The downside of doing this would be a little extra complexity, and it would be necessary to eliminate the ability to specify the controller using an attribute on the command element. I'm starting to think that it would be a good idea to eliminate this anyways just to simplify validation and allow for more future flexibility. Right now you can specify a controller in two ways. <command name="foo" controller="org.foo.Bar"> <view... </command <command name="foo"> <controller value="org.foo.Bar"/> <view... </command> Both of these currently work. Of course, if you want to add extra initialization parameters to the controller, the second approach is necessary so that the <controller> element can have subnodes. I'm wondering if, even without the extra pluggable ControllerFactory feature, it wouldn't be better to just eliminate the first option. Thoughts? +1/-1/+0? Anyone like the idea of pluggable ControllerFactory implementations? Jeff Schnitzer [EMAIL PROTECTED] _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
