I am currently using Struts. The implication of that statement is relevant to where I am calling my file Dialog box. I click a button, it calls an action and in my action I call a method from a another class which I wrote that will display a file dialog box!! Here is the code for that function.
//Create Frame for FileDialog box
Frame f= new Frame();
This makes no sense to me: FileDialog is a Swing component. As such, it runs on the server side.
Struts is a web application framework. Its purpose is to run on the server and process requests made by a client--like a web browser. Never the twain shall meet other than via HTTP requests.
Does anyone know what I am doing wrong?
The short answer is "completely misunderstanding the nature of web applications." I'd suggest checking out any of the myriad Java web application tutorials available from Sunacle and on the web before proceeding much further.
FileDialog is an AWT component. It is recommended you use it's Swing counterpart which is JFileChooser. Google for AWT/Swing or Heavyweight/Lightweight components to understand the difference and why one should switch to Swing components.
David Newton wrote:This makes no sense to me: FileDialog is a Swing component. As such, it runs on the server side.
I think you meant to say it runs on the client side.
I am not sure if you understood exactly what is happening around. A small hint from my side
Struts is a web application framework. All the information flows in the form of HTML. Whenever a request is given to the server it builds HTML response and sends to the client. The client just needs a browser to show all the information. But here you want to use 'FileDialog' which is actually is a AWT component. AWT/Swings are used to develop standalone applications i.e. it needs a JVM to run the application and can't be run on a remote machine directly.
So in your case, whenever the above code is encountered a FileDialog would popup on the machine which runs the server since the JVM runs on this mahcine. You would have clearly understood the issue if you would have given the request to the particular web page from a different machine.
@Maneesh: David was trying to point out the same issue by saying 'server side'
Not when called from a web application. The file dialog (also with JFileChooser) is shown on the system that makes the call. For web applications, that's the server, not the calling client. You'd need a signed(!) applet to be able to show a file dialog for the client. The only alternative I know is use an HTML input element with type="file", but you loose a lot of functionality like file filters.
Edit: that was a reply to Maneesh. Guess David, Pradeep and I all are saying the same thing.
You're right about that. Then letting the user download the file using the browser's mechanisms is a better solution. If the content type for the link is not something the browser can display itself (so not text/html, text/plain, images) then most browsers automatically shows a dialog that allows the user to open it directly with the preferred application or save it.
As for uploading files, I just found out today that <input> has an optional attribute "accept" with which the web designer can specify a comma separated list of content types to allow. Opera seems to be the only browser to listen to this though; it adds one filter for each content type. Internet Explorer 6 (need it at my job...), Firefox 3.6 and the latest versions of Chrome and Safari all ignore it.
Joined: Feb 08, 2010
Okay I am thinking I have a better grasp on whats going on here, I haven't had a chance to look at this sense I posed but will let y'all know how it turns out thanks for all the replies!