Report Architecture Questions

2 posts, 0 answers
  1. E Pons
    E Pons avatar
    16 posts
    Member since:
    Apr 2010

    Posted 13 Oct 2010 Link to this post


    I'm a brand new Telerik Reporting user working on a WPF/Entity Framework project which will eventually have ~250 reports.  We're using VS 2010 with the latest Telerik Reporting release.  I'm researching how to best set up the report architecture for easiest maintenance, most reuse, and fastest speed when developing and testing reports.  So far, we've created a BaseReport which inherits from Telerik.Reporting.Report and contains StyleSheet rules, methods to programmatically create Report and Page Headers/Footers, and other multi-purpose user-defined functions.  Any other report will inherit from the BaseReport.  This approach is seems workable for the most part, but I'd greatly appreciate input about a couple questions:

    1. General Design: Does anyone see issues with our approach?  Is there a better way to achieve the goals above?

    2. StyleSheets: I'd like to utilize the BaseReport's StyleSheet directly, assuming it should be available via inheritance, but the styles defined in the BaseReport don't seem to be recognized in the reports which inherit from BaseReport.  I understand an ExternalStyleSheet can be utilized.  However, this is less than ideal because I believe the ExternalStyleSheet needs to be manually added to each new report.  Also, the styles aren't visible in the "StyleSheet" property.  Whatever the solution is, we need to make sure that later changes to the global StyleSheet will be reflected in previously existing reports. 

    3. VS Template: When I create a new report using the Telerik Reporting Template in VS, there are a number of changes I need to make each time.  Can the VS Template be modified to avoid this repetition or is there another recommended technique?

    Thanks much!!

  2. Derek
    Derek avatar
    118 posts
    Member since:
    Oct 2008

    Posted 04 Dec 2010 Link to this post

    I'd be interested in any feedback you get on this as well; the lack of a strong inheritable architecture seems to be a weakness in the reporting environment. Most corporate users will have certain criteria that needs to be consistent from report to report, and there doesn't seem to be anything to easily manage that kind of hierarchy.
  3. DevCraft R3 2016 release webinar banner
Back to Top