Craig McClanahan wrote:
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.
I think this is what Martin's proposed DownloadAction seeks to do, that is, define a valid extension point.
I want to be clear on what we are actually discussing... At this point we're NOT talking about my original submitted proposal, which did deal specifically with serving from a database (because my original thinking was that it could be done in a generic way). Martin's suggested class has since bumped my original proposal, but instead I submitted a sample app that made use of Martin's class. This is where this discussion is today. Just wanted to be sure we're all on the same page :)
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.
I would agree with this without question. The situation I'm trying to deal with (and what was the genesis for my original proposal) is really serving from a database. I have a system at work that I wrote that serves images from a database (for client customization) as well as serving PDF's generated on-the-fly, so that's being done from memory. The images are certainly static and could be handled by the web server (why they aren't in this case is an environment-specific issue). It is this area, the "semi-static" and the dynamic BLOB-type downloads that I think there is an opportunity to do something, as you said. I would durther make the argument that this is such a common activity that to include it in Struts in some fashion is beneficial to all that use Struts.
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.
Agreed. There can be such a variety of ways of doing this that a general-purpose solution probably isn't possible. The simple question though is at what point is it serving "enough" people to validate it's addition. I think Martin's approach, perhaps with just a little bit of tweaking in some ways, is sufficiently generic and extensible enough to warrant inclusion. I think my sample app, showing the serving of images from the file system as well as from a database, proves the flexibility of the approach. Serving from virtually any other source should be a simple matter.
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.
I don't think I disagree with that thought, but I do see some statements here that are leading me to believe your thinking of my original sample app, not the one based on Martin's DownloadAction. I'd be interested in continuing this discussion after I'm sure we're comparing apples and apples :)
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?
Same point as above... I'm not sure we're on common ground in terms of what we're debating.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
