On Wed, 22 Dec 2004 23:40:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> The problem with putting code like that into a command, is what if > someone wants to replace the populate command, but doesn't want to > re-invent the multipart stuff? I think there is a place for service > functions, call them utils or whatever, implement common routines that > one or more commands take advantage of. For this particular use case, I had been considering the following approach when I try to integrate FileUpload functionality into Shale[1] (which is also Chain based) -- write a command that does the request wrapping if this is a multipart request, and then *replace* the original request (in the Context object) with this new wrapper. Then, downstream commands that don't care about the upload-ish characteristics can do simple things like retrieve parameters by name (which is what the populate command does), without caring whether they are working on an original request or a wrapped one. > I agree these routines should not be lumped into one or two huge util > classes. Ideally, these functions would be grouped into logical service > classes fronted by interfaces, allowing multiple implementations. To > pull of something like that cleanly, however, I believe we'd have to > fully adopt an IoC/DI container like Spring. I'm sure we'll still end up with some utility type stuff (and wrapping it as you describe is a good idea), but there are still some interesting opportunities to reduce the overall "volume" of utility code. > > Don > Craig [1] I'm looking forward to Commons FileUpload being Filter-ized ... and hope we can also make the guts of its logic suitable for inclusion in Commands like this as well. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
