Andrea Aime wrote: > 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? This sounds a bit off to me, the DataStoreFileResource that was already there should have been accepting a ZIP file with the shapefile and its companions. I will look over the code in SVN and figure out what the confusion is here. (Hunch: I put the ZIP stuff in trunk after the 1.6.x branch of RESTconfig was created.) Anyway, I am all for having the ZIPped fileset instead of just the shapefile. >> 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. aaime++ >> 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. Hm, sounds like another mismatch between trunk and 1.6.x. Again, all for the improvements if they're not already there. > >> 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). Other clients I've used for quick REST requests include http://restclient.org/ and the firefox extension RESTTest (http://addons.mozilla.org/en-US/firefox/addon/5946) >> 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?
Yes, me too. What does this accomplish that isn't met by the existing code? > Cheers > Andrea > > !DSPAM:4040,482d45ed41092085621377! > -david ------------------------------------------------------------------------- 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
