Обсуждение: 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 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? Hope this input helps get ideas rolling. Tim.
> -----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.
I'll do a better job of quoting below. :) -----Original Message----- From: pgadmin-hackers-owner@postgresql.org [mailto:pgadmin-hackers-owner@postgresql.org]On Behalf Of Tim Finch Sent: Thursday, March 07, 2002 3:01 AM 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 <Mark>Sounds great.</Mark> 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. <Mark>Tim said: 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. Mark's reply: I don't think we are going to pressured at all for space. The form opens up at the current default of 80% of available screen space, and all but one pane can be hidden by the user. So they could easily have just the diagramming pane take up their entire screen, if they wanted the room. </Mark> - 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? <Mark>All the view designer stuff can easily be regenerated based on a .sql file or the reverse-engineered SQL code, with the exception of the placement and other changes the user made to the layout of the diagramming pane. That should indeed be saved in the database, I think.</Mark> Hope this input helps get ideas rolling. Tim. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
I like the control. Some discussion points: 1. I think the control need to be resizable, both by a minimize button and by border dragging. 2. I like the notion of each instance of the control having the appropriate icon (table, view, function, etc). 3. The diagramming pane should also have scroll bars, as required. I don't recall off the top of my head if it is there yet or not. 4. What are your plans/thoughts on linking entities? For example, in a standard diagramming section, I think FK relationships ought to be rendered graphically between objects. In the pane for the view designer though, the user ought to be able to draw the relationship and modify them to show inner, outer, cross joins, etc. Your thoughts? Regards, Mark -----Original Message----- From: pgadmin-hackers-owner@postgresql.org [mailto:pgadmin-hackers-owner@postgresql.org]On Behalf Of Tim Finch Sent: Thursday, March 07, 2002 3:01 AM 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 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? Hope this input helps get ideas rolling. Tim. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>Mark's reply: I don't think we are going to pressured at all for space. The >form opens up at the current default of 80% of available screen space, and >all but one pane can be hidden by the user. So they could easily have just >the diagramming pane take up their entire screen, if they wanted the room. ></Mark> Thats good. Its just the default opening workspace is 1/4 to each pane, and realistically they will need the diagram, field selection and possibly SQL panes open all the time. I agree the results pane is optional for design time. ><Mark>All the view designer stuff can easily be regenerated based on a .sql >file or the reverse-engineered SQL code, with the exception of the placement >and other changes the user made to the layout of the diagramming pane. That >should indeed be saved in the database, I think.</Mark> Your right, it was the diagramming pane I was referring to. Also the idea of theming the table controls with the colour idea ought to be a database scope setting (or optionally database scope) rather than View scope, would mean some concept of a central 'project file' into which modules and functions in pgAdmin have tyhe ability to write their settings, a sort of 'Registry' but stored in the pgsl backend. In fact if we came up with a method of doing it Registry wise then something like the view designer could determine its own 'hives' and 'keys' and not care how, for example, the left hand tree view in pgAdmin stores its own project related settings. What do you think Dave/Jean? Tim
At 14:35 07/03/2002 -0800, Mark A. Taff wrote: >I like the control. Some discussion points: > >1. I think the control need to be resizable, both by a minimize button and >by border dragging. Yes. However I thought this might be best implemented by the DiagramView (DV) control into which the DataTable (DT) OCXs will be drawn, the DV setting the properties of the DTs as the user redraws them. The Min button - do you meana form of roll-up like Dreamweaver etc. ? I was also thinking the other day that DT objects should have a 'size' property where the object can be drawn at one of say three different font-size sizes. For example if you were making a View based on two main tables plus a third linking table that is simple a M-M relationship breakdown with the PKs of each main table, you might set this to the 'small' size and use B/W colour scheme, showing its fields in a smaller point size, and thus taking up less room, but the main tables appear in 'Medium' or 'Large' size, and using the colour theming to show them in colour. In this way, is a minimise button so necessary, I'm in two minds. >2. I like the notion of each instance of the control having the appropriate >icon (table, view, function, etc). Yes that's a good idea. Functions however, are these going to appear in the top window as a diagramming object? Surely they will just get referenced in the 'select columns' grid underneath? I'm not fully au fait with PostgreSQL functions yet - can the return a recordset that cen be used in a query, i.e. can they be used as a table in FROM...JOIN statement? Surely the diagram pane is simply for graphical representation of the FROM...JOIN statement? >3. The diagramming pane should also have scroll bars, as required. I don't >recall off the top of my head if it is there yet or not. You're right, Yes it should and no its not. Now to this end, whats the gas on us using commercially available OCX controls. I have a legal bought copy of VSView, which contains an OCX that is a 'scrollable pane' - it takes care of all that side of things. There are no financial licensing issues with distributing it, but the problem of course is its unlikely you guys have a developer's license for it... Thought I'd ask. >4. What are your plans/thoughts on linking entities? For example, in a >standard diagramming section, I think FK relationships ought to be rendered >graphically between objects. Oh exactly! Just like MS Access query Designer and SQL Server designer. The lines will be drawn between fields that are 'joined' and the line will indicate clearly, graphically, any constraint settings that make a difference. The line should also indicate clearly if the relationship infers 1-M, 0/1-M, 1-1 etc. etc. again inmuch the same way MS Access does. My thinking for coding this is that the DV object when wanting to draw a line will ask a DT object at what Twip position from the TOP setting will it find the 'node point' to start drawing the line from for given field 'fldFieldToDrawFrom'. Similary the DV will ask the next DT what the node point is for the line to draw to and then the line is drawn between them using the standard VB Line OCX. Then some maths works out other geometric object positions to graphically represent the 1-M, 1-1 stuff, and any text that may need to appear etc.etc. >In the pane for the view designer though, the >user ought to be able to draw the relationship and modify them to show >inner, outer, cross joins, etc. Indeed. Classic Drag/Drop should work here to enable the ability of coding this. We also have to deal with the issue that MS Access deals with in that if we import two Tables into a View design which have a pre defined FK between then, whether we assume this FK reference is the intended FROM...JOIN required for the view. In my experiebnce with Access this is 80% often what you need with the ability to delete the line in the View Designer when not required for the odd query where you need to do something else. Tim.
> -----Original Message----- > From: Tim Finch [mailto:pgadmin@timfinch.cix.co.uk] > Sent: 08 March 2002 11:54 > To: Mark A. Taff > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] table OCX control > > > You're right, Yes it should and no its not. Now to this end, > whats the gas > on us using commercially available OCX controls. I have a > legal bought copy > of VSView, which contains an OCX that is a 'scrollable pane' > - it takes > care of all that side of things. There are no financial > licensing issues > with distributing it, but the problem of course is its > unlikely you guys > have a developer's license for it... Thought I'd ask. No commercial controls thank you. Standard redistributable Microsoft ones, or our own only. Too many licencing and compatibility problems otherwise. Regards, Dave.
> -----Original Message----- > From: Tim Finch [mailto:pgadmin@timfinch.cix.co.uk] > Sent: 08 March 2002 11:37 > To: Mark A. Taff > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] table OCX control > > > In fact if we came up with a method of doing it Registry wise then > something like the view designer could determine its own > 'hives' and 'keys' > and not care how, for example, the left hand tree view in > pgAdmin stores > its own project related settings. What do you think Dave/Jean? Hmm, you saw my earlier thoughts on this. Keep it optional, keep it simple. I guess the best bet would be to come up with a spec proposal for us all to consider. It might be worth keeping the Projects to-do item in mind while developing this - as one of you said, it is related. Jean-Michel might have some comments on that - it's his to-do item. Regards, Dave.
> >No commercial controls thank you. Standard redistributable Microsoft ones, >or our own only. Too many licencing and compatibility problems otherwise. > >Regards, Dave. thought as much, no worries, just thought it was worth checking out. Hey! I like a challenge! Tim.