Re: table OCX control

> -----Original Message-----
> From: Tim Finch [mailto:pgadmin@timfinch.cix.co.uk]
> Sent: 07 March 2002 11:01
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] table OCX control
>
>
> Dear all,
>
> Firstly may I apologise to Mark. The work I outline in this
> message was
> done before I realised you had already made the first version of the
> DataWidget ocx control. I had totally missed it.
>
> http://www.fosterfinch.co.uk/pgadmin
>
> The site has a link to a screen grab of my first table ocx
> control design.
> it has absolutely no code in it yet.
> Things to note, and for discussion
> - Tables will be able to be themed (blue, red, white,
> yellow), wher the
> background colours all change to that theme, if the user
> wishes to, in
> order to spot tables quicker in the designer
> - Bold fieldnames are Primary Keys
> - italic fieldnames have some form on constraint other than FK on them
> - underlined fields are FKs
> - tick boxes on left do what MS SQL designer does, selects
> fields for display
> - White boxes at end of fieldname line tell you the column type in
> abbreviated form (i8 - Int8, Vc - Varchar etc.)
> - The idea will bwe that when the user hovers over one of
> these a pop up
> tells you additional info like Varchar length, or check/FK
> constraint details

Cool.

> Thoughts:
> - Mark, I see you have fleshed out more on the code side of your
> datawidgets, I will use these methods/props etc where
> feasible. I feel that
> my design of the datatable ocx is a bit more clean and less
> fussy. As the
> designer is going to be pressured for screen space at the top for the
> tables we are going to need to keep the tables small.
> - I know the wish list for pgAdmin contains the idea of a
> project file in
> the future. This is going to be a key requirement, esp where query
> designing is concerned as the user will position tables and
> colour them
> etc. and will want this to be retrieved. Surely one of the
> best places to
> keep the project file is actually in a table in database
> itself? In the
> meantime, what will we do about storing the non SQL aspects of a view
> design for retrieval later on - simply save them to a .pvd
> (PgAdmin View
> Design) file on the local drive of the user?

We should try to keep everything in the database to allow for
multi-developer environments. One thing I learned from pgAdmin I is to keep
the SSOs (server side objects) as simple a possible and only use them where
absolutely necessary. pgAdmin I had about 8 views, 8 functions and 3 tables
which were a real pain in the arse to autoupgrade and repair. Many people
didn't like them either because they cluttered up their databases.

In pgAdmin II, the only SSO is pgadmin_rclog (the Revision Control log)
which was kept as simple as possible, yet as future proof as possible. This
is only created when RC is enabled on a database, and is dropped if it is
disabled. We need to make sure that any more SSOs we add are as friendly...

All sounds good though - look forward to some working code.

Regards, Dave.