On Wednesday 05 September 2007 01:46:51 Justin Deoliveira wrote: > Hi Andrea, > > I am just now looking at the Feature part of your review. And here are > my comments. > > * Property exposing name and type from descriptor > > This is kind of tricky issue. I need to provide some context. Consider > for a moment two types of attributes: > > 1. An attribute that is part of another type > 2. An attribute that is at the top level > > In the first case Attribute.getDescriptor() != null, but in the second > case Attribute.getDescriptor() == null. The reason being that in the > second case the attribute is not part of another type... so there is > nothing to "descript". I know the javadocs do not state that at all... > they are horrible just a quick note on this one. The rationale for getDescriptor() being null for attributes that are at the top level seems sensible, but in practice I've found the following issue: It previous experiments and even in the FM module, it was considered that Feature instances returned from a DataStore are at the top level, and thus they come without a descriptor. This is inconvenient when encoding that feature to gml and the actual problem is generally masked by the fact that we used to encode the FeatureType name as the Feature instance name, which might be handy for direct single db table mapping. Anyhow, I found out that Feature instances comming directly from a datastore need a descriptor, as per having the name of the Feature at hand. It makes sense for that descriptor to have 0..N multiplicity too.
As the new model is a better representation of the ogc abstract feature model and is a better to map to gml too, there's no more need to do the tricks we used to (say, when encoding gml, using the FeatureType name for the Feature instance, and when encoding a DescribeFeatureType request, appending "_Type" to the FeatureTypeName in the generated gml schema). Now we have both the actual FT name and the Feature name. Moreover, when a GetFeature request is sent, the typeName parameter actually refers to the Feature instance name. Say, typeName=River, not typeName=RiverType. So the need for Feature instances to come out from the datastore with proper AttributeDescriptor. I had to ensure that when working on the community-schema modules in order to cleanly encode GML and avoid hacks like the one described above. Not sure if I explained it well or even if it makes sense at all to you, please comment. Gabriel > > Regardless, the name() method is as convenience which makes it so that > client code does not have to do a null check on the descriptor. For case > 2, name() returns null. > > However, getType() returns non-null in both cases. And in the first case > Attribute.getType() == Attribute.getDescriptor().getType(). > > Does that make any sense? > > * Associations > > Looking at this I am a bit confused as well. I believe teh reason for > the duplication is related to what i stated above. However... that case > does not apply since you cant really have an association at the top > level. Hopefully Jody can provide more feedback here. > > * Attribute ID's > > I think the reason for this is that things other then features can be > identified, like geometries in GML. And yes... I believe this should > return null in the case that getType().isIdentifiable() is false. Yet > another hole in the docs. > > * ComplexAttribute.getValue() to List > > +1 on this one. A list is still more useful even if you are telling > people that the order in the list may be random. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
