Board index » delphi » Re: Generic Report Class

2004-04-01 09:47:41 AM
delphi279
Ritchie Annand writes:
content will always be a DataSet?
Thanks for your comments Ritchie.
--
Erick Sasse
 

Erick Sasse writes:
interface for both paper reports drawn "by hand" in Delphi code,
QuickReports and Excel reports.
Today I'd probably have declared an IReport interface, and access
reports through this interface.
Typically (IMHO, that is) it is not the report *itself* that benefits from
implementing an interface or deriving from a common ancestor report, it's
the application.
I've written a few report interface classes (and failed a few times), and I
believe I have come to the following conclusion:
Application's requirements on reports are highly different. The differences
may be fundamental, like:
- where data is retrieved from (a TDataSet type component or in-memory data
structures)
- whether the report itself or application's data sources define what's to
be produced ("Report this dataset" vs. "Get the required data to fill in
this report")
- "Reports are custom designed by hand in reporting tool" vs. "Report's
layout is calculated by application"
- "Export formats are handled by reporting tool" vs. "Reports are to be
reproduced iun different formats"
- There may or may not exist a metadatabase providing info on formatting of
fields
- "Starting point" of the report may be a simple set of parameters, like
"Sales 2002", or it may be deeply nested into the application context (all
kinds of parameters areretrieved based on context)
- Data structures may be static, or they vary over time or diverge in
different installations
As you'd probably guess, I have given up a generic reporting interface. The
only one I have reused is a simple routine / set of classes being able to
create an Excel report form a TDataSet or a TStringGrid. But that is OOP ...
nice, generic classes....and then start all over again in the next project
;-)
--
Regards,
Bjørge Sæther
XXXX@XXXXX.COM
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.
 

In article <406b74bd$XXXX@XXXXX.COM>, XXXX@XXXXX.COM
says...
*always* be a DataSet?", but for most peoples' purposes it will be.
The second question would be "will the content always be a SINGLE
dataset?", which might be a more pertinent question (and the followup
question, "Will your boss ever change their mind?" :). If you might have
any levels of master-detail, they might work better wrapped in something
that can keep all the DataSets together.
The third question would be "are you creating the reports on the fly, or
are they pre-defined somewhere?". If they're always pre-defined, and you
set which predefined item it is in properties or constants, then you're
probably doing yourself a disservice trying to make a generic framework
out of something that is not generic at all :)
(If you had the names in text files or something, however, wrapping that
little bit of effort might make it worth wrapping classes around)
Creating object-oriented classes yourself only truly benefits when you
can take away some of the effort or some of the duplication of code,
either now or in future maintenance. If you end up setting the same
number of properties and calling the same number of (or more) methods,
and it isn't any clearer, then it is probably not a good candidate.
There may be other, better candidates in the code somewhere :)
To get back to your question, it doesn't matter much whether the
ReportContents are a property or a parameter, really. If it is truly a
DataSet, then you can put it in as a DataSet into the base class and
refactor later if things get more complicated :)
-- Ritchie Annand
Senior Software Architect
Malibu Software & Engineering Ltd.
Business: www.malibugroup.com
Personal: nimble.nimblebrain.net
Wiki: wiki.nimblebrain.net
 

Ritchie Annand writes:
--
Erick Sasse
 

Thanks Bjxrge! :)
--
Erick Sasse