DownloadAction Sampl App Sample Going... Going...

["Frank W. Zammetti" <fz...@omnytex.com>]

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 :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: DownloadAction Sampl App Sample Going... Going...

[Michael McGrady <mi...@michaelmcgrady.com>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org