[#STS-510] Add a getFile() method to FileBean - Stripes

Details

Type: Improvement
Status: Closed
Priority: Minor
Resolution: Won't Fix
Affects Version/s: Release 1.4.3, Release 1.5
Fix Version/s: None
Component/s: None
Labels:
None

Description

It would be great if there were a "public File getFile()" method in the net.sourceforge.stripes.action.FileBean object. This would be useful for some validations (for example checking the type of image uploaded) that require the file or at least the full path to the file.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Gregg Bolinger added a comment - 11/Feb/08 11:39 AM

If you look at the javadoc for FileBean...

http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/action/FileBean.html

You'll notice that getting the size, contenttype and a few other goodies are already available. And if you need a File representation you can just do something like..

File file = new File('someLocation');
fileBean.save(file);

Show

Gregg Bolinger added a comment - 11/Feb/08 11:39 AM If you look at the javadoc for FileBean... http://stripes.sourceforge.net/docs/current/javadoc/net/sourceforge/stripes/action/FileBean.html You'll notice that getting the size, contenttype and a few other goodies are already available. And if you need a File representation you can just do something like.. File file = new File('someLocation'); fileBean.save(file);

Hide

Permalink

James Robert added a comment - 11/Feb/08 2:10 PM

Gregg, your suggestion is what I do at the moment.

But, before I copy the temporary file anywhere, ideally, I would like to be able to check that it is valid using the FileBean object. It would therefore remain as a temporary file while I validate it, and if it is valid then I copy it to a permanent location. This seems nice and clean and easy.

This goodies that are already available a great for this, but for some validation, having the File object or the actual path to temporary file is necessary.

Looking at the source, the File object is present as a property in the FileBean already. Is there a reason that there is not a getter method for this already?

Show

James Robert added a comment - 11/Feb/08 2:10 PM Gregg, your suggestion is what I do at the moment. But, before I copy the temporary file anywhere, ideally, I would like to be able to check that it is valid using the FileBean object. It would therefore remain as a temporary file while I validate it, and if it is valid then I copy it to a permanent location. This seems nice and clean and easy. This goodies that are already available a great for this, but for some validation, having the File object or the actual path to temporary file is necessary. Looking at the source, the File object is present as a property in the FileBean already. Is there a reason that there is not a getter method for this already?

Hide

Permalink

Gregg Bolinger added a comment - 11/Feb/08 2:15 PM

I don't see a reason why it couldn't be made public. The only reason I pointed out the API was because the one example you gave already exists (getContentType()) without needing the File. So I just wanted to make sure you were aware. Thanks for giving more info.

Show

Gregg Bolinger added a comment - 11/Feb/08 2:15 PM I don't see a reason why it couldn't be made public. The only reason I pointed out the API was because the one example you gave already exists (getContentType()) without needing the File. So I just wanted to make sure you were aware. Thanks for giving more info.

Hide

Permalink

Tim Fennell added a comment - 11/Feb/08 2:17 PM

There are a couple of reasons. By not ever publishing a reference to the File object Stripes can be fairly certain that noone has snuck in and done something to the file behind it's back. Therefore operations like save() and getInputStream() etc. can all be sure that the file is there and untampered with.

It also means that if at another date we choose to do something else, like use something other than a File to hold the pointer to the data, all that is encapsulated. If we let the File reference out, we're really saying that we'll always support that and always use Files as the storage mechanism, where we might chose to store files below a certain size in memory....

Show

Tim Fennell added a comment - 11/Feb/08 2:17 PM There are a couple of reasons. By not ever publishing a reference to the File object Stripes can be fairly certain that noone has snuck in and done something to the file behind it's back. Therefore operations like save() and getInputStream() etc. can all be sure that the file is there and untampered with. It also means that if at another date we choose to do something else, like use something other than a File to hold the pointer to the data, all that is encapsulated. If we let the File reference out, we're really saying that we'll always support that and always use Files as the storage mechanism, where we might chose to store files below a certain size in memory....

Hide

Permalink

James Robert added a comment - 11/Feb/08 3:32 PM

Gregg, Tim, thanks for your quick responses. I figured there must be some reason...

The use case that having the File available would help with is as follows:
1.Validate the uploaded file by examining contents of the file.
2.If valid, then copy it to overwrite an existing file on the server.

At moment step one involves creating a second temporary file for validation before overwriting the old file. So I have to write the file an extra time and clean up both the FileBean and the other temporary file in my finally block.

I don't know whether making this use case easier outweighs the reasons you give above for keeping the File object private.... So please close this issue if you like. PS. Stripes is indeed awesome-tastic, cheers!

Show

James Robert added a comment - 11/Feb/08 3:32 PM Gregg, Tim, thanks for your quick responses. I figured there must be some reason... The use case that having the File available would help with is as follows: 1.Validate the uploaded file by examining contents of the file. 2.If valid, then copy it to overwrite an existing file on the server. At moment step one involves creating a second temporary file for validation before overwriting the old file. So I have to write the file an extra time and clean up both the FileBean and the other temporary file in my finally block. I don't know whether making this use case easier outweighs the reasons you give above for keeping the File object private.... So please close this issue if you like. PS. Stripes is indeed awesome-tastic, cheers!

Hide

Permalink

Frederic Daoud added a comment - 26/Sep/09 8:59 PM

Closed for the reasons given by Tim.

Show

Frederic Daoud added a comment - 26/Sep/09 8:59 PM Closed for the reasons given by Tim.

People

Assignee:

Unassigned

Reporter:

James Robert

Vote (0)

Watch (0)

Dates

Created:

11/Feb/08 11:17 AM

Updated:

26/Sep/09 8:59 PM

Resolved:

26/Sep/09 8:59 PM