One of the problem around the file upload functionality is that there is, no matter what, a file size limit set on the server. The limit could be 100Kb such as 100Mb depending on the configuration of the server.
But what happens if the user tries to upload a file bigger than the limit?
It’s simple, the file is going to be uploaded on the server until the limit is reached. Once it happens, the server returns an error message to the client.
Well, this is not ideal!
Indeed, depending on the connection speed of the user, the error message could be displayed a few minutes later. And you know how impatient users are!

So obviously, the solution would be to validate the file size before the upload starts.
To do that, we can simply use the fileSize Javascript function against the upload field.
But, surprising enough, this function doesn’t work on Internet Explorer!

And the only solution I found to get the file size with IE was using ActiveX:

var oas = new ActiveXObject("Scripting.FileSystemObject");
var e = oas.getFile(document.forms[0].file.value);
var size = e.size;

Finally, here is the whole Javascript function to validate the file size:

function validateFileSize(file, maxSize) {
	if (navigator.appName=="Microsoft Internet Explorer") {
		if (file.value) {
			var oas = new ActiveXObject("Scripting.FileSystemObject");
			var e = oas.getFile(file.value);
			var size = e.size;
		}
	} else {
		if (file.files[0]!=undefined) {
			var size = file.files[0].fileSize;
		}
	}
	if (size!=undefined && size > maxSize)
		return false;
	return true;
}

with file the file input field to validate and maxSize the maximum size in bits.

For example, you can call this function as follow:

validateImageSize(document.forms[0].file, 500000)

I successfully tested this code on:

• Google Chrome 6;
• Firefox 3.6;
• Internet Explorer 6;
• Internet Explorer 7.

These tags allow to display information about the first FacesMessage that is assigned to the component referenced by the “for” attribute. The difference is that the RichFaces tag has some extra functionalities such as Ajax rendering, error markers and predefined css class names.
Have a look at the following page for more details: http://livedemo.exadel.com/richfaces-demo/richfaces/message.jsf

This is all nice and well but it is not the only difference. Indeed, the HTML code generated by both these frameworks will also be different!

First of all, let’s see how the tag <h:message styleClass="errormsg" for="element"/> will be transformed. If there is no message to display, nothing will be generated (which is a good behaviour). However, if a message is present, the tag will be replaced by the following HTML code:

<span class="errormsg">Required.</span>

So far, so good!

But now let’s check what code RichFaces is generating for the tag <rich:message styleClass="errormsg" for="element"/>.
The following is the code created if there is NO message to render:

<span class="rich-message errormsg" id="form:j_id255">
    <span class="rich-message-label"></span>
</span>

And here is the code which will replace the RichFaces tag if there is a message to display:

<span id="bookingform:j_id255" class="rich-message errormsg">
    <span class="rich-message-label">Required.</span>
</span>

As you can see, the main difference is that RichFaces is wrapping the original span tag into another span tag. But, it is also generating some code even if there is no message to display! You would ask why is it doing that? The response is simple. The wrapper span element is necessary for RichFaces to Ajax-render the message tag if an error message has to be displayed for the targeting element.

So make sure you don’t put any padding or margin style in your custom CSS class which I called ‘errormsg’ in my example. Otherwise, you might have a gap when you were expecting nothing… (this happened to me)

For the others, I will talk about the JavaScript event onclick which is not fired when the following requirements are matched:

• In a form;
• There is only ONE input text element;
• There is one button which has an onclick event assigned;
• You press the ‘Enter’ button inside the input text element.

For a better understanding, let’s now take the following example:

<html>
    <head><title>Test</title><head>
    <body>
        <form>
            <input type="text" id="t1"/>
            <input type="submit" onclick="alert('onclick fired!'); return true;"/>
        </form>
    </body>
</html>

As you can see, there is nothing difficult in this code.
Well, that doesn’t mean Internet Explorer can handle it…

The bug occurs if you press the ‘Enter’ button inside the input text element using Internet Explorer. Indeed, the onclick event is not fired and the text ‘onclick fired!’ is not display to the user! However, it works perfectly fine on Firefox and Safari.

The funny thing is this code works on Internet Explorer if you add another input text, even if it is hidden!
Why? Don’t ask me!

Anyway, the following example works on IE:

<html>
    <head><title>Test</title><head>
    <body>
        <form>
            <input type="text" id="t1"/>
            <input type="text" style="display:none"/>
            <input type="submit" onclick="alert('onclick fired!'); return true;"/>
        </form>
    </body>
</html>

Why are we assigning an onclick event to the submit button?
It could be for a lot of reasons, but the main one is probably to validate the form before submitting the data.

By the way, RichFaces is very often using this event on the submit buttons.
So remember to add a hidden input text to your form if you want to allow users to use the ‘Return’ key.