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 по дате отправления:

Предыдущее
От: Matthew Hagerty
Дата:
Сообщение: Static link with libpq
Следующее
От: Byron Nikolaidis
Дата:
Сообщение: Re: [INTERFACES] ODBC Problem