Alessio Fabiani ha scritto: > Hi guys, > > I made few improvements to the GeoServer RESTConfig and sldService stuff > which I would like to briefly discuss here, and in case of interest I > can commit it: > > 1. DataStoreFileResource: this class originally was intended to let > GeoServer get a shapefile and create a new datastore. I corrected some > errors and changed a bit the behavior. Originally this resource was > checking just for the arrival of a single .shp file, which is not > sufficient for my needs; so I changed it in order to let it accept a ZIP > file containing the whole Shapefile stuff, decompress it into GeoServer > data dir, create the new datastore and contextually create the > FeatureType also.
This seems sensible to me. David? > 2. FeatureTypeResource: this class allows a user to insert/update a > FeatureType. Originally the resource constrained the user to send the > whole feature type properties everytime. I changed a bit in order to let > a user to update also just some of the properties of the FeatureType if > the latter is already present in the catalog. Hum, how do you do that? Are you exposing the properties as sub-resources? In REST there is no partial update of a resource afaik, usually that is obtained by exposing explicitly what you want to make modifiable singularly. > 3. StyleResource: this resource was incomplete, in particoular it didn't > save the style on the catalog and also didn't check for the style > existence in the case of a replacement. I changed it to perform those tasks. Sounds sensible again. > 4. SimpleClient: I put this simple utility class in the test package in > order to allow users to perform simple GET/POST/PUT/DELETE requests to > the REST interfaces. It is not fully complete though. Is it any better than using curl on the command line? (did not look, just wondering). > 5. on sldService I added few Resources to let users to easily generate > color classifications and optionally color Ramps, without the need to > create and save a new SLD. Maybe they are redoundant, but very usefull > to me. On a POST request, the user can specify the datasotre, the > property, the type of color quantization to apply and the number of > classes. POST == creation of new resource. If your code is just returning a style without storing it on the server, the request should be a GET. Moreover, why specify a datastore? Wouldn't it be better to have a GET request on the FeatureType node that looks like .../topp:states?request=classify&attribute=myAtt&method=quantile&intervals=5&ramp=red > The user can also send as optional parameters of the form the > type of color ramp to generate and in case of custom color ramp also the > start, end and mid colors. The result is a JSON string representing the > quantization rules. Each rule consists basically of a title, a filter > and if the color ramp was specificed a symbolizer describing the fill to > apply. > > 6. I added to the sldService a UserStyleResource which allows a user to > modify the default SLD of a wms layer, independetly if it is generated > from a featuretype or a coverage. Not yet fully complete though. I thought that was already covered by RESTConfig? Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
