I need a way to serve files (PDFs) to users through a portlet, but obviously they are private and should only be viewable by the user. Can I use the MWS folder taxonomy for this purpose?
I was streaming them to the UI (thanks for helping with that, Eric) but I’ve run up against IE8’s 32KB URI limit and I’m stuck again. If I could reference the file directly it would be aces.
Any thoughts are most welcome!
Sure, it is possible to store files in the mws content repository that have access control applied to them. However if these are temporary files, you may need to do additional work to remove them at some future time to keep the size of the MWS database from growing.
But, first maybe you could explore some techniques that will make the URL shorter.
For example, for your action URL, most of the parameters on the URL are probably not necessary, so you could try to clear the state from the action url and only add back the parameters that are really required (if any).
IPortletURL actionUrl = createActionUrl();
actionUrl.clearState(); //clear the state from the url
actionUrl.setAXSRFT(true);
actionUrl.setTargetAction("exportPDF_action"); Thanks Eric. The problem with the URL isn’t the parameters, it’s the 1MB+ of base64 encoded data. 
Got an code snippets for loading a file into the repository …and then deleting it?
Thanks!
Lucas.
Ok. I don’t really understand why the encoded data would be on the URL. That seems like a bad idea since you can stream the data directly from the portlet action.
There are several ways to add/remove files from MWS, but maybe the simplest would be to use the Attachment providers.
For example:
PortalContainerAttachmentsProvider provider = new PortalContainerAttachmentsProvider();
//set the attachment container to be the current users root folder
provider.setContainerID("user.current.root");
//add the file
File localFile = null; //[TODO: get local file path here];
String fileEncoding = null; //null for binary file
provider.addAttachment(new URLFileItem(localFile), fileEncoding);
//remove the file
provider.removeAttachment("fileName.pdf");Sorry Eric, not the URL the URI.
[code]
My understanding is the DATA has browser dependent limitations, the most strict of which is in IE8 @ 32KB, so what we did before will work, and works great, but only for small files.
[url]http://en.wikipedia.org/wiki/Data_URI_scheme[/url]
Lucas.
Eric,
I got the attachment working this morning – thanks – but my problem now is there doesn’t appear to be a way to view it in-line.
If I open the result of .getDownloadLink the content is streamed to me, and if I link to the container (.getContainerID) then I see the icon of the content.
Is there a way to link to the file as if it were in the /WebContent/ directory?
Thanks a million…
Whether to open the file inline in the browser or prompt the user what to do with it is controlled by the Content-Disposition http response header.
If you stream the file from a portlet action, the IFileExportBean class used to stream the file has a ‘isDownloadForced’ field you can set to control the content-disposition behavior.
However, if you link directly to a file stored in MWS, the behavior will be determined by how the MWS renderer treats the resource. By default there is a renderer rule for pdf files served from the MWS content repository that forces the file to be downloaded.
To see it or configure the renderer rules login as sysadmin and goto this page:
http://[host:port]/portlet.rulesadmin.renderer
To have different rendering behavior for your files pdf, you would either have to remove the ‘pdf’ renderer rule or create a new renderer rule that is higher in the evaluation order whose target is the ‘content’ renderer (instead of the ‘content-forcedownload’ renderer).
See here for an example of how to stream a PDF from a portlet action and display it inline using the object tag:
After re-reading your question again, I think I may have misunderstood what you were asking.
If you are asking how to get the file content from the attachment, you can get it from the FileItem field of the attachment object.
For example:
IAttachmentItem item = [todo get_attachment_item_from_provider_here];
InputStream fileDataStream = item.getFileItem().getInputStream();I’m attaching a sample CAF portlet project seems to work for me to render a pdf inline.
I may have confused you with incorrect info about the action url. In this case the “fe:” should not be there since it is not needed in this context.
For example:
public String getMyPdfActionUrl() {
try {
IPortletURL actionUrl = createActionUrl();
actionUrl.clearState();
actionUrl.setAXSRFT(true);
actionUrl.setTargetAction("exportPDF_action");
return actionUrl.toString();
} catch (Exception e) {
error(e);
return "javscript:void(0)"; //return a do nothing url
}
}inlinepdf.zip (252 KB)
Thanks for sticking with it, Eric. I sincerely appreciate it.
I understood your Action URL example (from my other thread) and got it working instantly. It’s very clean, thanks.
The problem is…
it seems like the Data URI limitations I mentioned earlier should keep it from working on larger PDFs. This is why I wanted to be able to link to the file directly.
So my questions are:
Do you think the Data URI limitation will come into play?
If so, is there way to link to a file on MWS (as if it were in /WebContent) but also have access control applied such that only the creator can access it?
Thanks a trillion,
Lucas.
Hi Lucas.
Sorry, I had some technical difficulties yesterday so i could not respond.
To answer your questions:
No, in my example, the data attribute of the object tag is just the portlet action URL. The file content was not encoded in the data URI, instead it is automatically retrieved by a second http request that streams the data to the acrobat plugin in your browser.
Yes, files/folders stored in MWS can have access control applied to them. This complexity is not required if you go with the approach from #1, but I can try to dig up an example of programatically changing the access control if you decide you need to go with this route.
No worries, I appreciate the help. No rush.
I guess I’m just confused what the difference is between calling the action URL (as how I’ve done below) and long encoded string. Anyway, it’s fantastic, just can’t wrap my mind around it.
<object data="#{activePageBean.myPdfActionUrl}#view=Fit&scrollbar=1&toolbar=0&statusbar=0&messages=0&navpanes=0" type="application/pdf" width="600px" height="500px"><p>It appears you don't have a PDF plugin for this browser. <a href="#{activePageBean.myPdfActionUrl}">Click here to download the PDF file.</a></p> </object>Thanks a million,
Lucas.