Home General
New Blog Posts: Merging Reports - Part 1 and Part 2

Deployment example and Report Builder OO

edited July 2002 in General
Dear All,

The Developer's Guide PDF mentioned several ways to deploy the reports:
...
A. Compile Reports into the executable
B. Compile Reports into a package
C. Distribute Report Template Files
D. Distribute Report Database
...
I am very interested in any examples on method B and C.
Is there anyone out there who have implemented something like these?
I don't think RB's demo come with these examples, but if I'm wrong,
please point out where I can find them.

In Method C, the Developer's Guide also said :
...
Place all the data access components for the reports in a data module.
Place a single report component that uses the data module on the form.
Create all of the report layouts via this one report component, saving each
one down to a separate report layout file. When it is time to print the
report, load the report from file and call the Print method.
...
I'm wondering whether this is a good idea. When we provide an event handler
for a component in the report designer, the code is placed in the form. If
you have lots of reports, this will mean that all those event handler's code
is going to be sprinkled all over the form, which is a nightmare for
maintenance. I hope someone can enlighten me on how we can use proper
Object-orientation in creating reports with RB. I have a whole hierarchy of
generic report object (with custom parameter asking/handling; "report
explorer" functionality, automatic timestamping and logging, security, etc)
implemented with QR (crazy, I know,... that is why I'm thinking of moving to
RB now...:). At first I thought that it will only involve redoing the report
layout and event handlers, but unfortunately Since RB doesn't support Visual
Form Inheritance, I'm completely at loss at how I can proceed.

Thank you very much in advance,
salam,
sugi.

Comments

  • edited July 2002
    B. You can compile your application with run time packages, just as you
    would in any Delphi app. This would let you make your app more dynamic in
    that you could replace the report package at a later time if you setup the
    app's architecture to support hot swappable packages as Mark Miller is
    always demonstrating at BorCon. We don't have a demo of this approach, but
    it would be a good one. Thanks for pointing this out.

    C. If you have lots of event handlers, then it is probably better to use
    separate report objects and locate their event handlers in separate forms,
    as shown in our main reports demo project. As far as distributing report
    templates, they can be placed in files (.rtm) or in a database. To use one
    report object, the event handler problem is solved in the same way: use RAP
    in ReportBuilder Enterprise. It allows you to store the calaculations inside
    of the templates, so you do not have to tie template reports to delphi event
    handlers. You can if you would like to, but you don't have to. If there is
    something in RAP that we don't support, then you can create a RAP pass
    through function to execute delphi code or you can extend the RTTI for RAP
    to include new classes. There are demos of both of these approaches in the
    RAP demos directory in your RBuilder installation.

    You can use visual form inheritance for report components, but you can't
    place data pipelines in the ancestor form.


    Cheers,

    Jim Bennett
    Digital Metaphors

  • edited July 2002
    Hello...
    Thank you very much for the reply.

    I have never been to BorCon, and I have some doubts about the 'hot swappable
    packages' concept. But that's a question for the delphi newsgroup..:)
    Thanks for clearing this up.

    I don't suppose we could have a demo in, say, the next couple of weeks ? :)

    Aaah... So this is the reason I've been getting strange Access Violations on
    rtl60.bpl.

    My previous report forms (QR) is 'self-contained', in the sense that the
    report templates, data access components, etc, are encapsulated inside the
    report form. Now if I can't have the Pipeline component on the same form as
    the Report component, my only choice would be to move all data access
    components (datasets and the pipeline) into a TDataModule, leaving only the
    report component and the event handlers on the form.

    The arrangement seems a bit 'strange', I'll think more about it tomorrow
    morning.
    Thank you!

    Salam,
    sugi.
  • edited July 2002
    Hello...
    Thank you very much for the reply.

    Unfortunately I have never been to BorCon, and I have some doubts about the
    'hot swappable
    packages' concept since I've read postings about having to compile everytime
    things change on
    either side of the fence, but I guess that's a question for the delphi
    newsgroup..:)
    Thanks for clearing this up.

    I don't suppose we could have a demo in, say, the next couple of weeks ? :)
    What I wanted to know is whether RB imposes any restrictions in the design
    of the packages.

    Aaah... So this is the reason I've been getting strange Access Violations on
    rtl60.bpl.

    My previous report forms (QR) is 'self-contained', in the sense that the
    report templates, data access components, etc, are 'encapsulated' inside the
    report form. Now if I can't have the Pipeline component on the same form as
    the Report component, my only choice would be to move all data access
    components (datasets and the pipeline) into a TDataModule, leaving only the
    report component and the event handlers on the form.

    The arrangement seems a bit 'strange', I'll think more about it tomorrow
    morning.
    Thank you!

    Salam,
    sugi.
This discussion has been closed.