Matthias Basler wrote:
Hi Matthias, always fun to read your email ... and I will let you in a
secret.
You have rediscovered the C# environment! In C# (or any dot net) you
sling "RowSets" around. Objects (represent a table) and have methods to
get result set and modify result sets, and tables and graph widgets have
been made to consume them and do the right thing.
So yes we could sling JDBC ResultSets around and set up components based
on that, indeed that is a *good* approach. It is just not a pure OO
approach. But this is one situation when being pure OO does not pay...
I would also report back on some commercial experience I have with this
stuff:
- a pure table does not work for complex content
- a tree (indicating a path or index) and a table (indicating the data
at the selected index) often works the best...
RESULT
+ 1..100 <--1
+ 101..200 <--- 2
+ 101 <--3
101.TIME <--4
+ 201..255
If you select:
1 - you see a table of four entries 1..100, 101..200, 201..255, double
clicking on 101..200 brings you to ...
2 - you a traditional table of features, numbers along the side (fids
actually), attributes as the columns, etc...
3 - selecting an individual feature, shows you columns ATTRIBUTE and
VALUE (with say NAME, TIME, POSITION, HISTORY)
4 - clicking on a complex object like TIME shows you ATTRIBTUE and VALUE
(with DAY, MONTH, YEAR, HOUR, MIN, SECOND )
Clicking on a List like 101.HISTORY would show you a list in the same
manner as your origional RESULT list.
- The rows are populated by database entries, records, features
or however you like to call it.
data + query = result
- The columns are the attributes, fields, properties
or however you like to call it.
attributes (I am learning that properties include operations)
- Each column has a data type, usually constrained by a class,
sometimes being more specific.
description = type + cardinality + attributeName
- Usually the column descriptions are quite similar even though the
data stored (geographical features, wether data, persons, or simply
"any database content") are very different:
Restrictions apply, such as decimal digits (precistion) and such.
Usually there is something like a default value and/or a nodata value.
type = typeName + binding (class) + restrictions (filters) + more metadata
- Usually the intent of showing a table (editable or not) with such
data to the user is also similar and the functions to be done are
the same (edit the values, sort by column x, select entries,
add record, delete record etc.
JFace vs Swing here, I love both approaches and cannot choose between
them. Although JFace is less work, I have more freedom to hack with swing.
Of course, the JFace viewer widgets have recognized this, so it is not a big
deal to create content and label providers as well as cell editors for each
kind of tabular data.
Can also look to the BRIT project or any of the data mining projects for
more useful abstractions and sometimes
widgets. BRIT for example has a generic query builder that is not sql
specific.
Still I feel that the notion of "tabular data" has been reinvented several
times now with different names, and I have to include my own API for
meteorological data here as well (although it was designed to be somewhat
reusable).
And I have to include any dynamic data model, Entity/EntityType and
Feature/FeatureType and EObject/EClass and DOM/XMLSchema and ....
To cut long stories short: Would it be possible to have a generic database
table API and have the GeoAPI feature model inherit from it (by adding the
methods that are specific for GeoAPI and spatial data on top)?
Yes and that is what is happening, in the GeoAPI thing we finally have
some people (Bryce) who have access to the
strange ISO specifications where all this is written down. So Feature
extends Record and FeatureType extends RecordType and so on...
I imagine something like javax.swing.table.TableModel, but more
sophisticated, in order to cope with almost any sort of tabular data.
So read through Bryce's pdf and get back to us? The idea is to have
interfaces that do what is needed so we can gobble up later
specs with less effort. But also are implementable with a code
generation run from EMF.
If I can put this bluntly the work is not specific to GeoAPI, it just
represents a "baseline" for how to convert these specification. If you build
your widgets against this baseline they can be reused across other
domains. That would be a good thing.
(Note that my thoughts arose from reviewing the current GeoAPI feature
interfaces, NOT the complex feature API. I am not sure, if complex features
and feature collections can still be see as a special case of tabular data
or if they depart too much from this model.)
Any thoughts from you about this?
Yes, many - it is what we are doing ;-) Having someone going after a
Java 5 implementation would make me Very happy.
For two reasons:
- it would rock!
- I have asked GeoAPI to wait for two implementations before considering
something "good", right now we only have one person (Justin) going after
an implementation - and he is doing it with Java 5.
Jody
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
