Justin Deoliveira ha scritto: > I guess the latter. I agree that its better design to just have the > builder do what it can, and not throw exceptions, seems more inline with > what a builder should do. The downside is that this logic will have to > replicated elsewhere. And there is possibility of duplication, doing it > in the UI and the catalog. And of course removing any thing will most > likely result in a regression somewhere.
Either that or I have to copy that code fully for the work I'm doing and fix it in my module. At the moment the only user of that method on trunk seems to be the wicket UI, which would enjoy the same fixes. > That class was a place to put "stuff", so its a bit messy at this point. > If we think it is "slowing down", we should refactor it, and now is the > time to place some rules on the builder, I would be for that. But it > would be nice to do it consistently. Or at least come up with the plan > of how to do it consistently. Sure, let's talk about it (I can make a short lived copy of that code for the time being). So, all the methods should try to act as data fillers and avoid failing when they cannot fill one parameter. Long operations should be optional. Any other principle? >> >> I think the method should be modified to just fill as much as possible >> without throwing exceptions, and leave the checks to whether a feature >> type is usable to the catalog validation routines instead, or to the >> UI validation, in case the feature type built like this is used >> to fill a new layer configuration page. > >> >> Oh, UI wise we don't want to have the native bbox computed before >> hand as that may take various minutes when the data sets are huge >> (this is one of the things we had to fix for TIKE in 1.7.x). >> Should we add a param in that direction, or just have the bbox filling >> be a separate method (initBboxes(FEatureTypeInfo)? > > Are you talking about the code that calls featureSource.getBounds()? I > am ok with breaking out expensive operations into a separate methods. Yep, that's the one. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel