I have a client who wants just about every grid enabled for Excel and PDF export. The mechanisms that come with the grid are basic. Unfortunately there are many considerations for doing exports from the grid. And then the final document is subject to be treated differently depending on the browser: Does the document get saved or is it opened by an application? Does the PDF launch in the same page, a new page, or in a reader app?
Rather than using the built-in exports, I usually add my own Export buttons and call my own routines for custom reports with fine-tuned formatting. I can completely control all of the above details and all formatting requirements with custom code, but this must be done for each grid and its diverse and unique requirements. But I'd like to know if folks here are getting more "mileage" from the built-in controls.
The most common requirement is that the Excel and PDF should be as WYSIWYG as possible. The user sorts and groups the grid, then clicks Export, and they expect the document to look just like the grid. What we get are documents with columns mis-aligned, funky formatting, awkward grouping indentation, and other artifacts that make the results unusable. I understand the complexities involved in making this stuff work but it looks like this functionality is incomplete in the product, never quite up to speed with the rest of the grid functionality.
So do we just lump it and roll our own? Or is there some other common technique that people use to approach grid exports?
Thanks!
Rather than using the built-in exports, I usually add my own Export buttons and call my own routines for custom reports with fine-tuned formatting. I can completely control all of the above details and all formatting requirements with custom code, but this must be done for each grid and its diverse and unique requirements. But I'd like to know if folks here are getting more "mileage" from the built-in controls.
The most common requirement is that the Excel and PDF should be as WYSIWYG as possible. The user sorts and groups the grid, then clicks Export, and they expect the document to look just like the grid. What we get are documents with columns mis-aligned, funky formatting, awkward grouping indentation, and other artifacts that make the results unusable. I understand the complexities involved in making this stuff work but it looks like this functionality is incomplete in the product, never quite up to speed with the rest of the grid functionality.
So do we just lump it and roll our own? Or is there some other common technique that people use to approach grid exports?
Thanks!
3 Answers, 1 is accepted
0
Hi Tony,
In scenarios where the exported content needs to be customized(like in the particular case) I would recommend doing so by subscribing to the OnGridExporting and OnPdfExporting events. Note that integrating a built-in solution which to automatically customize the exported content is a big effort and may not fit the requirements of all our clients. Every developer may have different preferences on how should the exported content look which will make the logic heavy and slow. Therefore we have exposed a way which allows every our clients to handle such cases according to their requirements. If however you have a certain feature that you think should be implemented I would recommend submitting it as a feature request in our feedback portal.
Regards,
Angel Petrov
Telerik
In scenarios where the exported content needs to be customized(like in the particular case) I would recommend doing so by subscribing to the OnGridExporting and OnPdfExporting events. Note that integrating a built-in solution which to automatically customize the exported content is a big effort and may not fit the requirements of all our clients. Every developer may have different preferences on how should the exported content look which will make the logic heavy and slow. Therefore we have exposed a way which allows every our clients to handle such cases according to their requirements. If however you have a certain feature that you think should be implemented I would recommend submitting it as a feature request in our feedback portal.
Regards,
Angel Petrov
Telerik
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to the blog feed now.
0
TonyG
Top achievements
Rank 1
Rank 1
answered on 04 Feb 2014, 12:32 AM
Thank you for your response Angel. I've only now found time to come back to this - and the client is now focusing on this specific feature.
I understand from your note that there are "different preferences" and that some developers will want to "customize the content".
What I'm suggesting here is that when a user has a grid in front of them and they click the PDF button, that they want to see in the PDF exactly what's in front of them. That's hardly unreasonable and certainly as easy to understand as the term WYSIWYG. My client is now asking me questions implying I don't understand their "simple" request, as they can't understand why something that seems so easy to them should be such a challenge for a seasoned developer. Yeah, it should be easy - just give me what's already on the screen.
The problem for a developer is that we need to track the state of the browser and on a postback we need to guess at the code required to craft stylings which reproduce whatever has already been rendered. I understand that client-side code can change the state of the UI making it a challenge for the server to reproduce the visual features currently being displayed. This isn't the case for components which are entirely managed from code-behind.
It would be ideal to hook into the RadGrid_Render event to capture all data and HTML, and then in OnPdfExporting just send that to a PDF. I understand the problem here is that client-side scripts are rendering data received (sometimes in a browser-specific manner) and that all of the information required to reproduce the controls is not available.
So again, I'm wondering if other developers have found this as much of a challenge as I have, and what solutions have been devised.
The option I'm considering now is to use the state of the user session along with the WebBrowser control. I can open that control to a localhost URL which renders exactly what the user is seeing, but with no grid height and no scrollbars. Upon navigation to that page an image will be captured. This will then be used to generate a PDF with whatever other features are desired. In this regard there is no Telerik handling except the click on the PDF button in the grid. With the PDF on the server we can then send it up to the user, email it, or do whatever else we want.
I would think over the years that a lot of developers have come up with home-grown solutions like this simply because of the inadequacy of the Promethius/RadControls/DevCraft/UI/whatever-we-are-today functionality. And BTW, don't take this as a criticism. I love the products and the company. I'm just saying this one area has never been as developed as most others. Yes, I can submit this as a feature request in the portal but we all know it's going to take a Long time before we get any results on that (consideration, spec, development, QA, beta, docs, production) ... I need a solution right now.
Thanks for your time.
I understand from your note that there are "different preferences" and that some developers will want to "customize the content".
What I'm suggesting here is that when a user has a grid in front of them and they click the PDF button, that they want to see in the PDF exactly what's in front of them. That's hardly unreasonable and certainly as easy to understand as the term WYSIWYG. My client is now asking me questions implying I don't understand their "simple" request, as they can't understand why something that seems so easy to them should be such a challenge for a seasoned developer. Yeah, it should be easy - just give me what's already on the screen.
The problem for a developer is that we need to track the state of the browser and on a postback we need to guess at the code required to craft stylings which reproduce whatever has already been rendered. I understand that client-side code can change the state of the UI making it a challenge for the server to reproduce the visual features currently being displayed. This isn't the case for components which are entirely managed from code-behind.
It would be ideal to hook into the RadGrid_Render event to capture all data and HTML, and then in OnPdfExporting just send that to a PDF. I understand the problem here is that client-side scripts are rendering data received (sometimes in a browser-specific manner) and that all of the information required to reproduce the controls is not available.
So again, I'm wondering if other developers have found this as much of a challenge as I have, and what solutions have been devised.
The option I'm considering now is to use the state of the user session along with the WebBrowser control. I can open that control to a localhost URL which renders exactly what the user is seeing, but with no grid height and no scrollbars. Upon navigation to that page an image will be captured. This will then be used to generate a PDF with whatever other features are desired. In this regard there is no Telerik handling except the click on the PDF button in the grid. With the PDF on the server we can then send it up to the user, email it, or do whatever else we want.
I would think over the years that a lot of developers have come up with home-grown solutions like this simply because of the inadequacy of the Promethius/RadControls/DevCraft/UI/whatever-we-are-today functionality. And BTW, don't take this as a criticism. I love the products and the company. I'm just saying this one area has never been as developed as most others. Yes, I can submit this as a feature request in the portal but we all know it's going to take a Long time before we get any results on that (consideration, spec, development, QA, beta, docs, production) ... I need a solution right now.
Thanks for your time.
0
Hello Tony,
I completely understand your concerns, however with the current implementation of the export mechanism not everything which is visible can be exported out of the box.
For example the sprites and style sheets which the grid uses are not available once exporting is triggered. In order to provide such type of functionality we should rewrite the way the exporting mechanism works from the ground up. Implementing the aforementioned functionality is quite complex and should be carefully planned, as this is not just a small fix or improvement. Also I have to mention that there is a considerable risk of introducing breaking changes that are very hard to be avoided due to the complexity of the functionality in question.
I would suggest that you log this into our feedback portal so it can be reviewed by our developers. Note that when a feature request is made our team thoroughly investigates all aspects of it. Researches what can and what can't be done and approves the request if the functionality can be integrated without affecting other aspects of the already built mechanism.
Finally, I want to thank you for sharing your views on this matter. We highly appreciate any feedback which our clients provide as we are always striving to satisfy their needs to the maximum.
Please excuse us for any inconvenience caused.
Regards,
Angel Petrov
Telerik
I completely understand your concerns, however with the current implementation of the export mechanism not everything which is visible can be exported out of the box.
For example the sprites and style sheets which the grid uses are not available once exporting is triggered. In order to provide such type of functionality we should rewrite the way the exporting mechanism works from the ground up. Implementing the aforementioned functionality is quite complex and should be carefully planned, as this is not just a small fix or improvement. Also I have to mention that there is a considerable risk of introducing breaking changes that are very hard to be avoided due to the complexity of the functionality in question.
I would suggest that you log this into our feedback portal so it can be reviewed by our developers. Note that when a feature request is made our team thoroughly investigates all aspects of it. Researches what can and what can't be done and approves the request if the functionality can be integrated without affecting other aspects of the already built mechanism.
Finally, I want to thank you for sharing your views on this matter. We highly appreciate any feedback which our clients provide as we are always striving to satisfy their needs to the maximum.
Please excuse us for any inconvenience caused.
Regards,
Angel Petrov
Telerik
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the UI for ASP.NET AJAX, subscribe to the blog feed now.