views:

352

answers:

1

I have a rapidly growing set of Telerik reports in my web project. My data providing strategy is that each report has an companying text file containing a SQL query. I handle complex filter criteria, like long 'x is in(y,z,a,b,c....)', or '((x=1) and (x < y))', repeated a hundred times, by doing text substitutions on a text file query before using it to get a DataTable for the report.

All reports are classes that derive from Telerik.Reporting.Report, which have limited properties that serve as report meta-data, such as business title of the report, vs. the report's programmatic name. There are no fields for attributes such as a report category, the name of the SQL query file for the report, possible alternate viewing page for the report, the subset of common filter parameters to be disabled for the report, etc.

I find the first candidate solutions here unattractive, viz. creating and maintaining a 'report settings' store, either in a file, web.config, or a database table. This store is divorced from the actual reports, and working in them or the store requires frequent and annoying context swaps.

My more favoured idea is to use something similar to the Dynamic Data meta-data scheme, where an attribute on the entity class ascribes another class to hold meta-data for the entity. I could also extend Telerik.Reporting.Report, adding maybe a dictionary for attributes I want to attach to reports, and derive all my reports from that.

Any criticism on my current thinking, or suggestions on other options, will be appreciated.

A: 

Since Telerik Report definitions are nothing more than pure C# / VB classes, you should be able to use any "standard" C# approach for including meta data with your reports. In your derived report classes, you can add any fields or proprieties you need to manage your settings, or you can try to create a more "elegant" solution by extending Report in your project.

The current version of Telerik Reporting does not offer a native metadata solution for setting report attributes, but it is a very interesting idea. I have asked the Telerik Reporting team to weigh-in on this idea, so they should provide more guidance soon.

In the mean time, I think you are on the right track with your planned "Report base class" that will make it easy for all project reports to set the necessary "settings" values.

Todd