| Suggestion for a plugin "commons" e.g. JDBC [message #98830] |
Wed, 23 July 2003 18:12  |
Eclipse User |
|
|
|
Originally posted by: adam._NO_SPAM_softfab.com
Dear All,
I'm writing a plugin for an XML<>SQL mapper called XML-DBMS.
I've looked at a bunch of OSS plugins for guidance & tips etc & the
though struck me...
"Why isn't there an Eclipse plugins commons"?
What I mean by this is to take the example of JDBC/SQL. There are lots
of apps which either need to look at or work with JDBC & SQL etc. I
particularly like JFaceDBC.
However consider that the average developer/user will only have a
certain number of DB'es (inc URL, DB driver jar files etc) that he will
be using. He may be doing some kind of SQL work or some sort of OR
mapping or even a Entity bean etc. Would he really want to set up the
same db multiple times ( once for each plugin)?
i.e. imagine if there was a "JDBC" common part which had views etc for
setting up db'es & which then someone building an SQL editor could hook
into or someone doing an OR mapping or whatever.
i.e. a single common jdbc part which could then be made the best jdbc
part (full jdbc spec inc metadata) & which a developer could use to set
up his jdbc connection once.
There are other "common to many plugins" areas but the jdbc one is just
so obvious ......
Especially given there are so many nearly duplicate JDBC/SQL editors
each with their own base implementation of JDBC, setting up drivers
etc.etc.etc.
Why require each plugin developer who wants to do a JDBC using plugin to
re-invent the wheel etc? Isn't Java (& indeed the eclipse plugin
mechanism) supposed to promote object reuse?
Adam
|
|
|
|
| Re: Suggestion for a plugin "commons" e.g. JDBC [message #100494 is a reply to message #99003] |
Sat, 26 July 2003 10:23  |
| Eclipse User |
|
|
|
Originally posted by: adam._NO_SPAM_softfab.com
Uwe Voigt wrote:
> Adam,
> I'm not sure it would make sense to create such core plugins that contain
> basic functionality for specific areas.
> Especially for JDBC there is a plugin (DbEdit) that is split into a core,
> a ui and extension plugins (with version 1.0, which is available on
> SourceForge soon).
> Extensions are editors, contributing actions and the like.
> There isn't a 'standard' yet, that's why each developer started his
> efforts with his own implementation I think.
There are lots & it's pointless. i.e. imagine a simple thing but
required i.e. the classloading of JDBC drivers.
How many different people need to write the same piece of code? Ditto
the whole mapping of the JDBC metadata & the methods for coping with the
differences (e.g. how the different db'es report on/use "Schema").
e.g. Database>Schema>Table or just Database>table.
We should be (if you believe in both opensource & the concept of code
/object reuse) able to have a project which simply provides the JDBC
nuts & bolts which then people building plugins which in some way use
JDBC can then build upon rather than everyone having to build their own
JDBC metadata handler, JDBC driver jar classloader etc.etc.etc.
If you look at the apache commons code, while in some ways it's grown to
include stuff I would not count as "common" it is an interesting model
to follow wrt Eclipse.
How many corp developers **don't** use an SQLDB via JDBC in some way
(whether J2EE or JSP or Swing CRUD app or whatever).
You just need to look at some of the plugins in:
http://eclipse-plugins.2y.net/eclipse/plugins.jsp?category=D atabase
To see that there is this common subset whether you want to create XML
docs or JDO objects or J2EE Entitiy beans or an SQL editor or just look
at the data in a db.
Think of all the stuff (inc gui views) required to:
A) Set up a db
B) Load the driver jars referenced in (A).
C) Run against the DB (create a connection etc) & get the JDBC metadata out
D) Visually display that info (e.g. in a SWT tree)
E) Be able to get the info from a mouse action from the selected tree
node (e.g. a table) & provide that info to the specific app/plugin.
How many people have had to write that same sequence? Why when it would
be better for people who're interested in that bit (& would like to
improve the handling e.g the differences between the different db'es)
can all contrib to a single project & can then go onto create the
differences in what they want at a higher level (e.g. creating XML
mappings or SQL editors or graphical views of the relationships between
tables/ERD modelling etc.)
AFAICS there is nothing within the Eclipse setup wrt these "commons".
Much like the GEF & what have you projects, there should be a "commons"
project for stuff like basic JDBC functionality etc.
&.....it gives a "common look & feel" to the setting up db'es etc such
that developers don't have to work out how & where to set up a db with
plugin A vs wher e& how in plugin B etc
& & Different plugins could use the same "live" connections maintained
by the commons code (e.g. you're building say an xml/object mapping &
want to shove in some test data or create a table or even check the
values in the object/xml produced by one plugin against an SQL statement
fed into an SQL Editor).
It makes so much sense it hurts.
Adam
> Uwe
>
> Adam Flinton wrote:
>
>
>>Dear All,
>
>
>>I'm writing a plugin for an XML<>SQL mapper called XML-DBMS.
>
>
>>I've looked at a bunch of OSS plugins for guidance & tips etc & the
>>though struck me...
>
>
>>"Why isn't there an Eclipse plugins commons"?
>
>
>>What I mean by this is to take the example of JDBC/SQL. There are lots
>>of apps which either need to look at or work with JDBC & SQL etc. I
>>particularly like JFaceDBC.
>
>
>>However consider that the average developer/user will only have a
>>certain number of DB'es (inc URL, DB driver jar files etc) that he will
>>be using. He may be doing some kind of SQL work or some sort of OR
>>mapping or even a Entity bean etc. Would he really want to set up the
>>same db multiple times ( once for each plugin)?
>
>
>>i.e. imagine if there was a "JDBC" common part which had views etc for
>>setting up db'es & which then someone building an SQL editor could hook
>>into or someone doing an OR mapping or whatever.
>
>
>>i.e. a single common jdbc part which could then be made the best jdbc
>>part (full jdbc spec inc metadata) & which a developer could use to set
>>up his jdbc connection once.
>
>
>>There are other "common to many plugins" areas but the jdbc one is just
>>so obvious ......
>
>
>>Especially given there are so many nearly duplicate JDBC/SQL editors
>>each with their own base implementation of JDBC, setting up drivers
>>etc.etc.etc.
>
>
>>Why require each plugin developer who wants to do a JDBC using plugin to
>>re-invent the wheel etc? Isn't Java (& indeed the eclipse plugin
>>mechanism) supposed to promote object reuse?
>
>
>>Adam
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03910 seconds
Home