Rather than adding lots of new attributes to the existing action mapping element, maybe you should add your properties to an ActionConfig sub-class and use nested set-property elements to configure your download action mapping. Then your download action implementation could be used with older versions of struts.
I haven't played with with set-property but I think you would reference your new ActionConfig or ActionMapping sub-class with the <action className=""> attribute and then use nested <set-property property="" value=""/> elements for each property that needs to be set for a particular impl. <!ELEMENT action (icon?, display-name?, description?, set-property*, exception*, forward*)> You should probably leave Martin's class as is and add your new impl along with a new config class that has all the attributes your action impl needs. That would leave Martin's class available for use by people that have some other means of getting the stream. -----Original Message----- From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: On Martin Cooper's DownloadAction... 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]
