Hi, so yesterday I was looking into how making validation optional into the current feature model.
First off, we have this idea that features might be allowed to hold invalid attributes, and that we can use a isValid() method to check whether they are actually valid or not. Implementation wise, this triggers the first issue: that method does not tell what is wrong, but only that something is wrong. A different approach could be to have a validate() throws IllegalAttributeException and have the exception report exactly what's wrong with the feature. Moreover, even having that method, someone might want to have continuous checks on the feature model like we do now, that is, have the builders and the model throw exceptions when an invalid attribute value is provided. Do we really want to do that? Or we just tell the world that validation checks must be explicit, that is, never ask the model to do them automatically? If on the contrary we believe it's important and we allow the user to customize that behaviour, Jody was suggesting to do so by providing two different feature factories, one that builds non validating features, the other that builds validating ones... which in the end would boil down to parametrize the SimpleFeatureImpl with a flag that enables validation when attributes are set. It would also require the builder static utility methods, which are very commonly used in the datastores, to accept a factory. To make it effective it would mean we'd need to add a new Query hint (the feature factory, which is not there) and use it in all data stores. Yet that would not be all, those methods are used in many many places (SimpleFeatureBuilder.build(...) is used in 179 different places according to Eclipse), do we want add a factory param in each place? Just have a look in DataUtilities class to get an idea. Given that most non datastore methods are transformation related ones, we could use the same factory that built the original features, adding a getFactory() method to the Property interface... thought of course that would be another geoapi change, would require even more changes around, well, you get the picture. It seems to me this kind of change would require at least a one day sprint... what do we do in the meantime? Cheers Andrea ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
