cross browser multipart form handling

[John Fereira]

So, one of the limitations of multipart-form handling is that when an <input
type="file" ..> tag is used it will bring up a window which allows a user to
select a file for upload but won't allow the user to select multiple files.
As you may know, the tag produces a text input field with an adjacent button
for selecting a file from the local file system.

As I would like to be able to allow the user to upload an arbitrary number
of files and process them as a batch on the server side I came up with the
following solution:

I've added an onClick event to the input element like this:

<div id="files"><input class="textsmall" type="file" name="file-0" id="file-
0" size="70" value="Browse" onClick="FormUtil.addFile(this);"/></div>

The FormUtil.addFile() function creates a new input element and appends it
as a child of the element with an id of "files".

The first thing I noticed is that clicking in the text box initiates the
onClick event (not just clicking on the button as I would have hoped). To
handle this I can check the value. If it is zero length, I send an alert
message indicating to select the Browse button. Once the browse window pops
up and a file is select, the new input element is created and onClick
attribute is removed from the element just clicked (this allows changing
that input tag without creating a new element).

This works quite well in Firefox. However, it appears that the order of the
event handling is different for IE. In Firefox it appears that the browse
window is displayed first, and once the file has been selected, the onClick
event fires. In IE, it appears that the onClick event fires first and the
browse window isn't displayed until the event completes.

Does anyone have a cross browser solution?

[ASM]

John Fereira wrote:

Does anyone have a cross browser solution?

onchange ?

never I though to use onclick for that filer
(with my IE needs to click overside the field)

--
Stephane Moriaux et son [moins] vieux Mac

[RobG]

John Fereira wrote:

So, one of the limitations of multipart-form handling is that when an <input
type="file" ..> tag is used it will bring up a window which allows a user to
select a file for upload but won't allow the user to select multiple files.
As you may know, the tag produces a text input field with an adjacent button
for selecting a file from the local file system.
On some browsers only the button is shown until a file is selected,
don't expect that the text field is always visible from the start.

As I would like to be able to allow the user to upload an arbitrary number
of files and process them as a batch on the server side I came up with the
following solution:

I've added an onClick event to the input element like this:

<div id="files"><input class="textsmall" type="file" name="file-0" id="file-
0" size="70" value="Browse" onClick="FormUtil.addFile(this);"/></div>

The FormUtil.addFile() function creates a new input element and appends it
as a child of the element with an id of "files".

The first thing I noticed is that clicking in the text box initiates the
onClick event (not just clicking on the button as I would have hoped). To
The element is both the field and the button, so I guess a click on
either is a click on the element. There is no way to code an on-click
for just the text area or just the button.
handle this I can check the value. If it is zero length, I send an alert
message indicating to select the Browse button. Once the browse window pops
That would annoy the heck out of me, why not just do nothing?
up and a file is select, the new input element is created and onClick
attribute is removed from the element just clicked (this allows changing
that input tag without creating a new element).
But means that the behaviour changes with no sign to the user that it
has. Again, potentially confusing and annoying.

This works quite well in Firefox. However, it appears that the order of the
event handling is different for IE. In Firefox it appears that the browse
window is displayed first, and once the file has been selected, the onClick
event fires. In IE, it appears that the onClick event fires first and the
browse window isn't displayed until the event completes.

I think you have a number of usability issues here that can be avoided
by using a separate button to create the extra input. When the button
is clicked, add another input.

You may want to add a 'delete' button too to get rid of extra inputs
that might be created in error - have fun with it! :-)

--
Rob

[John Fereira]

RobG <rg***@iinet.net.au> wrote in
news:43*********************@per-qv1-newsreader-01.iinet.net.au:

John Fereira wrote:

So, one of the limitations of multipart-form handling is that when an
<input type="file" ..> tag is used it will bring up a window which
allows a user to select a file for upload but won't allow the user to
select multiple files. As you may know, the tag produces a text input
field with an adjacent button for selecting a file from the local file
system.
On some browsers only the button is shown until a file is selected,
don't expect that the text field is always visible from the start.

In this case, the page is an administrative interface that will only be used
by a handful of people so I have some control over what browsers will be
used. Unfortunately a couple of those users are from a government agency
that is a bit MS shop so they'll be using IE. I've looked at it in opera it
appears there is some confusion as to what the value attribute means. On IE
and firefox setting the value dictates the text used on the button but on
opera it also uses that contents for the input box.

As I would like to be able to allow the user to upload an arbitrary
number of files and process them as a batch on the server side I came
up with the following solution:

I've added an onClick event to the input element like this:

<div id="files"><input class="textsmall" type="file" name="file-0"
id="file- 0" size="70" value="Browse"
onClick="FormUtil.addFile(this);"/></div>

The FormUtil.addFile() function creates a new input element and
appends it as a child of the element with an id of "files".

The first thing I noticed is that clicking in the text box initiates
the onClick event (not just clicking on the button as I would have
hoped). To
The element is both the field and the button, so I guess a click on
either is a click on the element. There is no way to code an on-click
for just the text area or just the button.

handle this I can check the value. If it is zero length, I send an
alert message indicating to select the Browse button. Once the browse
window pops

That would annoy the heck out of me, why not just do nothing?

I could do that. Since the same people will be using the page I imagine
that it will only take one click in the text box to get the message.

up and a file is select, the new input element is created and onClick
attribute is removed from the element just clicked (this allows
changing that input tag without creating a new element).
But means that the behaviour changes with no sign to the user that it
has. Again, potentially confusing and annoying.

Actually, the behavior does change. The contents of the adjacent text field
box changes. Again, since it's only going to be used by a few people an
explanation of the expected behavior would prevent any confusion. It might
not be totally intuitive but it doesn't have to be.

This works quite well in Firefox. However, it appears that the order
of the event handling is different for IE. In Firefox it appears that
the browse window is displayed first, and once the file has been
selected, the onClick event fires. In IE, it appears that the onClick
event fires first and the browse window isn't displayed until the
event completes.
I think you have a number of usability issues here that can be avoided
by using a separate button to create the extra input. When the button
is clicked, add another input.

I thought about doing that but it would require an extra click to add an
additional file.
You may want to add a 'delete' button too to get rid of extra inputs
that might be created in error - have fun with it! :-)

The server side will handle the form elements with empty text fields so a
delete isn't really necessary. There is also a Cancel button that will
remove all child elements of the "files" element then add one to start over.
Since the page will have limited and predictable usage (it will be used
about 2-3 times a day to upload 2-3 files at a time) I can play a bit with
the user interface without too much consideration for users running on old
browsers. For example, I may add some AJAX functionalit (using Direct Web
Remoting) that will do some filename validation before submitting the form.
After the files are uploaded they'll get renamed using a standard convention
based on some information in a backend database and the "release date"
provided by the users. The release date is selected using JSCalendar.

[John Fereira]

ASM <st*********************@wanadoo.fr.invalid> wrote in news:4318e1f1$0
$1************@news.wanadoo.fr:

John Fereira wrote:

Does anyone have a cross browser solution?
onchange ?

That just might work. I'll let you know.
never I though to use onclick for that filer
(with my IE needs to click overside the field)

I hadn't thouht to use onChange. The element is different from other form
elements in that it produces both a text field and a button but the events
seem to apply to both. An onClick would seem to apply to the button while
an onChange might be more appropriate for the text field.