Jody wrote: > > 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. > > > I beg to disagree, your Geometry stuff is "complex content", should be > able to "Drill Down" and look at the ordinates...
I see. I thought this would already work with the current feature model. I actually never thought about "displaying" geometries in a table this way. But now that you mention it ... why not. > But yeah, start simple. > > 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. > > > I think we should skip the reading and just draw a picture or two ;-) > Your wiki page or mine? Yours. I don't have an own wiki. (Sorry for being so out of date. ;-) ) (But don't want to press you into drawing them if you have little time.) Anyway. My concern is always that for "normal" users of, lets say, uDig, any such widget must be intuitive. Take your first suggestion, for example: Splitting a large attribute table in smaller pieces of, lets say, 100 features at a time is nice for lazy loading and nice for the memory footprint - it is nice for the developer, no question. But how about the user? If I imagine being a user, I'd find it more intuitive to have the whole list in one table, no explicit change of the subset required. And how about selecting multiple features spread over different "parts" of the big table? So maybe give the user the choice how to view a large data set? Or maybe have a table that just keeps the visible entries in memory ... without the user noticing! (Using proxies...) As a user I wouldn't care exactly how the developer reduces the memory footprint. Just thinking loud. > > Is there already an API with > > this inheritance to work against ... even if unstable? > > [...] > Yes there is, it is called pending and it is stablish (ie we are > implementing against it, but we can fix stuff if you find a problem). Now I'm confused. If it is not the GeoAPI pending branch, where is it then? Just point me to the SVN, please. -- 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
