Re: Reporting
От | Andreas Pflug |
---|---|
Тема | Re: Reporting |
Дата | |
Msg-id | 4455F4C5.2010209@pse-consulting.de обсуждение исходный текст |
Ответ на | Reporting ("Dave Page" <dpage@vale-housing.co.uk>) |
Список | pgadmin-hackers |
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
В списке pgadmin-hackers по дате отправления:
Следующее
От: svn@pgadmin.orgДата:
Сообщение: SVN Commit by andreas: r5107 - trunk/pgadmin3/src/base