Deployment example and Report Builder OO
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.
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.
This discussion has been closed.
Comments
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
http://www.digital-metaphors.com
info@digital-metaphors.com
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.
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.