Checking a File Upload Control – Server Side

In my latest escapade, I’m looking to provide an avatar-like feature on a staff record so that staff can upload a self-portrait.  I’m pretty sure most of the staff at my company, myself included, will be unable to resist the urge to change their photo to something immature, but I digress.  Avatars it is.

So, I’m displaying an image from a “Photo” field in the document, and providing a File Upload control for the user to change the image.  Pretty simple stuff.

My first question was around making sure that you only ever have one photo in the photo field, so that we can just upload the first attachment.  A bit of googling took me to a great answer by Mark Leusink on StackOverflow that makes use of the method NotesXSPDocument.getAttachmentList(“rtitem”).  This returns a list of attachments of type DominoDocument.AttachmentValueHolder – this has a property called getState() that tells you if the file is being added by the file upload control.  Brilliant!

var attList = document1.getAttachmentList("Photograph");

for(var i=0; i<attList.size(); i++) {
var att = attList.get(i);

          if (att.getState()==0) {      //STATE_INDOCUMENT: this is the 'old' file: remove it
                document1.removeAttachment("Photograph", att.getName() );
          } else if (att.getState()==1) {       //STATE_ADDED: this is the new file
               //leave it
          }
}

I popped this into the querySave event for my data source, and it works well – but I was rather unimpressed when I discovered that the code dutifully cleared my photo field even when there wasn’t a file in the File Upload.  Of course it did.  Silly me.

So, I needed to check the file upload first and only clear things out if there was a new image on the way.  This turned out to be a little more difficult than I expected.  You can validate the file upload easily enough in client side JS, but I didn’t really want to add client side code or an extra control to act as a flag – that seems too much like the old skool hidden computed fields stuff that we did with Notes client apps.  I wanted to do it on the server side instead.

I went diving, and found a few possible solutions, but nothing that I really liked.  Then I realised that a nice simple solution was staring me in the face – I could use the code I had just discovered to do the check, like so:

var attList = document1.getAttachmentList("Photograph");
var uploading = false;

//First pass - check to see if we are uploading a file
for (var i=0; i<attList.size(); i++){
     var att = attList.get(i);
     if (att.getState()==1){
          uploading = true;
     }
}

//Second pass - if we are uploading, remove everything except the one we are uploading
if (uploading == true){

     for(var i=0; i<attList.size(); i++) {
          var att = attList.get(i);

          if (att.getState()==0) {      //STATE_INDOCUMENT: this is the 'old' file: remove it
               document1.removeAttachment("Photograph", att.getName() );
          } else if (att.getState()==1) {       //STATE_ADDED: this is the new file
               //leave it
          }
     }
}

This is all pretty simple stuff, but it reminds me that I need to put more time into learning about the various methods and properties available in the dim, dark corners of the object model.  I find myself pining for an XPages version of the old-school LotusScript poster that everybody had up on their wall back in the day.  Sure, the 2013 version might be as big as the side of a barn, but I’d still be tempted to find a big enough wall if such a thing existed.