Frank W. Zammetti wrote:
Has anyone that needs to downloaded the DownloadAction Sample App I put together? I need to clear some space on my server, and that's a good candidate for deletion. If anyone still needs it, the address is:
http://www.omnytex.com/downloadapp.zip
Also, I didn't get any feedback on it, so do I assume it looked good to everyone? Or do I assume everyone has just been too busy to look at it? Being as I'm susprised I found the time to do it myself, perhaps the later is the more likely :)
Hello, Frank,
I have a couple questions, if that interests you. I am trying to understand your thinking. I am going to soon be addressing downloading and want to integrate it with my upload application. I was thinking of building a downloading API not unlike my uploading API. Your work has given me pause and I would be interested in your thinking.
Sometimes when you look at someone who has pursued a completely different solution than one you have worked on or envisioned, it is hard to grasp what they were thinking. So, forgive me if I am a bit thick on this, because I have just finished my own upload application which I am now in the process of "connecting" to a Struts application.
Let me note what I have done and then ask you, if you would, to explain what your thinking is knowing where my predelictions have gone.
Fundamentally, what I have done is used the commons DiskFileUpload, FileItem and FileUploadException to do the "heavy lifting" and have built an upload application around them with classes to take care of parameters, parsing, repository, file items, and form data, with a central application manager. This application interfaces take care of the usual needs in such an application, such as specifying repository types, setting file limits in size, type (I have identified 1055 extension types, many having subfile types, such as ".xm" which is both a FastTracker 2 file and a Digital Tracker music module (MOD) file, and there are many more, I am sure) and number, setting blacklists and whitelists, providing listeners and histories, taking care of overwriting options, and so on.
Only at this point does Struts come into play. The Struts view or form can use the interface in addition to the normal Struts stuff. (My comprehensive button application also has a solution for <input type='file'> allowing me to use mulitple dynamic, localized image buttons for the file browse. There was a challenge on the Internet for doing this, i.e. using images for browse buttons, because some think that due to W3C restriction on the browse button or <input type='file"> make this impossible, but it isn't. I know because I do it regularly. This is integrated with Struts.)
Anyway, it is only at this stage that I am ready to talk to an Action and the action merely passes the request object off to the application. You can see we were thinking differently. I am trying to see what you envision in this sort of context happening via the DownloadAction.
Am I making sense to you? I would like a comprehensive "load" app that embraces these connected activiites.
Thanks, Frank,
Michael McGrady
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
