I guess I thought that since the topic of this thread was to provide comments about a different section of Andreas document, a second thread was warranted. Maybe not. Apologies for stepping out of the bounds of good email etiquette.
-Justin Paul Selormey wrote: > Why not just reply to the original thread instead of creating a new one? > > Best regards, > Paul. > > On 9/5/07, Justin Deoliveira <[EMAIL PROTECTED]> 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. >> >> 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. >> >> >> -- >> Justin Deoliveira >> The Open Planning Project >> http://topp.openplans.org >> >> ------------------------------------------------------------------------- >> 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/ >> _______________________________________________ >> Geoapi-devel mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/geoapi-devel >> > > ------------------------------------------------------------------------- > 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/ > _______________________________________________ > Geoapi-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geoapi-devel > > !DSPAM:4007,46de064a24322458217002! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
