Well my code review is not going to well - Justin keeps asking, good,
questions.
For FeatureState implementation in 2.2.x I used the same horrible code
that was already there that let you access the feature members as an
attribtue called "features". This of course must die ... and with a new
feature model it finally can.
1. the javadocs for FeatureCollection.itterator() explicitly state that
the values are to be made available to XPath as "featureMember" and
"featureMembers" (for a GML featurecollection)
2. the attributes used by a feature are ment to be derrived - aka the
attribute "bounds" mapped to FeatureCollection.getBounds()
3. the attirbutes also include name, description, id - so the general
definition of a feature colleciton is out of sync with GML ... so we
will need to let FeatureCollection carry its own attributes - and to be
pure we should not let the collection go "empty". As an example of a
useful attribute - "version" would be a good candidate in a geowiki
application
So here is a revised plan made with the help of Justin:
1. FeatureCollectionDelegate extends FeatureImpl (so Justin does not
have to cut and paste attribute code)
2. FeatureCollectionDelegate.getAttribute( string ) maps "bounds" to the
"wrapping" FeatureCollection.getBounds() method
4. FeatureCollectionDelegate can cache the answer of getBounds()
3. FeatureCollectionDelegate listens to its wrapper for events and can
clear its cache of derrived attributes
None of these changes will be made to 2.2.x as the FeatureModel is not
useful enough to describe a FeatureCollection with attributes...
Jody
Hi Guys,
I got online with Skype and talked with Justin one evening this week,
and learned about all the stuff he has not been sending to email!
Here is the ground we covered (GeoTools only):
- a code review of the ResourceCollection, FeatureCollection,
FeatureState ideas in geotools 2.2.x (yeah a code review for me). The
result was Justin wants FeatureState to be a Feature (so he does not
have to cut and paste some code), I would rather it not support the
Feature interface (cause it is really a "mixin" providing the
attribute, getBounds, getType information for a FeatureCollection.
But I did not care enough to complain much. The only problem is that
the FeatureState.getType() explicitly must return a
FeatureCollectionType when mixed into a FeatureCollection. Since this
is API only used by those implementing a FeatureCollection from the
inside out I figure they can read the javadocs.
-------------------------------------------------------
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
