Silly idea: wouldn't it make sense to add a "Type Name" text entry to the data upload form? It could default to the filename (minus .shp) on a first upload, and be unmodifiable on an update, besides it would be nice separation of concerns?
2c. Gabriel On 7/20/10 7:25 PM, David Winslow wrote: > On 07/20/2010 02:58 PM, Sebastian Benthall wrote: >> Ariel brought up this issue in channel earlier. Wanted to recap the >> discussion for the list. >> >> Ariel pointed out the following bug: that after uploading new data the >> layer page is not accessible anymore. >> >> This raised a couple issues around the "replace data" functionality. >> >> First, what should happen when a user uploads a shapefile that doesn't >> have the same typename? I think the typename should stay the same and >> the new filename should be thrown out. > Shapefiles don't have typenames. But, yes, replacing a layer implies > that the name will not be changing. Otherwise it's > "delete-and-upload-something-unrelated" which is probably not what > anyone is looking for. So +1 on using the existing typename when a user > goes through the "replace" form. > >> David brought up an additional problem, which is that if the new >> shapefile has a substantially different schema, it can break styles >> that are associated with that layer. > "substantial" is vague and misleading here. The changes are easily > described and could be automatically detected with a bit of effort. > Style-breaking changes include - > * removing attributes > * changing the type of an existing attribute > > If we want, we could even scan known styles and only flag as an error > changes to attributes that are actually used. > >> What's the solution to this bug? >> >> I think that if the way that best short-term solution is to add >> whatever error handling is needed for the broken styles to fail >> gracefully, and let the user clean up after broken styles as needed. > -0.5 > > I don't think that letting GeoNode users unwittingly break *other users' > maps* is a great way to go. imo, we should defer the layer replacement > feature until after the 1.0 release so we have time to implement some > complementary features to take off some of the rough edges. >> Do these descriptions match others' expectations? If so, then I'll >> make tickets about them. > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers.
