Subject: xpage and file upload (unable to upload more than 7 megs) | |
| |
Product Area: Domino Server | |
Technical Area: Application Development | |
Platform: Windows | |
Release: 8.5.1 | |
Reproducible: Always | |
Hi. In short Using Xpage, I am unable to upload anything larger than 7 megs. Even in the Notes Discussion Template, The same problem occurs. I have already set the Http field Maximum size of request content to 25600 in the server doc and also the Domino Web Engine: Maximum POST data (in kilobytes): to 25600 as well. Also, In the Xpages tab from the application properties, I have set the Maximum file upload to 25600. even try to also set that setting using xsp.properties in C:\Domino\xsp\nsf and in C:\Domino\data\properties: xsp.upload.maximumsize=25600 My Upload button use a full update of the page as well. It is working fine with file smaller than 7 megs. I have a file upload control and added a button with the simple action "Save Document" in Xpage. When I select a file larger than 7 megs and click on the upload button, then the browser just never finish to send the page and keep trying to push the page forever and sometime end up with an error message. What can I do to fix that issue? I really need to send larger file. I tried it on Domino 8.5.1 and 8.5.2 as well and got the same issue.
. . More Info (Steve Dionne 2.Dec.10) . . . . Timeout Problem (Paul S. Withers... 2.Dec.10) . . . . . . I tried it and I still have that is... (Steve Dionne 2.Dec.10) |
This is two XPages tips rolled into one prompted by my colleagues Maire Kehoe and Niklas Heidloff.
So the question was how do I upload files larger than 1mb via XPages and how do I increase the timeout limit to allow for slow network speeds when I'm uploading these big files?
So the first part, how do I increase the file upload limit? I posted this a while back explaining how this can be done. There's two parts that need to be done to get this to work. First, you set the size you want of the option 'xsp.upload.maximumsize' in the xsp.properties file (at app or server level). The default being 1024Kb, e.g. xsp.upload.maximumsize=1024.
The second is done on the server document where you got to set a higher level on the HTTP stack. Go to Internet Protocols\Domino Web Engine and set what you need on 'POST Data' in 'Maximise POST data'. The default here is 10Mb.
So that's your limit done.
Now to increase timeout so when I'm uploading those large file it doesn't fallover. The timeout default is 20 seconds in this case, but you may get some cases where it will take longer to upload an p_w_upload. The current way to do this is by using XSP.submitLatency
<xp:scriptBlock id="scriptBlock1"><xp:this.value><![CDATA[XSP.addOnLoad(function(){// change submitLatency to 2 seconds (defaults to 6 seconds):XSP.submitLatency = 5 * 1000;alert(XSP.submitLatency);});]]></xp:this.value></xp:scriptBlock>
In 852* a new option has been added to the xsp.properties which will do the same - xsp.partial.update.timeout
# #######################################
# PARTIAL UPDATE TIMEOUT
# #######################################
# There allows a use to configure the partial update timeout in Designer# The default is 20 seconds #xsp.partial.update.timeout=20
Or you can set the option for just this XPage:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core"> <xp:this.properties> <xp:parameter name="xsp.partial.update.timeout" value="3"></xp:parameter> </xp:this.properties> </xp:view>
The option is in seconds (the submitLatency is in milliseconds).
Hope this helps.
No abstract provided.
| ||||||||||||||||||||||||
Show
Table of Contents
Hide
Table of Contents
Summary: Currently the IBM® Lotus® Domino® 8.5 XPage upload control allows you to upload a file into an XPage application. In certain cases, however, you may want to limit what types of files a user can upload. This article describes how to configure the upload control for your needs and how to alert users when incorrect file types are submitted. IntroductionDoes your application allow users to upload p_w_picpaths, but you find that all types of files are being uploaded? Do you want to prevent users from uploading executable files into your application? This article explains how to configure the XPage upload control, to limit what MIME types can be uploaded into your application. MIME, or Internet Media Type as it is now referred to, describes the content that is being uploaded into your application. Adding the upload control to your XPage or custom controlYou can add the upload control to any XPage or custom control by simply dragging it from the core controls panel in Lotus Domino Designer and placing it in the desired location (see figure 1). Figure 1. Upload control in an XPage To limit the file upload control to accept only a certain MIME type: 1. Once you have the control in place, select the Properties tab > All Properties for the control (see figure 2). 2. Under the Property column, select the accept property, and then click on the Value column. You will see a drop-down list of default file types from which to choose. Figure 2. List of default file types This is fine if you want the file upload control to accept only one MIME type, but what if you need a MIME type that is not listed, or you need to accept multiple MIME types? In these cases, you can compute the value of the accept property so that you can accept a file type that is not listed, or accept multiple file types. To do this, click on the blue diamond (on the far right-hand side in figure 2 above) and select compute value. If you want the upload control to accept only p_w_picpaths, you can compute the value as shown in figure 3, separating each MIME type with a comma. Figure 3. JavaScript expression to compute the accept property value Click OK; you now see the computed value for the accept property in the Value column, as shown in figure 4. Figure 4. Computed value displayed in Value column Using the file download control to find MIME typesWhat if you want to add a new MIME type but are unsure what the MIME type is for a given file, such as a PDF? To help in figuring out what a MIME type is for a given file, you can use the file download control along with the file upload control to display the MIME type for any file (see figure 5). Figure 5. File download control from a Web browser To add the download control to your XPage or custom control, simply drag the control from the core controls panel in Lotus Domino designer and add it to the desired location. Once you've added the control, under the Properties tab, select File Download, and in the Options section make sure Type (the default) is selected (see figure 6). Figure 6. File Download options Now, before restricting the upload control to certain MIME types, you'll be able to verify the MIME types before you add them to the upload control.
If you are configuring the upload control to accept only certain MIME types, you may want to alert users when they try to upload a file whose MIME type is not allowed for upload. To do this: 1. Add the message control to your XPage or custom control. 2. Next, under the Properties tab, select Display Error, and in the Name field enter a name for the control. 3. Click on the drop-down for the “Show error messages for” field andbind it to the field that would generate an error in the case of the upload control (see figure 7). Figure 7. Message control configuration Once the message control is configured, you'll see the following message if, for example, the upload control does not allow MIME types of text/plain:
With the new XPage upload control you now have greater control over what type of files your application will accept. This provides greater flexibility, for example, by ensuring that only p_w_picpath files are uploaded when you ask for a profile photo or ensuring that only spreadsheet files are uploaded when you request expense reports.
Notes and Domino information center: http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp IBM Lotus Support document, “Knowledge Collection: XPages”: http://www-01.ibm.com/support/docview.wss?uid=swg27014929 IBM Lotus Support document, "Preview in Web Browser" option grayed out for custom controls”: http://www-01.ibm.com/support/docview.wss?uid=swg21366584 About the authorKevin Giles is an IBM Advisory Software Engineer currently working as an application developer and system administrator for the IBM developerWorks® Lotus Web site. He joined Iris Associates, now part of IBM, in 1997, where he worked on the original Notes.net Web site. In past roles he also worked as a quality assurance tester for Lotus Domino. Kevin is an IBM Certified Advanced Application Developer. ResourcesConclusionNotifying the user when an invalid file is submitted
|
I decided to make the control easy to drag and drop onto any XPage after speaking with Niklas Heidloff from IBM. He was filling me in on all the changes coming soon to OpenNTF.org and I felt it was important to contribute to the efforts that are underway.
About the Multi Attachment Custom Control
This custom control uses a central p_w_upload repository db for all the p_w_uploads for your application. It allows the user to add as many p_w_uploads to a document as they want by clicking the "Add New Upload" button . Each p_w_upload is a separate document in the p_w_upload repository and is linked back to the document using the document's universalID. The custom control uses a repeat control to repeat a description and download control for each p_w_upload.
The parameters I added allow you to specify the location and name of the repository database as well as control the various features of the file download control. The repository contains a single view and form. You can place that view and form into any database to create the repository.
Here's a screen shot of the custom control being used on an XPage that tracks Project information:
Here's a screen shot showing the parameters:
Descriptions of the available parameters
Parameter | Description | Type |
fileUploadDbName | The db name that will store the p_w_uploads. Include the full path from the Notes data directory. | string |
hideIfNoAttachments | Controls the visibility of the download control if there are no p_w_uploads | boolean |
showCreatedDate | Controls the visibility of the column for Creation date | boolean |
showModifiedDate | Controls the visibility of the column for Modified date | boolean |
showSize | Controls the visibility of the column for Attachment size | boolean |
showType | Controls the visibility of the column for Attachment tyope | boolean |
You can download the control here: http://www.openntf.org/Projects/pmt.nsf/ProjectLookup/XPages%20Multi%20Attachment%20Custom%20Control .
You can read more about how the control was built by clicking here: http://www.jmackey.net/groupwareinc/johnblog/johnblog.nsf/d6plinks/GROC-7G3GF7
Please feel free to contact me if you have any issues or questions.....
* Please Note: There's an updated version of this control Published on OpenNTF.org
Overview:
XPage Custom Controls allow you to build your own controls for reuse. They show up in the control palette and can be dragged and dropped on any page just like any of the other controls. The concept is similar to a subform in Domino.
I was demoing XPages to a group of colleagues the other day. I was showing an example of the repeat control, which allows you to repeat a group of other controls based on a formula or value. The neat thing about the Repeat control is it can dynamically creates controls at runtime. One of the the guys asked about using the control to generate unlimited file upload controls for storage in central repository database. I thought... wow, that is a great use case for an example (thanks Mark). It was very quick to build too.
Let's start out with a look at the completed custom control:
After dropping it on an XPage, here is a screen shot of the control in use. You can see that 3 files have been uploaded already and the user clicked the "Add New Upload" button a 4th time and is presented with a blank upload control plus a description field:
The "Add New Upload" button creates a new document in the FileUploadDB database with a reference to the current document's doc ID. The page is then reloaded and the repeat control creates a new blank upload control bound to the new document. A simple JavaScript save() uploads the p_w_upload.
You can drop this control anywhere on your page(s). The only additional item that is needed on your page is a field calculating the document's docUNID (2nd to last screen shot below).
Here are the steps to build the control:
In your database, under Database Navigator select "Custom Controls" then click "New Custom Control". Provide a name for the control.
Drag and drop a Button control on the page and for the label enter "Add New Upload". Select the Event tab and provide the following formula for the event. This will create a new p_w_upload document in the repository and reload the page:
*note: for this example the p_w_upload repository is named "FileUploadDB.nsf" in the Domino root directory
Next drag a Repeat control to the canvas. Select JavaScript for the Iteration and enter the following for the formula. This formula looks up the associated p_w_uploads and generates an array of docIDs based on the document collection:
Enter the following for the Repeat control options. The "docid" variable will contain the docUNID for each document:
*note: I do limit the amount of uploads to 30. I think that's enough...
Next drop a Panel control into the Repeat control. Set the Datasource as follows:
Set the Document Id to be computed. The Document ID will be the "docid" variable from the Repeat control:
There is one property we do have to set that is not obvious if you are starting out with XPages and Panels. That is to: "ignoreRequestParams". The reason for this is we are setting the Document ID and default Action for the Panel ourselves and do not want the Panel to pick up these parameters from the request. Here is a screen shot of how to set that parameter:
Drop a "Table control" to the Panel, 1 row by 2 columns. Now we need to add our controls to the Table. Add an "Edit Box", "File Upload" and "File Download". Here's a screen shot of the bindings for the controls:
Description Edit Box Control:
FileUpload Control and FileDownload Control both have the same bindings:
For the FileUpload control we want to hide the control after one file has been uploaded. We only want one p_w_upload per repository document. Here is a screen shot of the Visibility formula and where you would set that:
Set the opposite logic for the FileDownload control, that is return false if there are 0 p_w_uploads.
Place a Button control in the second column labeled "Upload". Set the same visibilty formula as the FileUpload control. It has a very simple formula which saves all data sources. You could substitute a simple action here if you prefer:
On the form where you will use the new MultiUpload control, I use the universalID for the link between the document and the p_w_upload. I placed a hidden Edit Box control on the page with the following Default value formula:
Lastly, here is the Attachment form in the FileuploadDB.nsf repository. I have a view sorted by ParentUNID named "vAttachmentLkUp":
That's it! It really is very minimal the amount of work involved. It took less than an hour for me to do. I am sure the interface could use a little bit more work, but I think it makes for a great example.
The one issue I had seemed to be a bug where I could not place the FileUpload control as the first control in the Panel. I ended up putting the Description first and that seemed to fix the issue...very odd issue. I posted the problem to the 8.5 Beta forum.
Download it and try it out. Hopefully seeing these techniques solving a real business need will start you thinking about other uses for this technology. Let me know if you have any questions....
* Please Note: There's an updated version of this control Published on OpenNTF.org
Overview:
XPage Custom Controls allow you to build your own controls for reuse. They show up in the control palette and can be dragged and dropped on any page just like any of the other controls. The concept is similar to a subform in Domino.
I was demoing XPages to a group of colleagues the other day. I was showing an example of the repeat control, which allows you to repeat a group of other controls based on a formula or value. The neat thing about the Repeat control is it can dynamically creates controls at runtime. One of the the guys asked about using the control to generate unlimited file upload controls for storage in central repository database. I thought... wow, that is a great use case for an example (thanks Mark). It was very quick to build too.
Let's start out with a look at the completed custom control:
After dropping it on an XPage, here is a screen shot of the control in use. You can see that 3 files have been uploaded already and the user clicked the "Add New Upload" button a 4th time and is presented with a blank upload control plus a description field:
The "Add New Upload" button creates a new document in the FileUploadDB database with a reference to the current document's doc ID. The page is then reloaded and the repeat control creates a new blank upload control bound to the new document. A simple JavaScript save() uploads the p_w_upload.
You can drop this control anywhere on your page(s). The only additional item that is needed on your page is a field calculating the document's docUNID (2nd to last screen shot below).
Here are the steps to build the control:
In your database, under Database Navigator select "Custom Controls" then click "New Custom Control". Provide a name for the control.
Drag and drop a Button control on the page and for the label enter "Add New Upload". Select the Event tab and provide the following formula for the event. This will create a new p_w_upload document in the repository and reload the page:
*note: for this example the p_w_upload repository is named "FileUploadDB.nsf" in the Domino root directory
Next drag a Repeat control to the canvas. Select JavaScript for the Iteration and enter the following for the formula. This formula looks up the associated p_w_uploads and generates an array of docIDs based on the document collection:
Enter the following for the Repeat control options. The "docid" variable will contain the docUNID for each document:
*note: I do limit the amount of uploads to 30. I think that's enough...
Next drop a Panel control into the Repeat control. Set the Datasource as follows:
Set the Document Id to be computed. The Document ID will be the "docid" variable from the Repeat control:
There is one property we do have to set that is not obvious if you are starting out with XPages and Panels. That is to: "ignoreRequestParams". The reason for this is we are setting the Document ID and default Action for the Panel ourselves and do not want the Panel to pick up these parameters from the request. Here is a screen shot of how to set that parameter:
Drop a "Table control" to the Panel, 1 row by 2 columns. Now we need to add our controls to the Table. Add an "Edit Box", "File Upload" and "File Download". Here's a screen shot of the bindings for the controls:
Description Edit Box Control:
FileUpload Control and FileDownload Control both have the same bindings:
For the FileUpload control we want to hide the control after one file has been uploaded. We only want one p_w_upload per repository document. Here is a screen shot of the Visibility formula and where you would set that:
Set the opposite logic for the FileDownload control, that is return false if there are 0 p_w_uploads.
Place a Button control in the second column labeled "Upload". Set the same visibilty formula as the FileUpload control. It has a very simple formula which saves all data sources. You could substitute a simple action here if you prefer:
On the form where you will use the new MultiUpload control, I use the universalID for the link between the document and the p_w_upload. I placed a hidden Edit Box control on the page with the following Default value formula:
Lastly, here is the Attachment form in the FileuploadDB.nsf repository. I have a view sorted by ParentUNID named "vAttachmentLkUp":
That's it! It really is very minimal the amount of work involved. It took less than an hour for me to do. I am sure the interface could use a little bit more work, but I think it makes for a great example.
The one issue I had seemed to be a bug where I could not place the FileUpload control as the first control in the Panel. I ended up putting the Description first and that seemed to fix the issue...very odd issue. I posted the problem to the 8.5 Beta forum.
Download it and try it out. Hopefully seeing these techniques solving a real business need will start you thinking about other uses for this technology. Let me know if you have any questions....
The issue with the File Download control in XPages is that it does not launch Microsoft p_w_uploads properly when using Internet Explorer. The secondary issue is that it throws an exception if your database is in a subdirectory. You can read the details here in the 8.5 Discussion forum .
Last week Irina Kojevnikova posted a solution to the problem . Her solution overrides the File Download control's HREF for each p_w_upload.
Here is a description of the solution:
On the All Properties tab for the File Download control, there is a property fileNameHrefValue which is computable.
The JavaScript for the value computes the url for each p_w_upload by referencing the current row using the data->var property value rowData. As the control loops through the p_w_uploads, we can get the name of each p_w_upload by using rowData.getName(). Now we can use the filename to build a new url for each p_w_upload.
The data var property is set on the All properties tab under the data section.
The end result is a url similar to: http://localhost/TestDiscussion.nsf/0/A8364817576EF43F852575A30043E76D/%24FILE/JohnExcel.xls
One issue I could not completely resolve was that if the user attaches files and the document has not been saved yet, the new url will not work since it is using the universalID. Most likely the person that uploads a file will not try and launch it immediately, though they might want to delete it. So I replaced the href with "#" if it is a new document so there will not be an error message if the user clicks on the file...it will do nothing. If anyone has a suggestion on a different approach, please let me know.
I updated the discussion8.ntf template with the fix and you can download that here: discussion8.ntf . You will need to sign the database with a production id for use on your server, or sign the 3 custom controls I updated: mainTopic, response, and viewTopic. I also updated my Custom Control for storing file p_w_uploads in a central database with the fix.
Thank you to Irina for putting together a solution! Also, a special thanks to Richard Cotrim who spent some time this weekend testing the solution.
- 1 Restrict the size of uploaded files
- 2 Limiting file types for upload
- 3 How to process an uploaded file
- 4 How to enable large file uploads in Domino
Restrict the size of uploaded files
Set in Application Properties -> XPage Properties -> File Upload max size .
Limiting file types for upload
You can set define which file types are allowed to be uploaded in the upload control -> all properties -> basics -> accept.
Read details in Domino Designer Wiki.
How to process an uploaded file
Place code like this in the beforeRenderResponse event of an XPage to get a handle to a just-uploaded file:
var con = facesContext.getExternalContext();
var request:com.sun.faces.context.MyHttpServletRequestWrapper = con.getRequest();
var map:java.util.Map = request.getParameterMap();
var fileDataName = "file"; //name of the POST request parameter that contains the file
var fileData:com.ibm.xsp.http.UploadedFile = map.get( fileDataName );
var tempFile:java.io.File = fileData.getServerFile();
The file is in the "xspupload" directory on the Domino Server and has some crypting filename. You can get the original filename with fileData.getClientFileName().
For example, you can attach the file to some Notes document with code like this:
var correctedFile = new java.io.File( tempFile.getParentFile().getAbsolutePath() + java.io.File.separator + fileData.getClientFileName() );
var success = tempFile.renameTo(correctedFile); //rtFiles is a rich text item on a notesdocument of your chosing rtFiles.embedObject(lotus.domino.local.EmbeddedObject.EMBED_ATTACHMENT, "", correctedFile.getAbsolutePath(), null);
correctedFile.renameTo(tempFile);
This snippet renames the temporary file to the orginal filename, attaches it to a RichText item and renames it back to the cryptic name (so that it will be deleted by Domino after processing).
How to enable large file uploads in Domino
Open the server document in the Domino Directory, go to Internet Protocols/HTTP and then to the "HTTP Protocol Limits" section.
Set the fields "Maximum size of request content" and "Maximum POST data" to the same value (for example 20.480 for a 20MB limit).
Then set this limit in your application in Application Properties -> XPage Properties -> File Upload max size.
- 1 Restrict the size of uploaded files
- 2 Known Bugs for upload control
- 3 Workaround for known bug in download control
Restrict the size of uploaded files
Set in Application Properties -> XPage Properties -> File Upload max size .
Known Bugs for upload control
The option "replace file name" does not work in 8.5. Fix is planned for 8.5.1.
The submit/save button needs to do a full refresh, not a partial refresh.
Workaround for known bug in download control
If your application is in a subdirectory on your domino server the download control does not work, it presents wrong paths to the files. This is a known bug and is planned to fix in 8.5.1.
John Mackey found the following workaround:
- go to all properties of the download control
- set all properties -> data -> var to "rowData"
- navigate to fileNameHrefValue property and add the following javascript:
if (!@IsNewDoc()) {
return "0/"+datasource.getDocument().getUniversalID()+"/<dollar>FILE/"+rowData.getName();
} else {
return "#";
}
Important: replace "<dollar>" with the dollar char!!!
Replace "datasource" with your actual datasource in your XPage.
Details and screenshots: http://www.jmackey.net/groupwareinc/johnblog/johnblog.nsf/d6plinks/XPages-File-Download-Control
转自:http://www.cnblogs.com/hannover/archive/2011/3/4.html
转载于:https://blog.51cto.com/subform/975063