Reporting

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Reporting
Date: 2006-04-30 19:46:17
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4011CA044@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
> Sent: 30 April 2006 19:42
> To: Dave Page
> Cc: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: Lightspeed for frmQuery and other issues.
>
> Ok, I see that method, and see it used 4x in pgObject, but
> dunno what it's about. A quick glance makes it appear strange
> to me, as all xxReportYY methods in pg* files. Can't comment
> on what they're doing.

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.

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.

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?

In related news, the scripts look handy, but don't seem to work if there
is only one script option on the menu, and the report options are being
repeated now, though that doesn't really matter of course.

/D

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message svn 2006-04-30 20:13:06 SVN Commit by dpage: r5106 - in trunk/pgadmin3: . src src/db src/dlg src/include src/utils
Previous Message Andreas Pflug 2006-04-30 18:42:13 Re: Lightspeed for frmQuery and other issues.