The Problem
When we use the built-in features to render printable pages, we are not making any additional server hits, say, to fetch all rows in a table that is to be included in the printable version of a page. In some cases we may want to have an entirely different layout for the printable version of the page, with additional disclaimer text and other elements.
The Solution
Use an alternative OutputMode to programmatically cause the printable page behavior.
The <af:showPrintablePageBehavior/>does not handle our requirement to hit the server for additional data, the alternative approach would be (depending on your scenario) to use a duplicate page with "email" features that mimics the features of the original page, but with layout that is more printer friendly. Enabling the email features renders the pages exactly as the <af:showPrintablePageBehavior/> would. To do this, you can pretty much copy paste your code as another page(You'll need the pageDef and other related files too), and if you are having a bounded taskflow with jsffs, then the printable page should be a view activity in the unbounded taskflow that can is marked as "Bookmarkable" with parameters, so that the page can take the parameters and load all the data necessary. In the printable page, make sure that the
- data table content delivery is set to immediate and
- the AutoHeightRows is set to the FetchSize and
- the FetchSize is -1 so that all rows will be populated in to the VO that is backing the table.
Once the new "Printable" page is designed, running it in isolation may look fine, but when printing you wil notice that a true printable page behaviour is not produced. eg.: On screen, a table may display 50 rows, but on the paper, it may get truncated at 10. The new page is designed to hit the server to get all the data that we need to display in the printable version of a page. To make it behave like a page produced by the <af:showPrintablePageBehavior/>, we change the OutputMode mark the page as "Email-able" which renders the page in look and behavior like <af:showPrintablePageBehavior/>
You notify the ADF Faces framework to convert your page to be email/printer friendly by appending the following the request parameter to the URL for the page:
org.apache.myfaces.trinidad.agent.email=trueThis causes the page to be rendered as a printable page
You can launch the page in another window by setting the useWindow attribute on the command component to launch a new window/tab in the browser with the printable page. When launching the Printable page, you can include the URL parameters to load the data along with the org.apache.myfaces.trinidad.agent.email parameter.
This works well when you all the details on the printable page can be fetched with a few parameters. The most common example is when you have a master-detail or search/result type page navigation where you have one page that displays a number of records and you choose one record to view in deatil and you need to print the detailed information of that one entity/record (the details page). In this case, the details/Printable page can take one ID chosen from the master/parent/search page and then fetch all related information using that ID in the second page. If however the situation is when a search page is to be made printable, the usual case is that the use wants to save the results from his/her search and exporting the content as excel/html works better.