Re: Java GUI development

Bear,

I had sort of been thinking about not using the JDBC API for this, but
you make a good point of it being a reference application for JDBC. I
did intend to use the driver code, but more of the lowlevel stuff for
speed reasons. One of the problems the driver has is that it fetches the
entire query before returning which could be problematic. I kind of like
the idea of some sort of cache for the query if it is large. Something
along the idea of a lazy load, where we would initially return the first
couple of pages, and then if the user scrolled down we would fetch
another couple of pages. If it were "really smart" it would only keep a
window of information in memory. That being said this may be an
opportunity to make the driver better too!

RE JSP tags: I personally favour templating tools like velocity, or
webmacro over jsp, but that's my personal taste (you can read the
arguments on www.servlets.com and form your own opinions). I do however
see the possiblity of writing the code so that it could be either a web
application, or a GUI application. I think that is a real attainable
goal using java.

Notionally the idea would be as follows:

The database is more or less object oriented as it is, ie pg_tables,
pg_trigger, pg_index, etc. can all be easily modelled as objects. So the
entire structure of the db can be loaded and accessed, by either the
gui, jsp, or templating code.

Thoughts?

Dave

On Wed, 2002-06-05 at 15:15, Bear Giles wrote:
> > Is there anyone interested in collaborating on a Java GUI.
>
> That's been on my 'possible projects' list, so I may be interested
> in contributing. I've also been playing with some Tomcat JSP tags
> that may be a good complement to this project. The goal of these
> tags is to make it easy to write "am I sane?" views of the database -
> basically a dump of each table, but with links so that you can easily
> navigate between the tables.
>
> E.g., if table foo has a foreign reference to table bar, then each
> row in foo should have a link that shows the corresponding entry in
> bar. Contrawise, it would be nice if each row in bar had a link
> that brought up all rows that accessed it. (Then there's those
> graphing applets that could show relationships between tables, and....
> okay, I'll stop drooling now.)
>
> JSP may be a good prototype tool for a standalone application.
> It allows formatting to be quickly changed, so people can try out
> different approaches, and the "input" could be handled by JSP
> that catches forms.
>
> > I am fairly
> > confident I could handle the low end server interface to the tables, but
> > am looking for someone with swing skills
>
> I think one of the desireable goals of this type of project is as
> a demonstration of how to access the database through Java, and
> thus the project should use JDBC unless something entirely outside
> of its interface is required. This also helps make the application
> thin and fast, since it's not doing much beyond constructing JDBC
> queries and formatting the results.
>
> Bear
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
>