2

We have been developing a web application in JSF using Netbeans 6.9.1. It is about shopping. Therefore, many a times we have to deal with images. Images need to be uploaded into MySql database. Doing so, requires some mechanism to browse image files but we found that JSF does not support file browse directly. we could have used HTML file browse <input type="file".../> but for that we need to obtain the external context from Servlet to access it's value in JSF managed bean from request parameters.

HttpServletRequest request=(HttpServletRequest)FacesContext
                         .getCurrentInstance().getExternalContext().getRequest();

which may not be one of the convenient, suggested and best methods I think [ and also, it may not be the approach to mix HTML with JSF components] and if we were to use HTML file browse, we would have to maintain it's view state which is utmost important in JSF and HTML file browse by nature doesn't maintain it's view state and also, we can only obtain the file name from HTML file browse. In many circumstances, it is essential to obtain the absolute file path. Is it possible to retrieve the absolute file path from HTML file browse and make it maintain it's view state? Which approach should we follow?

Lion
  • 18,729
  • 22
  • 80
  • 110
Bhavesh
  • 4,607
  • 13
  • 43
  • 70

2 Answers2

3

Without a framework you could use the Apache commons package, for example. Or Tomahawk...Just Google search for those two as there are easy tutorial online to get you started:

tomahawk OR commons-fileupload

By the way the method you have listed to obtain a request in JSF is very popular and i also use it in my JSF application for several different things. So, give it a try. Hope this helps!

Mechkov
  • 4,294
  • 1
  • 17
  • 25
2

It's indeed not the best practice to fiddle with raw Servlet API in your JSF code. You should try to minimize the javax.servlet imports/dependencies as much as possible. An ideal managed bean has none of those imports. So forget that part.

The standard JSF component library indeed doesn't ship with a component which represents a <input type"file">, for the simple reason that the standard Servlet API, which JSF is based on top of, didn't provide any facilities to parse multipart/form-data requests. Only since Servlet version 3.0 this is supported with the new HttpServletRequest#getParts() method. But at that point JSF 2.0 was already designed and finished. We're currently at JSF 2.1, which finally officially requires a minimum of Servlet 3.0, so a file upload component should be possible with just the standard APIs. Right now there are two ongoing spec requests open to include a file upload component in JSF 2.2:

Until then, your best bet is to grab a 3rd party component library. If you are looking for a really barebones component which doesn't render any additional JS/CSS fanciness, then I'd recommend to pick Tomahawk's <t:inputFileUpload> component. You can find in the following articles how to install/configure it (it's unclear what JSF version you're using, so I'm mentioning it for both JSF 1.x and 2.x):

Please note that your question as in how to retrieve the absolute path made my neck hairs to raise somewhat. You should not be interested in the file's absolute path, but in the file's contents. For a more detailed explanation, see also How to get the file path from HTML input form in Firefox 3.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • There are legitimate reasons to get the full path of a file. For instance, I have an intranet application in which I want to be able to store a reference to an external file, such as a spreadsheet, that is stored on a shared volume that will be available to all users via a filesystem reference such as `\\Server01\Shared\Company\Documents\Order12046QualityTests.xls` or even `file:\\\J:\Company\Documents\Order12046QualityTests.xls`. In this case it's a file that will be updated multiple times throughout the life of an order, and I don't want to have to deal with repeatedly uploading it. – Kevin Rahe Aug 05 '15 at 13:17
  • @KevinRahe: for that, HTML is the wrong tool. Use a client side application (e.g. Applet). See also a.o. http://stackoverflow.com/q/27698363 – BalusC Aug 05 '15 at 13:20
  • An Applet, with its requirement of a locally-installed JRE and signing or other method of getting past the sandbox security, seems like extreme overkill to obtain such a simple piece of information. I'm thinking something like a locally-installed utility that will determine the path of any file dropped on it (a la the Windows Command Prompt) and copy it to the clipboard, from which it could be pasted into a field in my browser application, would be more appropriate. – Kevin Rahe Aug 05 '15 at 15:13