Hi Jody, many thanks for you suggestions. See comments inline.
Jody wrote: > You have rediscovered the C# environment! Oh ... > 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... Cannot follow here. What does "pure object oriented" mean in this context and why would it not be "pure OO"? Why should I care if it works??? ;-) > 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... Agreed. The point that I must stress here is that I myself are not interested in "complex" features at all. All geographical data I have worked with so far were "simple". Also I'd rather start with a table for simple content and, if really needed, would extend it to deal with complex content later. Some complex things, like multiplicity <> 1 (i.e. lists as attributes) can also be added easily to a "flat" table. Others probably not. > 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. I think I have to read this two more times to get the full picture. The first suggestion, i.e. sub tables (1..100) (101..200) is definitely a good idea, especially when it comes to lazy loading. This is what the variables view in the eclipse debugger does when showing the contents of a collection. For #3 and #4 I had something different in mind, but this is a cosmetical issue. I'll cross this bridge when I come to it. > [...] > > 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... This sounds exactly like what I had in mind. Is there already an API with this inheritance to work against ... even if unstable? The GeoAPI pending to which you pointed me earlier doesn't show this inheritance (yet). I have just checked out the pending branch from the CVS to be sure. > So read through Bryce's pdf and get back to us? I guess you mean the "ISO 19109 Primer". After a hunt throught the RnD pages I have found it. :-) I feel much more up to date now. Thanks again. -- Matthias Basler [EMAIL PROTECTED] ------------------------------------------------------- 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
