Justin Deoliveira ha scritto: ... > * getUserData()/putUserData() > > I know that Gabriel found this useful for complex features. What he did > was use it to store the actualy parsed XSD elements straight from an xml > schema. He found it a nice way to keep the information around without > explicity tying the model to xml.
I'm not against having that property bag around. I just find silly to have those two methods redefined here and there and there... why not factor them out in a single interface that others do extend? > * FeatureType namespace > > Not sure i see this. I see PropertyType.getName(). And getName returns InternationalizedString, which is not namespace scoped. If you want the namespace scoped version of the name, you'll have to call myFeatureType.getDescriptor().getName(). Silly? At least strange to me... > * CRS > > Agreed. And my opinion is that too many things have CRS's on them. > Currently you have the following methods. > > - FeatureType.getCRS() > - Feature.getCRS() > - GeometryAttributeType.getCRS() > - GeometryAttribute.getCRS() > > Its confusing... and undocumented how each relates to each other. I have > seen the results of this in starting to write code... and trying to > figure out the crs is a 4 level deep nested if-else statement. Agreed. One place would be sufficient. > * Descriptors > > I understand that the idea of a descriptor is an abstraction. But in > this case I actually see it as a necessary one. In our current type > system there is no way to separate the type and the instance. For > instance, whenever a feature type has an integer attribute we end up > creating a custom on the fly attribute type for it. Its like creating a > new class every time you want to instantiate an object. > > And i admit, this strategy works fine for the simple case. But as soon > as you start talking more complex attribute types it soon falls down. As > you would have to duplicate alot of the structure when creating an > attribute type, instead of just using a single defined type. > > Hope that is not confusing. It sounds like you understand that part of > it regardless and that your issue is just with the getName() methods on > the api. A duplicate getName(). I don't see where getName() returns an > I18NString. Indeed, me neither now... I must have been dreaming... Then again, I don't see why we need two (PropertyType.getName() and descriptor.getName()). If PropertyType, AttributeType and ComplexType are meant to be "reusable token" that need to be referenced by a descriptor in order to be used, then why bother giving them a name in the first place? Cheers Andrea ------------------------------------------------------------------------- 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
