Way down there...
On Tue, 28 Sep 2004 21:51:55 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > 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? Um, that's pretty much what I was trying to do with the DownloadAction I posted for comment. It doesn't cover every possible case - for example, it doesn't provide a way to stream content back using chunked transfer encoding - but it does, IMHO, handle the vast majority of download scenarios. I'd be interested in hearing your thoughts on generalising this further, though. -- Martin Cooper > > > -- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
