Gabriel Roldán ha scritto: ... >> Ideally we would have a simple "schema editor" on the feature type >> editor page, similar to what we have now but be able to set things like >> namespace uri's for attributes, base types, etc... Just a thought, not >> sure if its a good one :). > Excellent. Agreed. So doing that means a schema mapping ui. And note I'm not > trying to promote community-schema-ds. Doing what you propose for the simple > case can be handled with a simple set of mapping strategies, and even with a > mapping datastore simpler than community-schema-ds. That way it may still > make sense to keep concerns separated. Note we're already doing that kind of > stuff when we wrap a FeatureSource given the state of an ui check (say, force > CRS?). > Proposal is the same: let geoserver configure a mapping datastore to handle > that and the encoder to encode what the datastore serves up. I would just > like to have a single place where to look for a single bug :P > I might be over-dimensioning the problem though?
Gabriel, I agree with you completely... in the long run :) The issue is more the one of letting GeoServer swallow these updates one piece at a time. We're still fixing loose ends from the last big change, the new feature model will bring more functionality but more issues as well, and so on. What I mean is, I welcome change, (and complex features in particular), but I want to start each new change from solid, reliable code in order to avoid functional and performance degradation that may kill the project. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
