Skip site navigation (1) Skip section navigation (2)

Re: table OCX control

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: 'Tim Finch' <pgadmin(at)timfinch(dot)cix(dot)co(dot)uk>,pgadmin-hackers(at)postgresql(dot)org
Subject: Re: table OCX control
Date: 2002-03-07 11:32:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers

> -----Original Message-----
> From: Tim Finch [mailto:pgadmin(at)timfinch(dot)cix(dot)co(dot)uk] 
> Sent: 07 March 2002 11:01
> To: pgadmin-hackers(at)postgresql(dot)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.
> 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


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

pgadmin-hackers by date

Next:From: Mark A. TaffDate: 2002-03-07 22:24:54
Subject: Re: table OCX control
Previous:From: Tim FinchDate: 2002-03-07 11:20:08
Subject: Re: ViewDesigner Code

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group