Hello Shannon,

Before approving and scheduling this feature for implementation, we would like to clear up the scenario that requires to have access to the report "layout" and why it might cause further implications.

Based on the information here and in the support ticket #1527900 I understand that by "report layout" you actually mean the report definition, as we call it in our docs. This is the serialized representation of a report instance and for historical reasons it is stored in XML format in .trdx files that back then were produced by the Standalone Report Designer . Later we introduced the .trdp format, where the "p" stands for "package". Basically this is a ZIP-compressed structure that contains the XML definition along with any resources used in the report - inline data, images, localization strings, etc.

When we started working on the Web Report Designer (WRD for short), we knew that XML definitions would just not work fine in JS apps, so we needed a new way of serializing the report. That's why we implemented a JSON-serialization mechanism which is used on the client-side where the WRD operates. We wanted to preserve the interoperability between the report designers and that's why the WRD opens and saves .trdx and .trdp files, while internally on the client everything is presented in JSON format. The default workflow goes like this: when the user opens a report in the WRD, the ReportXmlSerializer deserializes the .trdx or .trdp report definition to a IReportDocument instance. Then the ReportJsonSerializer serializes that instance to JSON and sends it to the Web Report Designer. When the user saves the report, the WRD sends the report definition in JSON format to the ReportDesignerController, where the JSON contents are converted to .XML and saved as .trdx or .trdp.

I'm explaining all this to give you better view on how the different serialization steps are performed. As you can see, on the client (where the WRD works) the report definition is stored in JSON format. If we expose a property that allows to access the report definition, it will contain the JSON representation of the report, which might not be useful.

If I understand correctly, you want to customize the Open/Save logic, which is exactly why we provide the  ability to write your own IDefinitionStorage  implementation, especially for its GetDefinition() and SaveDefinition() methods. Currently they provide only a string as definition identifier, which is not enough in the current scenario. Still, I think this is the place that needs improvement rather than exposing the report definition as a property of the Web Report Designer component.

In this case we can provide a way to extend the report definition identifier to represent a simple structure with properties like User, Category, etc. We can introduce two client event handlers that will be called before the report is loaded in the designer and before it is being saved. In the "beforeLoad" handler the users will be able to resolve the actual report name that will be shown in the WRD. In the "beforeSave" handler the user will be able to create the structure with all the custom properties he needs and process them server-side in the SaveDefinition() method.

Does the approach above fit your scenario and if not, please give more information on how your scenario differs from the one above and what information you would like to persist in the definitionId so it will work in your case? Answering these questions will give us better understanding about such scenarios and will allow us to address the problem correctly, so it will be useful for the majority of our users.

Regards,

Ivan Hristov

Telerik Reporting by Progress