Configuring file uploads

To create a field for uploading files in the Web UI Framework, use the File Upload Widget, which is an extension of the textfield control in Ext JS.

The following graphic shows an example of a file upload control created using Ext JS (the Attach Photo control). In a web browser, the input field is used as a file. The following graphic shows a text field with a Browse button. When you click Browse, a file selection dialog box opens. The dialog box is operating system-specific and cannot be customized.

File Upload

You also need to adjust the following properties in yfs.properties to configure file uploads.

Use the sc.file.upload.maxfilesize and sc.file.upload.maxfilesize.table_name properties to specify the size of files that can be uploaded.

Use the sc.file.upload.allowedfiletypes and sc.file.upload.allowedfiletypes.table_name properties to specify the type of files that can be uploaded.

Use the sc.file.upload.dir property to specify a directory that will temporarily hold uploaded files.
Use the sc.file.upload.type property to decide when to upload the file to the server.

With the Web UI Framework, the filter mapping of the Struts filter and the Struts-cleanup filter's <url-pattern> should be changed from * to *.do so that the upload servlet requests do not pass through the Struts filter. If the URL pattern is not changed, then the file upload request gets parsed before it hits the upload servlet, in which case the file will be lost. The following code shows how to set this up:

{{{
   <filter-mapping>
          <filter-name>struts</filter-name>
          <url-pattern>*.do</url-pattern>
   </filter-mapping>
   <filter-mapping>
          <filter-name>struts-cleanup</filter-name>
          <url-pattern>*.do</url-pattern>
   </filter-mapping>
}}}

In WUF file uploads, the following happens:

File validation for type is performed. Validations are done also on the server side for the name and file type. Size validation is not possible in the browser.
The files are placed within a subdirectory of the temporary directory that is specified in the sc.file.upload.dir property in the yfs.properties file ({sc.file.upload.dir}/{App_Server_Name}/{userID of the user uploading the files}/{session ID of the session which is uploading the files}). The App_Server_Name, userID, and JsessionID values will be stripped of all special characters.
The internal data value of the file upload widget (FileUploadField) is changed to SCFile:<Element_ID>. For example:
```
{User : { 
      UserId : "user1",
      attachFile : "SCFile:ext-comp-1037"
   }
}
```

After files are successfully streamed to the server, the FileAttachments element with the file information (such as unique file ID, file location, and widget ID) is appended to the screen's data object that is used in the upload. The actual API call to send file information to the database is made with this input.
The following shows the change for a sample data model after appending the information:
```
{User : { 
      UserId : "user1",
      attachFile : "user1_1267599880675_1"
   }
FileAttachments : {
     FileAttachment :
       {
        file_id : "user1_1267599880675_1",
        file_path : "att2.bmp",
        Element_ID : "ext-comp-1037"
       }
    }   
}
```

An API failure occurs when:

There is a failure to send across files to the server.
There is an exception while trying to persist files in the database as part of the API call (that is, after the files have been placed successfully on the server).

Events are called when files are deleted from their temporary location on the server.

Securing file delete

The ISecureFileDelete Interface allows you to securely delete a file that is uploaded to the temporary server location. Use the following property in the yfs.properties file to plug in the ISecureFileDelete Interface:

sc.secure.file.delete.impl=/*

Ensure that sc.secure.file.delete.impl=/* is a fully qualified path to the Java™ class implementation of the ISecureFileDelete Interface. The ISecureFileDelete Interface definition has a method, which must be implemented:

         +
                   /**
                    * @param file is an existing file which has to be deleted
                    * from temporary location of the server. This method
                    * implementation gets called only when file exists
                    * on the server location. 
                    * @return true if the file delete is successful, false otherwise.
                    */
                    boolean deleteFile(File file);

By default, secure file delete is available. A default implementation for secure file delete is plugged in. The default implementation class is 'com.sterlingcommerce.woodstock.util.frame.file.impl.PLTSecureFileDeleteImpl'. If the plugged-in implementation class is invalid or not accessible, the file is deleted using the Java File Delete API.