On Wed, 29 Sep 2004 00:07:06 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> 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 distinction you are drawing is indeed correct, and significant. However ... > 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 proposed example is a good first step, but the hard part of building a framework, as opposed to an application, is figuring out where to define the extension points. An example issue relevant to the current proposal -- what if I want to load my data from somewhere other than a database? If's fine to generalize the names of the tables and columns, but an extensible framework for building download-some-recorded-data portions of an application will probably need to define some interface that includes ways to abstract where the data comes from, what the output content type should be, how to determine the content length, whether (and how) to create a Content-Disposition header, and a myriad of other details. > 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? I would suggest that downloading *static* content (from a file on the server) is something that a web server, or a servlet container, already takes care of -- it doesn't need any extra support from a framework like Struts. The window of opportunity is around "static" data that is stored in a fashion not supported by the default functionality of the server on which the application is running. Of course, one could also argue that serving "static" content doesn't need an app framework at all -- it can be implemented (for example) by a standalone servlet that is totally unaware of Struts. That is also a reasonable position; one would have to articulate why this functionality needs to be incorporated into the controller for the user interactions. Such arguments can be made, but I don't think they are going to be universally applicatabe. > 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. > I agree with you that the o.a.s.actions package is built *on top of* the framework, instead of *being* the framework. However, the proposed code doesn't strike me as sufficiently general, yet, for inclusion -- perhaps we could look more at defining the general problem of "how can we create an abstraction for a response that might be acquired from some resource, instead of being dynamically created by the execution of a JSP page". In the purest sense, the fact that you can return null from an Action (indicating that the response has already been created) means that Struts itself doesn't need anything extra. That being said, a "design pattern" standard action, equally at home with data extracted from a database, a directory server, an XSLT transformation, static files, web services calls, a return from an EJB, or execution of some method on a JavaBean, ... would be more appropriate for inclusion in Struts itself. Such an approach (defining a Provider interface of some sort) would also enable the use of any of the currently popular IoC frameworks to provide an appropriate implementation, instead of burying all the functionality for JDBC access directly in the proposed Action itself. Is it feasibe to generalize the idea of a "download" standard action so that it could deal with the entire set of use cases, instead of just those related to a database? And, along the way, make the case why this should be implemented as part of the app framework itself, rather than just being another facility included in the same web application? > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
