I should point out that this is still possible in the current scheme; just create a base controller class which derives from org.infohazard.maverick.ctl.Throwaway instead of ThrowawayBean. Currently, all the population/validation logic is expected to be in the abstract base controller class, so this is already outside the framework core.
The big difference would be that the population/validation logic could be moved outside the controller base class. I suppose the primary benefit would be the ability to experiment with wildly different controller schemes, as opposed to mildly different controller schemes. Can you think of something you want to do that would be difficult or uncomfortable as part of a base controller class? While we're mulling this over, I'll eliminate the controller attribute on the command element. No matter what we choose now, this will allow us to make changes in the future without breaking compatibility. Does anyone have a preference for how the <controller> element should look? The old "type" attribute from Maverick 1.0 is not a good idea... I'm leaning towards: <controller class="org.foo.Bar"/> BTW, there is an example of using a modified version of Jason Hunter's multipart handling filter in PIG: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/pig/src/java/org/info hazard/pig/web/servlet/ The SafeMultipartFilter and SafeMultipartWrapper store the upload in RAM rather than writing to disk because Jason's code would have problems if two simultaneous users uploaded the same filename. Just be sure to limit the maximum upload size to something reasonable :-) Jeff > -----Original Message----- > From: jim moore [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 3:46 PM > To: Jeff Schnitzer; [EMAIL PROTECTED] > Subject: RE: [Mav-user] Flexible controller factories > > I definitely would give this a thumbs up. The ability to plug custom > controller functionality to handle multipart requests alone would make > it worthwhile, plus I think the ability to put in global bean validation > would be nice. For instance, on the project I am working on, I want to > populate String properties with null across the board if they are empty > strings. It would be nice to be able to centralize this functionality in > a logical place. > > --jim > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff > Schnitzer > Sent: Sunday, January 27, 2002 11:01 PM > To: [EMAIL PROTECTED] > Subject: [Mav-user] Flexible controller factories > > > 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 _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
