Обсуждение: Reporting
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 30 April 2006 19:42 > To: Dave Page > Cc: pgadmin-hackers@postgresql.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
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
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 01 May 2006 12:45 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: Reporting > <snip factories discussion> This is done now. Just a tiny duplicate menu problem remains. > > > > 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. OK, I'm a little more convinced of this now. Looking into it... /D