XWiki 4602: Error exporting live table to PDF #132
Conversation
…livetable macro if the action is 'view').
…ge instead of a failed livetable in the export).
|
This is not very user friendly, and not a lot better than the current version (although I admit at least now it no longer looks like an error). Sometimes the person reading the exported PDF won't even have access to the actual page, so sending them to look there for the data won't do any good. Also, the message is not true. The livetable can be exported, but no one wants/has time to do it :) In my opinion (from the user perspective), Vincent's second suggestion is the best way to go. At some point in the future there could be some higher upper limit for the number of table rows that can be displayed in without stressing the system and exhausting the user's patience. |
|
I agree. But it means making a request, parsing the JSON results (which can be customs) and display them properly. And what should we export, all the rows or only 20 of them because it's the default livetable display? I think my hack is not the cleanest solution but at least it is better than the actual behaviour. |
|
No, you should not make a request and parse the JSON. The proper solution is for the data to be directly available as JSON from the serverside. It already is computed as JSON, just that it isn't properly exposed. |
|
How can I do that ? getRenderedContent() ? How can I specify that I want the "plain" output syntax? And I add all the needed variables (that are usually passed in the query string) in the velocity context? |
|
These changes are not needed anymore now that the PDF Export Application can include content generated dynamically with JavaScript. |
Display an error message in the export instead of a broken livetable.