Re: Reporting - Mailing list pgadmin-hackers

From Dave Page
Subject Re: Reporting
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4011CA074@ratbert.vale-housing.co.uk
Whole thread Raw
In response to Reporting  ("Dave Page" <dpage@vale-housing.co.uk>)
List pgadmin-hackers

> -----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

pgadmin-hackers by date:

Previous
From: svn@pgadmin.org
Date:
Subject: SVN Commit by dpage: r5112 - in trunk/pgadmin3/src: frm include
Next
From: svn@pgadmin.org
Date:
Subject: SVN Commit by dpage: r5113 - in trunk/pgadmin3/src: frm include main