Archive

Posts Tagged ‘FileUpload’

XPages: FileUpload Control – replace filename

08/11/2011 1 comment

Today only a little advice.

I had the problem that some uploads failed in an application from time to time. I have used the standard FileUploadControl.

Unfortunately, the error wasn’t really reproducable, therefore I had to do some experiments.

A possible reason for this error were umlauts (we have them in germany, Ä, Ö, Ü) in the filename.

You can change the filename with a standard function of the control, it’s called “Replace file name of uploaded file with the following name”. You can find it in the main properties of the control.
You can also compute that, that works with the following code:

var path:com.ibm.xsp.http.UploadedFile = getComponent("fd_file").value;
var newPath:string = path.getClientFileName();

newPath = newPath.replace("Ä", "ae");
newPath = newPath.replace("Ö", "oe");
newPath = newPath.replace("Ü", "ue");
newPath = newPath.replace("ä", "ae");
newPath = newPath.replace("ö", "oe");
newPath = newPath.replace("ü", "ue");

return newPath;

There nothing special about that, except the class com.ibm.xsp.http.UploadedFile. This class is, in good old IBM manner, not documented. This class gives you some nice possibilities to access the uploaded file, before it is saved in a document.

Here is another interesting article about this topic: XPagesWiki

Advertisements

Stumbling Stone: FileUpload-Control

Today I had a tiny problem. Not even a bug, only a small booby trap.

On my page, I had three FileUpload controls and one FileDownload control. It was specified that a user can upload a maximum of three attachments. Therefore I added a rendering condition to all FileUpload controls, which chekcs the number of attachments in the document.
WARNING: The formula @Attachments doesn’t seem to work properly. It seems like @Attachment only checks the backend-document. I want to know how much attachments were uploaded right now to constrain the possibility to upload something. The function “doc.getAttachmentList(‘feldname’).size()” saved my day.

The three controls are placed below another, the first will be hidden if there are thee attachments, the second if there are two and the last one if there is at least one attachment. All this linked to a refresh, which is fired when you delete one attachment, everything works fine.

However, I faced the effect, if I add 3 attachments at once, only two were saved. The attachment from the last FileUpload control was never saved.

Get ready for the reason:

Controls seem to be processed sequential, connected with an internal refresh. That means, the first control is processed and the file is uploaded -> new there is a refresh -> second control is processed, everything is fine, so the second attachment is uploaded -> there is a refresh again -> third control wants to be processed, but there is more than one attachment in the document, so the control is not rendered anymore, therefore, the third attachment goes to hell.

The solution is quite easy, you only have to reverse the order of the number of attachments in the render condition. That means, the first control should be hidden if there is more than one attachment, the second is hidden with two attachments and the third with three attachments. Because the controls are processed in order they are in the code, everything works fine.

Another interesting fact is, that if you have some mandatory fields or have another server-side validation on your form, attachments are uploaded when you click the save button. After that the validation yells. The backend document doesn’t get bothered, but in the frontend document, there are your attachments uploaded, yet. In the context of my problem above, this could be quite confusing, but if you know that fact you can work around that.

%d bloggers like this: