Wow, I didn't expect my quick little abstract class to generate quite this much discussion! ;-) But since my name is now in the Subject line, I guess I should say something...
My thinking was that the class I put up for perusal was about as much as I think we should add to Struts itself, in the 'actions' package. In fact, I swithered on whether or not to include the concrete implementations of StreamInfo, rather than only the interface, but finally decided that, without those, it was perhaps a little *too* abstract. And I didn't just commit it because I wanted to hear from people as to whether or not it would be useful. One or more extensions of DownloadAction, as being discussed in this thread, would be more suitable for an example app, as Craig has suggested. I agree with Joe that it would be great to have an example that includes custom action mappings, and would encourage going down that path. They *are* a powerful mechanism, as I know from personal experience, and they're not that hard to use once you get the idea. One area where I'm less comfortable with an example is introducing a database to the mix. We've gone to some length to avoid that in the past - for example with the original example app - and I'm not too comfortable with changing that now. The less we have to depend on, specifically with respect to additional setup, the more accessable our example applications will be to the majority of Struts developers. -- Martin Cooper On Tue, 21 Sep 2004 14:23:45 -0400 (EDT), Frank W. Zammetti (MLists) <[EMAIL PROTECTED]> wrote: > Since the thread I originally started with regard to a BLOB download > Action kind of veered off into a different territory, I was hoping > starting a new thread could the discussion get back on topic. I have a > bit of a vested interest in this now because I started the discussion and > I hate leaving anything undone, so... > > The code posted earlier today by Martin Cooper strikes me as a good > approach, better than my own on the whole. As per my comments in the > previous thread, I'd like to incorporate some of what I did with my > suggested Action however... > > Basically, the premise I'm proceeding from is that a large part of Struts > is declarative, I.e., done through config files. My goal with the Action > I wrote was to continue in that vein. Although the code I posted got all > it's parameters from the request object for demonstration purposes, I had > always intended them being moved to the Action mappings in struts-config. > > Taking Martin's code, I believe this is possible. The benefit would be to > yield two things... one is the abstract base class itself as Martin wrote > it, which can be extended as required. Two, we would also get a concrete > implementation that can use the Action attributes from the config file, > thereby allowing developers to declaratively use the download capabilities > without having to write any code. To me, this is a good thing (tm), and > is frankly in keeping with the whole idea of Struts saving time and > effort. > > The way I envision it is an attribute added to the Action mapping that > names the StreamInfo class instance, call it "streamInfoType". This might > be FileStreamInfo, or DatabaseStreamInfo, etc. Note that this is IN > ADDITION to the type attribute, but when present the type would always be > the concrete implementation of the DownloadAction (call it the Struts > "srandard" DownloadAction implementation). If the type was a custom > DownloadAction class, then it may or may not make use of any > streamInfoType attribute that is present, completely up to the developer > at that point. The "standard" action would then instantiate the correct > StreamInfo class as named by the streamInfoType attribute and make use of > it, setting the attributes in it from the ActionMapping (or overriden by > request, see below) as appropriate for the known StreamInfo type. For a > download from the file system I would think "filePath" would be it. For > database downloads, they might be "tableName", "tableField", "tableQuery", > like my original Action had. I think we'd need to debate what else should > or should not be included in that list though. > > In addition, for maximum flexibility, allowing these values to be > overriden by corresponding values in the request should be allowed for. > > In short, I believe that persuing this whole idea is a worth-wild exercise > because downloading of BLOB-types is such a common activity I really do > think it belongs in Struts. I know there will be some debate about the > best way to accomplish it, but as is the case with most things in Struts, > there are numerous ways to accomplish any goal. Providing developers with > at least one solution built-in that might suffice for 90% of the cases > seems like exactly the thought process that's been used all along > developing the framework. > > -- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
