When I create file download control on a document I can display the attached files from a Rich Text Field.
In a separate process I am attaching more documents to the same document. I want to periodically refresh the download control container to see if there are new attachments. I do not want to do a full refresh of the page.
I have discovered that the partialRefresh of the file download control container either programmatically or manually does not result in the contents (downloadable files) being accurately updated.
XSP.partialRefreshGet('view:_id1:fileDownload1')
A full refresh of the screen shows the newly attached documents but I want to be able to partial refresh the panel container and see the new documents without full page refresh.
I have added a Random() computed text value into the panel and I can see that it is being refreshing correctly. I have even looked at the xhr response from the server and I can see that there is an update being made - but not with the new attachments in it - the "attached files" are not refreshing without full page refresh.
I can only assume this is a feature of the filedownload control in that it does not know that new files are attached at any other time other than page load.
Suggestions?
When partially refreshing a XPage, the datasources are not reloaded, only their last state (stored in memory or hdd ) is restored. If you change the scope of your datasource to request, the XPages engine is forced to recreate the datasource instead of using the cached one on each request (which includes partial refreshs).
This should allow you to refresh your fileDownload control without a full refresh.
Marky,
Yes, I have run into this before. You must do a full refresh with attachments.
http://xpagesblog.com/XPagesHome.nsf/Entry.xsp?documentId=FBAC0D921B677EA0852578CB006678D7
The link is fairly old, but I believe it still applies.
Matt White says in the article comments: "...Basically it is not currently possible to post a file attachment over AJAX, you either have to use Flash or a virtual iFrame solution if you don't want the entire page to refresh. As far as I know there is nothing that IBM can do about this at the moment.
Matt"
Related
The context here is that, in a CMS type of app, the users that create content like to reproduce Notes' way of having attachments anywhere in the text, not just a list of attachments at the bottom of the page. When creating a page, they want to be able to create links to the attachments right away, using a link and an img tag, not saving the document first and then edit it again.
I have found the YouAtNotes HTML5 Multi File Upload control, which enables the users to upload the attachments before the document is actually saved. The URL for attachment uploaded befor ethe doc is saved is then:
http://myserver/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I use this URL in the CKEditor to create an image and it looks OK: the image shows up in the editor and has this URL:
/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/insanity.jpg
I then save the document, and it still looks good. The image is showing up and the URL is still:
http://myserver/mydb.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I close my browser, and open up the page again, and now I see that my image is not showing up, but the URL is still:
/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
But if I look at the URL that is used by the download control, this is what is has:
http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg
Why did it change?
Is there documentation on how that whole attachmentprocess works, so I can understand it and give proper indications to the users so they can create valid links.
We also have a particularity in our publishing code: we need to keep the UNID of the published document so links that were made using UNIDs are still working. It is an app with a lot of content and many external apps link to it. So when we publish, we actually copy all the content of the draft into the already published document, so the UNID is different from the draft document, and we have issues with attachment links because of that. But that is something else...
The URL "/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg" relates to a temporary location before the docment has been saved. This is standard functionality because
For SSJS / Java to save an file into an NSF, it's got to have been uploaded to the server prior to the commit.
The user has not chosen to save the file yet, so it shouldn't be added to the NSF.
The document hasn't been saved yet, so even if it should be saved to the NSF, no document yet exists to save it to.
The components of the URL are:
"/Belair/xBiblio.nsf", the URL of the database it will finally need to be committed to.
"xsp/.ibmmodres/persistence", a URL that corresponds to a physical folder location where temporary files for this NSF are stored, based on xsp.properties of the NSF; if nothing is defined in xsp.properties of the NSF, xsp.properties of the server is used; if nothing is defined there, a default location is used.
"DominoDoc-NEW_569", a temporary reference to the new, unsaved dominoDocument datasource. If you close the browser and re-open it, you'll be getting a different temporary dominoDocument datasource reference, so I wouldn't expect the image to show up. Otherwise, different users could get one another's attachments.
"-Body", the field the file needs saving into.
"/indifference.jpg" the file name.
Once the document is saved, the file is stored into the Body field of the relevant document, and the file system cleaned up. The URL has to change, because otherwise the attachment would not be available on other replicas, because only the database gets replicated, and it could not be managed by DAOS.
The new URL "http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg" corresponds to:
"myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment", shorthand URL to open the relevant attachment.
"/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE", the location of the document the attachment is stored in.
"/Body", the field name.
"/indifference.jpg", the attachment name (the field could have multiple attachments, of course).
The information above is based on what has been documented in XPages Portable Command Guide (for xsp.properties settings for changing the default temporary locations) and Mastering XPages 2nd Edition.
I'm not sure what the YouAtNotes uploader does, so I can't say whether it should be changing the URL or not on save. But in more recent versions of Domino, attachments can be uploaded without a full refresh, which may be of use as an alternative.
When you're copying documents, if you're storing HTML that references images by their URLs, including UNIDs, you'll need to modify those references.
If you want to keep UNIDs, remember that they are read-write - you can set them as well as get them. However, bear in mind that you'll have problems if you change the URL to the same URL of an existing document. Bear in mind this is also XPages, so the data accessed via the XPages applications don't have to be in the same database.
I want to rewrite the lotus notes workspace using xpages.
So far i am successful but one feature is giving me quit a headache.
How can i access the database icon of a lotus notes application.
I tried to access: http://notespath.mydomain.com/$icon. That problem with that is that
it is not using the login from the current session to access the database and
retrieve the icon. Instead it tries to get it using the anonymous id. If the
anonymous id has no access to the database i get a popup to login.
My question is: Is possible to do this with the user that is logged in to the xpage
or is there is a way to export the database icon into a notes document.
Try following instructions here:
How to extract Lotus Notes database icon?
This should give you a method to get to the DXLExporter, and it looks like the icon is in the IconBitmap object. You're still going to get .ico files out though, which aren't ideal, but could be a good starting point for what you're trying to do here.
As Aaron Brake commented, XPages engine cannot access old Domino URL format for icon. Also see this: Image URL when previewed in Notes and in Web Browser
In our applications we use dedicated 32x32 PNG image resource (img_DBIcon) which is used in XPages. Developers need to maintain this image resource.
What´s about if you change your URL to a database icon??
Don´t use http://notespath.mydomain.com/$icon
Try http://notespath.mydomain.com/DB.nsf/$icon
When you click on the link for an attachment in the File Download control in XPiNC, you are promoted to save the attachment. Is it possible to configure the File Download control to open the attachment directly instead of prompting the user to save it? We're using 8.5.2 FP3.
Handling of an "attachment" is primarily done by the Browser (XPiNC being a firefox browser inside Notes). If for example, a PDF plugin is installed in the browser and the servers sends the corresponding "application/pdf" mime-type with the file, the browser uses that plugin to display the file. The correlation between mime-type and plugin or external application in the browser is something the server/webapplication can not influence.
What you can do on the server side is sending the mime-type "application/octet-stream" instead of the one corresonding to the file type, causing the browser to display the "Select application or download" dialog. So in Xpages, you would have to redirect the download through a XPage, where you set the corresponding HTTP Headers as shown in Set cache headers on an XPage and How to force PDF files to open in browser?
I haven't used the file download control or XPINC, but it is definitely possible to make your xpage or view control open an attachment directly. This method bypasses the download control.
Please see this post from Stephan Wissel: http://www.wissel.net/blog/d6plinks/SHWL-86QKNM, which gives you some SSJS that you can use to build the URL. You can use it in the onClick method of a button. You are essentially duplicating the functionality of the download control in a way that does what you want it to do.
If you want to do the same thing from a view control, then see this post: http://notesspeak.blogspot.com/2013/02/how-to-launch-attachment-from-view.html
Note that different browsers behave slightly differently but it works in all the majors.
Michael,
Here is code I used:
var unid = rowValue.getUniversalID()
var url = getAttachmentURL(unid, "storetransfer.pdf", "Testing//test.nsf")
url = "/" + url + ";"
view.postScript("window.open('" + url + "', '_blank', 'height=120,width=650,top=10,left=10,resizable=yes');");
I did modify Stephan's code a bit since my data is in a different NSF than my code. You probably know this but the view.postScript allows you to call clientside javascript from SSJS. It always is the last thing to run, hence the name. This is the same code from the Notesin9 video mentioned in the comments. I just tested this and it works like I think you want, but in firefox it does try to block the popup, and then has to push "open". Hope this helps.
What can we do about connection reset error that domino sends back to our application after submiting attachment which size exceeds limit of request size? We use standard upload control.
Is there anything that will allow us to handle this error? At this moment this is a very serious problem because it can lead to data loss.
You can check if your browser supports the html5 files API. When yes - checking the file size before upload is possible (there is an example on so somewhere). Other than that I second Ferry's suggestion
I don't use Xpage actualy, but i ve got a similar problem in domino 6.
To correct this limit, i use a temporary document in a pop-up. The attachement is saved in the temporary document, and an agent copy the attachement from the temporary document to the final document when the user save is document.
Another agent delete temp documents each night.
I hope that will hep you.
The upload limit could be set in Application Properties in the tab Xpages and there is a 'Maximum Post Data' setting on your website document on tab 'Domino Web Engine'.
I wrote a free async file upload control for Xpages, where you can prevent the user to upload too big files before the upload starts. You can download it here
I'm currently implementing the OpenNTF Multiple File Uploader by Mark Leusink.
This very nice custom control uses an xAgent to embed the selected file attachment into the target Notes document. Everything was working fine until I added Authors and Readers fields to the Notes documents. Now I'm getting a security error (402) when uploading the file.
My thought is the Upload xAgent can't edit the target document to attach the file. If I remove the security fields, everything works again.
My question is, do xAgents run with the same security as the current user? If not, can I set a "run as" user for the xAgent like I can for a Lotus Script agent?
I'd suggest that you look at the xAgent's code and rewrite it to use sessionAsSigner to access the database/document to upload the file. This will cause it to run as the signer of the application and bypass the security issues that your running into.
Both Tom's and Declan's answers are correct, but this doesn't count for the file uploader.
It uses a Flash component to do the actual uploading (called SWFUpload). Since browser cookies aren't shared with Flash, it can't send along the user's session cookie with the file and therefore to the Domino server the user performing the upload is nog logged in (aka Anonymous). That's why the uploader requires anonymous users to be allowed to read/write public documents in the ACL and the XPage/ XAgent handling the uploaded files (aUpload.xsp) is set to allow "public access users". It uses the sessionAsSigner object to access the database's content
Normally, the above settings would allow everyone to anonymously upload files. That's why I implemented a custom authentication solution based on an idea by Mark Barton: before every file is uploaded, a request is made to an XPage to retrieve a unique key. That XPage (aGetAuth.xsp) does run under the user's credentials and stores the key in a document in the database. This key is send along with the uploaded file and compared with the stored key. The upload is only allowed if the keys match.
First thing I'd check in your case if the code in the aUpload.xsp XAgent can read and write the target document using the sessionAsSigner call.
Mark, Declan, and Tim, thanks for jumping in.
I modified the xAgent **aGetAuth.xsp** to use sessionAsSigner to get the current database. At first I got the error "sessionAsSigner not found".
Google showed a quick answer was to re-sign the template before testing. After re-signing the template, twice, and preforming a "clean" everything works brilliantly.