aspose file tools*
The moose likes JSF and the fly likes Loading problem with t:inputFileUpload Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Loading problem with t:inputFileUpload" Watch "Loading problem with t:inputFileUpload" New topic
Author

Loading problem with t:inputFileUpload

Steve Renard
Ranch Hand

Joined: Apr 27, 2007
Posts: 66
I'm using t:inputFileUpload from tomahawk library for file upload functionality in my application.
On the corresponding backing bean, I have org.apache.myfaces.custom.fileupload.UploadedFile as the property.
It works great when it comes to the setter part. The file I upload goes to the server and is written as a database column value.
But for some reason the getter part has problems and I'm never able to display in UI the same file that I retrieve from database.
I need a solution to this issue. Please help.
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
What did you expect from the getter? An input field which is automagically converted to a download link or so?
Steve Renard
Ranch Hand

Joined: Apr 27, 2007
Posts: 66
Hi,
Sorry about the delay.But This issue is still open.
t:inputFileUpload has a text box and a browse button.
It allows me to choose a file and fills up the text box with full file path.
So while I retrieve the file back form database, I need to display the full file path in the UI. (I don't need a download link)
I appreciate your help.
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
The HTML specification already forbids it. It's a security hole.

As JSF just generates HTML, it can't do much for you here.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

When you upload a file, the contents of the file plus certain meta-information are sent to the server. Because the file may be binary, the file contents are MIME-encoded, but that's transparent to you, so don't worry about it. The meta-information includes the simple (no directory path) file name and the MIME type of the file. Typically the file will be copied to a temporary location on the server, but Tomahawk doesn't expose that - it just supplies the data as a bytestream after MIME decoding.

One the server has the data, it has to figure out what to do with it. It can create a copy of the file on the server side, store the file data as a BLOB in a database, or do whatever it wants.

In the case where you want to display an uploaded image, you have to present the image in terms that the user's browser can make sense of. Images are not transmitted in-line when you request a web page. Instead you use an image tag (<img> or its JSF equivalent, <h:graphicImage>). The image tag specifies a URL from which the image can be downloaded.

The tricky part is resolving this URL into an image. As I unendingly remind people, a web server is not a file server, so for the most part, you can't create a file and expect the server to locate it and transmit it automatically. True, you can stuff the file into the WAR, assuming that you're dealing with a server that explodes WARs, but I recently received an education in what happens when you do that - upgrading the WAR wiped out all the images.

A cleaner method is to create a servlet or JSP that accepts an image URL request and serves up the image data. The servlet/JSP would typically open the file created (or retrieve the database BLOB) and just copies the bytes to the output stream. After setting the content-type header to reflect the image type, of course - image/jpeg or whatever.

This can be kind of annoying, so one way that's less troublesome is to use a friendlier set of tags. The JBoss RichFaces library has a very nice file upload tag and a "mediaOutput" tag that can assist in displaying uploaded images. You still have to find a place to store the data and you still have to provide the logic that copies the data to the HTTP output stream, but you don't have to write a servlet, just implement methods on a backing bean.

The original file path is meaningless to a web server, since there's no way using only HTTP to open and access files on a client's computer. Fortunately. There's enough ways for rogue web sites to infect clients as there is. The only web to get a file from an HTTP client to an HTTP server is if the client pushes the file's contents to the server. Which is done by the browser as part of the functionality of the file upload html tag.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Loading problem with t:inputFileUpload