Re: Reporting

Dave Page wrote:
>
>
> Right, let me give you a quick rundown on whats /currently/ there as
> this may affect how things can potentially work with the factories.
>
> - pgObject and each derived class return a report menu for the current
> object using GetReportMenu (in pgObject) and GetObjectReportMenu (in the
> derived class)
>
> - Standard reports (ie. Properties, stats, dependencies) are implemented
> in pgObject. To avoid code duplication and ease the chore of adding new
> properties, rather than reimplement functions like
> ShowStatistics/ShowDepends in report format, we simply pass a pointer to
> the listview control on frmMain to
> frmReport::AddReportTableFromListView(), which creates a table in the
> rpeort mimicing the list view.
>
> - Object list reports are only apppropriate in pgCollections of course,
> and thus are implemented at that level.
>
> - Object specific reports (currently there are none, but a Table Data
> Dictionary is first on my list) would be implemented in the appropriate
> object class.

ok

>
> Now, for the future...
>
> Reimplementing the menus making full use of the factories should not be
> a problem.
>
> You mentioned implementing reports in frmReport. That seems wrong as it
> means that it will need intimate knowledge of each object type. It seems
> to me that this info should be encapsulated within the object or one of
> it's base classes such that frmReport remains generic, and
> object-specific code is self contained.

Well, so far there's no object specific stuff. I'd prefer object
extensions that are not rendering/output format specific, and thus don't
call back frmReport methods but merely deliver the data for frmReport to
render.
>
> That said, the generic reports that are there now could go in frmReport
> as they only need knowledge of frmMain (which I see is passed to
> StartDialog anyway). This would also work for the list reports that are
> currently in pgCollection as that can be tested through IsCollection().
>
> Sound reasonable? Anything important I obviously haven't thought about?

Sounds ok.

>
> In related news, the scripts look handy, but don't seem to work if there
> is only one script option on the menu,

Hu, thanks. Will fix.

and the report options are being
> repeated now, though that doesn't really matter of course.

I already removed some of that new object style handling stuff, probably
failed to put it in back when backing out my menu change attempt.

I still do have a little problem of the overall feature. I do understand
the need for reports, but the current approach seems quite limited to
me. In general, I'd expect that reports on single objects are not too
helpful; a quick glance at a property window should be enough in most
cases. I'd expect something like "list details on all functions in
schema A and all sequences and tables in schema B" as typical
requirement for a report on an application's db schema definition,
probably embedded in some explaining text, and with a table of contents,
printed as PDF. This is quite hardly done from report snippets that are
rendered full HTML.

It could work like this:
- generate XML report snippets on everything needed in a directory, or
appended to a common file.
- When all snippets are collected, render it to whatever is desired with
XSL.

I don't object having a "made HTML" option as it is now, but this would
mean a second output option, and we certainly won't like to have all
objects with specific reporting facilities recoded each time a new
output format is introduced; a good reason to deliver data only from
objects, not made lines of report.

Regards,
Andreas