I don't think downloading a file is quite as complex as uploading one, unless you want to grab a BLOB field from a database or something along those lines, but that's the beauty IMHO of Martin's contribution... It's a very easy matter to make use of the underlying concept in any which way you want, as my contributed sample app does.
The debate about what constitutes bloat in any framework is a difficult one, as is the debate about what makes sense as part of the framework and what is just a clever usage of it. In my mind, a framework should be as lightweight as possible BUT should provide as much "common" functionality out-of-the-box as possible. Where you draw the lines demarking all these different concerns is difficult to be sure. In simplest terms, if it doesn't add required work for a developer and doesn't impact performance or server load if a particular piece of the framework is not utilized, I don't really consider it bloat, assuming the functionality in question does fulfill a commonly-needed function. Certainly we can agree that downloading files is a common enough activity?
Look at it this way... If someone adds something to Struts that fulfills a need that comes up commonly, you could rightly call that addition a pattern. We don't consider pattern-based development bloat anywhere else, why would we here? Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a "one-stop shopping" proposition. I would agree you have to be careful in what you add because it IS easy to add things that probably shouldn't be, but that decision is never an easy one I suspect.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Michael McGrady wrote:
A downloading application utilizing Struts, in my opinion, like the uploading applications, should have its basic classes somewhere else, like uploading is in commons. Such an application, in my opinion, should merely present an interface that subclasses of Struts Actions can, directly or indirectly, reference. Such an application, also in my opinion, should distinguish and decouple distinct behaviors as, for example, the distinction between the io functions and the management functions such as access control, choice between zip, folder and database sources, etc. The demands of such applications, in my opinion, are too different from the purpose of the Action class to work well in the end in an Action class. Shouldn't, for example, any cool solution for either downloading or uploading in the end be multithreaded? Is getting or managing the receipt or sending of a file really within the proper scope of the Action class?
Michael McGrady
--------------------------------------------------------------------- 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]
