In this thread, Doug Chasman wrote:

You are correct on the controller lifecycle - the request to get the content to be converted to pdf is a separate HTTP GET request and the viewstate/controller is not preserved on a GET. This is primarily because of some internal Visualforce details and does not have to be this way forever but it is going to be this way for awhile.

For now you will need to manage data passing yourself, e.g. either by using query parameters or using an sobject(s) that have been saved (this will be visible to the PDF generation request).

We just ran into this - I have a StandardSetController extension which backs a visualforce page. The controller acts on the selected records from a standard list view page (via stdController.getSelected()), and then renders a page with a bunch of data from those selected records.

The page works 100% fine if it is not rendered as pdf, but as soon as I throw the "renderAs="PDF"" in the page tag, the selections get lost and no relevant data is displayed.

If what Doug says is correct, is there a recommended way around this if the controller is managing a large amount of data? Is the solution really as Doug says, to use query parameters or saved SObjects?

Since we will have this need in several pages, I am thinking of implementing a general purpose "presisted developer hashmap" for passing data to PDF controllers. It would basically consist of a master-detail relationship between 2 objects, something like ApexRequest and ApexRequestEntry.

ApexRequest is just a header, maybe we add an "expireDate" to support periodic data cleanup. ApexRequestEntry has just 2 custom fields, probably both strings, as a key/value pair.

Our standardSetControllers that need to render PDF's will do whatever pre-processing / data retrieval they need to do and then put the results in a bunch of ApexRequestEntry objects under a single ApexRequest. They will then render a PageReference redirect to the actual PDF-backing page controller, passing the ID of the ApexRequest as a query parameter. Then the controller for the PDF can read all the key/value pair entries and do what it needs to do. For most of the stuff we're envisioning, the ApexRequestEntry objects would just hold other SObject ID's as values, and the target PDF controllers would know to use them in aggregate as the various "IN" clauses for their queries.

It is a pretty elaborate fix, but we will need to do this in quite a few places and I don't want some hack solution that involves every controller parsing a 32k text field :)

Has anyone found a more elegant solution for this dire limitation of PDF-backing page controllers?

Salesforce doc team, if you are listening, this limitation REALLY needs to be documented! It is not mentioned in any of the 4 pages in the VF guide that refer to PDF generation. It cost my team a couple hours in debugging before realizing it was purely related to the renderAs attribute changing controller behavior.

Jeremy Kraybill
Austin, TX