Обсуждение: First DataTable submission to CVS!!
Dave, Jean-Michel, Mark, I have submitted my first bunch of early alpha files of DataTable OCX to the CVS in /dev/DataTable There is a readme that tells you what to do. Its not fantastic but at least is the start of the control. My idea is to keep the DataTable.ocx control totally unaware of PostgreSQL or pgSchema, and simply set simple properties and use methods to set it up. The second control that Mark asked me to work on (the Diagram Pane) will be pgSchema aware and will translate what it sees in a pgSchema table or View object and set the necessary properties on the DataTable ocx when one is being set up in the diagramming pane. I am also aware that the coding style does not match your requested method of working Dave yet. The reason for this is that at this early stage I want to concentrate my effort on getting something written and not have to adapt to a new style of coding after years of writing variable names and using tab spacing the way I have etc. This is not rebellion but making my life simple at the outset! Look forward to feedback. Tim.
> -----Original Message----- > From: pgsql@timfinch.cix.co.uk [mailto:pgsql@timfinch.cix.co.uk] > Sent: 18 March 2002 18:20 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] First DataTable submission to CVS!! > > > Dave, Jean-Michel, Mark, > > I have submitted my first bunch of early alpha files of > DataTable OCX to > the CVS in /dev/DataTable > There is a readme that tells you what to do. Its not > fantastic but at least > is the start of the control. > > My idea is to keep the DataTable.ocx control totally unaware > of PostgreSQL > or pgSchema, and simply set simple > properties and use methods to set it up. Yup, sounds good. > The second control that Mark asked me to work on (the Diagram > Pane) will be > pgSchema aware and will translate what it sees in a pgSchema > table or View > object and set the necessary properties on the DataTable ocx > when one is > being set up in the diagramming pane. OK. > I am also aware that the coding style does not match your > requested method > of working Dave yet. It's not far out. Controls can't really have all the logging/error handling that everything else does so you really need to make them bombproof. My main concerns will be (in the future, when your looking to integrate the code), object/variable naming, consistant indenting (2 char), and licence the comments. > Look forward to feedback. > Tim. 1) Check the spelling of dtbFieldConstraint's values before you write too much code around them. 2) I don't like the italic/underline. I think plain for regular fields, and bold + a colour for fkey/pkeys etc. 3) Use of only 3 datatypes is not good. It should support any (including custom) types, as does the rest of pgSchema/pgAdmin. Of course, this will make the box bigger, but I think it's a must. Looks pretty good though. You might want to drop email to Mark (myeatman@put.my.domain.here) he's the 3rd core developer but is usually very quiet. He's been working on a similar sort of control on and off for some time to represent a node on a network in a network mapping extension to some other software we write. It strikes me that there will be many similarities between the code in his and your controls, especially when it comes to drawing & tracking many of them and drawing links between them. Regards, Dave.
>concerns will be (in the future, when your looking to integrate the code), >object/variable naming, consistant indenting (2 char), and licence the >comments. > Yes, thats fine. >1) Check the spelling of dtbFieldConstraint's values before you write too >much code around them. Thanks! >2) I don't like the italic/underline. I think plain for regular fields, and >bold + a colour for fkey/pkeys etc. Tell you what, what about making this a stylistic issue a property setting of some kind. We can then build in (in future if not at start) an option in the setting of options to diagram-pane ocx the way to represent these settings and make it a pgAdmin View Designer feature user-setable option. >3) Use of only 3 datatypes is not good. It should support any (including >custom) types, as does the rest of pgSchema/pgAdmin. Of course, this will >make the box bigger, but I think it's a must. Sorry, should have pointed out the fact that as this is early code to show you where I am heading I have not tried to flesh out all the Enum settings, and so I fully agree other data types are needed!!! >Looks pretty good though. You might want to drop email to Mark >(myeatman@put.my.domain.here) he's the 3rd core developer but is usually >very quiet. He's been working on a similar sort of control on and off for >some time to represent a node on a network in a network mapping extension to >some other software we write. It strikes me that there will be many >similarities between the code in his and your controls, especially when it >comes to drawing & tracking many of them and drawing links between them. Thanks Dave, I will Tim.