Frank W. Zammetti wrote:
You are referring to Martin's DownloadAction I believe... Note that he didn't place it in the action package, he placed it in the actions package. It's a subtle difference, but an important one. As I understand it, the action package are the core classes and interfaces of Struts, while the actions package are specific subclasses of those core elements.
The next things, though, would be a forms package, etc. There would be one, I would bet, if some people had thought of it! LOL ;-)
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.
Downloading is just as complex, I think, and fraught with danger. I don't think Martin's approach does exactly what you think, but that is not the issue. I could be right, or you could be right. If we are arguing about whether we like it, it probably should be a CHOICE somehow but not in the framework proper. I am FOR making more choices available. Just HOW to do it is the question.
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?
Somethings, however, are useful and have NOTHING to do with Struts. The ImageButtonBean is an example of this. I also think that Martin's DownloadAction is an example of this. Those things should be available, of course. I am NOT saying they shouldn't.
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?
But, there are Strust oriented patterns and patterns that are not related to the framework. That is what I am saying. If you have a pattern that is (1) related to the Struts framework code and (2) a general sort of functionality that is needed, then it belongs. Other things that really are choices that some would like and others would hate should be available but not wedded to the framework in a way so that they have to be kept in there or deprecated.
Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a "one-stop shopping" proposition.
We could have MORE NOT LESS solutions if we did not put particular solutions into the framework which thereby freezes out competing and maybe better solutions. This is a real problem in my view.
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.
I would never add something that is a mere solution to a non-framework problem.
Thanks for the discussion, Frank. I appreciate it.
Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
