FormsService renderPDFForm how to use an xdp from repository?

[AlexanderWillet]

Hi,

I would like to use the renderPDFForm method from the FormsService to render a PDF. As input I would like to use an XDP stored in the crx repository. This is a very plain use case I think. To my surprise the renderPDFForm method accepts as input parameter only a filesystem path or a url. (see http://helpx.adobe.com/aem-forms/6/javadocs/com/adobe/fd/forms/api/FormsService.html)

To feed an xdp from repository into that method it would be necessary to

a) load the xdp from repository and temporaily store it to the filesystem to be able to use a filesystem path or

b) compose a url like http://localhost:4502/content/dam/forms/testform.xdp to be able to use a url.

Both approaches are not very elegant. a) doubles all forms in an external filesystem and b) causes lots of trouble because of anonymous access and acl restrictions.

Can someone please outline me a best practice?

Btw: the corresponding OutputService.generatePDFOutput() accepts a docmanager document as input xdp. This can easily be created from a content path and works fine.

Any help is appreciated!

Cheers

Alex

[althea_uxa]

Great, just what I was searching for.

[nitinn18425437 · Accepted solution]

Hi Alex,

Yes, you can access xdp from repository also in renderPDFForm. renderPDFForm recognizes crx:// prefix. So, if you specify path as crx:///content/dam/forms/testform.xdp    ,renderPDFForm will read xdp at /content/dam/forms/testform.xdp in the repository.

Thanks

Nitin

[AlexanderWillet]

Yeah, this works!

Thank's for the quick response and this tip.

Alex

[DarrenBiz]

nitin.nizhawan wrote...

Hi Alex,

Yes, you can access xdp from repository also in renderPDFForm. renderPDFForm recognizes crx:// prefix. So, if you specify path as crx:///content/dam/forms/testform.xdp    ,renderPDFForm will read xdp at /content/dam/forms/testform.xdp in the repository.

Thanks

Nitin

Hi Nitin,

I think this is a very important use case and should be much better documented within the API. Can we start getting some of these things that seem obvious to the development team put into the API as notes or examples? I know there is a tradition with Livecycle API's to be sparsely documented, but we need these kinds of things noted by the developers to save us a lot of time.

Thanks