I just have a quick question about the Reporting components.
In the future will it be possible to put code behind the reports? So we can create reports with customised formatting and fairly complex formulas.
In connection with the previous question will the reports have events and allow you to dynamically connect to a database before the report loads?
One of the things we'd like to do is to have interactive reports where the user can click on a particular data field within the report and it loads the corresponding record within our program. Some reporting components I've looked at before do this within a report viewer event whereas others do it within events of the actual reports.
I'd appreciate any advice you can give.
Many thanks for your time.
James
Hi Regina,
For our first release we'll have interactive filtering using report parameters. The rest of the scenarios you mention are all planned but won't be in our first release.
Thanks,
Andres
Hi Andres,
I would like to pick up on the interactivity issue James raised.
Are there any plans for adding interactive filtering, sorting and grouping to the reports?
Also, will there be support for drilling down into the report, as James asked before?
Thanks, Regina
Hi James,
Thanks for your feedback.
Our current thinking is to try to avoid the code-behind approach. It makes some interesting scenarios really cumbersome, like when you want to have the report definition stored in a database, load it from there, and render it. If the only way to do some tasks was code-behind, then those tasks won't be able to be accomplished in those scenarios.
Our goal is to let you perform those tasks without code-behind. For changing the data source dynamically at runtime, you can use a ReportDataSourceProvider. You can read about it in the docs or see it in the examples (the OrdersReportEntityFrameworkDataSourceProvider.cs class).
For complex calculations and formatting, our goal is to let you bind any property to any expression (which is not possible in the CTP). You can create fairly complex expressions with the expression language, or you could add properties to the classes you are binding to and perform those calculations in the property getters. We think this is a much cleaner/modern approach than code-behind, but we'd love to hear your thoughts about it.
Regards,