Jody Garnett ha scritto: > Summary: > - http://jira.codehaus.org/browse/GEO-141 Formally track this little > adventure of ours (so Martin does not kick me) > - http://jira.codehaus.org/browse/GEOT-1916 Update the Hints to mention > the new factories > > Andrea Aime wrote: >>> Difficulty is that this either needs to be a structures exception >>> message (indicating say the xpath to the problem and kind of problem) >>> or we should provides a utility method to do this kind of check. >> I was leaning towards a structured exception message. Like, I'd >> prefer to keep all the validation logic in one place, and possibly in >> an obvious one, splitting it around does not look nice to me. >> IllegalAttributeException is already structured, it has the descriptor >> of the failing attribute and the value that does not conform to it, >> too bad it's not exposing them, but it's just a matter of adding a >> couple of getters. > Okay - so can you decisive and direct me on this one?
Sure, I'll follow you up on GEO-141 >> If the strict option is meant to help debug only, what about a system >> variable to enable it? > Yes; the idea is to swap out factories - see hint below So you can have a system wide hint, right? >>>> It seems to me this kind of change would require at least a one day >>>> sprint... what do we do in the meantime? > If you want to call a sprint on this stuff I will join you; we are too > close to our deadline on the 15th here to do much. Perhaps we can chat > online and sort this out? Eh yeah, I already exhausted my mandate (1 week of work) so I'll only be able to work on this during the weekend. Actually being able to use a factory is sort of a new requirement that only collaterally touches the feature model speedup. For the 15th deadline I can switch features to use explicit validation, changing all datastores to allow the usage of a hint is a much bigger task. >>> Backing up: >>> - Our goal was to make the FeatureTypes static utility method >>> available for people to find; we have now done that correct? >> More or less, we do if we provide a validate() method that throws an >> exception giving people the full meal, otherwise we have to >> keep that Types utility class around, have isValid() call it, and >> then have the user call it again if he wants to know what is not >> valid, bleck... > Okay so you want to change the method; I can do that now. Please review > when you wake up. >> System wide == configurable? Where is that located? > When I last looked it was a Hint; let me check ... okay we got a > FEATURE_FACTORY but no FEATURE_FACTORY hint yet; something to fix... > http://jira.codehaus.org/browse/GEOT-1916 Cool >> Or is it just a hard coded default in the builder? > No the builder should either: > - be created with a factory > - or look up the default in the usual manner Agreed >>> Aside: The idea of remembering the factory seems like a little bit of >>> gain; while I had similar thoughts they come from a different problem >>> When working with Shapefiles only a limited set of content is >>> supported (max string length etc...). Having >>> ShapefileDataStore.getFeatureTypeFactory() return a factory that >>> knows about these limitations is a sensible way to go... >> Uuh, not sure... the ideas of factories is to put the user in control >> not the lower levels? > Yeah you see the conflict eh? (oh wait that was a Canadian moment). Uh? What's Canadian about it? :) > I agree that the idea of factories is to put the user in control; we > still may need something like "capabilities" to let people know what > data formats are supported ... something for another day? Yeah, most probably? ;) 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
