Re: [INTERFACES] JDBC JAVA interface
От | Peter T Mount |
---|---|
Тема | Re: [INTERFACES] JDBC JAVA interface |
Дата | |
Msg-id | Pine.LNX.3.96.980721211040.1291B-100000@maidast.retep.org.uk обсуждение исходный текст |
Ответ на | Re: [INTERFACES] JDBC JAVA interface ("Stephen Lombardo" <LombardoS@Mail.Montclair.edu>) |
Список | pgsql-interfaces |
On Tue, 21 Jul 1998, Stephen Lombardo wrote: > Peter T Mount wrote: > > >>Thinking about it, you could take a look at the Swing component set. Ithas a Table > >>widget which I think can handle ResultSet's. > >>-- > > >>Peter Mount (at work) peter@taer.maidstone.gov.uk or peter@maidstone.gov.uk > >>If you mail me here, please cc my home address peter@retep.org.uk > > > Thats true, but you can add flexibility and a higly reusable interface for database work > simply by using a canvas. It is a lighter weight component and you can come up with an > editable display with little trouble. I actually don't use swing, because I found it's too resource hungry. > By passing the result set to the canvas constructor you can use the > metadata to create column headers, and the custom grid for each result > set that is passed. this means that your component can be pointed at > ANY database and based upon the result set and metadata you will get a > custom table on which you can update rows, individual cells, or delete > entries on the fly. The way I actually handle them, is by having a class that extends Component (in jdk1.1 this is better than Canvas as it doesn't use any native code, and less resources). It then accesses a datasource via a simple Interface. I have several of these classes, one for JDBC, another stores the data in memory using Vector, another can handle simple DBF files, etc. The JDBC one can then be given a query string, and a JDBC connection, and it handles fetching the data. I'm planning another one to actually handle JDBC tables, rather than queries, so the entire table or view is used. [snip] > It might be quicker to use swing or even the packaged classes for ptplot > as Cyril was planning on doing, spending the time to create your own > diplay pays off in the long run with its customizability, portability, > and its flexable interface. I cant agree more here. I've spent a lot of time writing, then rewriting code, just to get the functionality I needed. My mapping classes, which can generate maps from JDBC queries (and soon using postgresql's geometric types), I had to write myself because there was nothing available to do the job. All of the "graphic" classes are cartesian, while I needed something that could handle sperical geometry. Also, I needed to have low level control of the data, because one of the things I wanted to be capable of doing, was generate output, not just on a Printer, but in either Postscript or Portable Document Format (PDF). -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk ************ Someday I may rebuild this signature completely ;-) ************ Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
В списке pgsql-interfaces по дате отправления: