> > The name should not be a part of the representation of a workspace; this > is exactly the type of duplication of information I am talking about. > What happens when someone updates the workspace configuration by doing a > > PUT /workspaces/foo > > <workspace> > <name>bar</name> > </workspace>
Is there a way in a PUT to change or redirect where the resulting resource (after modified) will be? If not I guess the answer would be to ignore the name attribute or send back a 403 or something. > > ? > > This should be implemented as a POST request with just the namespace URI > in the body, and an HTTP header named 'Slug' (as used in Atom pub) to > specify the desired name. > > Does that clarify the concern I had? Maybe "name" was a bad example since its used to identify a workspace. But replace name with a normal attribute and my initial argument is the same. Aside I don't understand if a POST to /workspaces specifying the name is not allowed then how do I create a new workspace? I see no reference to the use of a header in rest configuration api proposal. All i see is that that a POST to /workspaces should create the new workspace, and set the Location header in the response which specifies the path to the new resource. Perhaps I am missing something. > >> And similar for a GET on /workspaces/foo. It would be nice to be able to >> go straight from workspace object to XML. >> >>> If we use a reflective implementation of the resources, I assume we will >>> be either exposing all attributes of configuration objects, or >>> blacklisting attributes to be hidden. I think it would be more safe >>> against future changes to the GeoServer catalog API to continue to use a >>> whitelist approach. >> I agree that we have to be careful about making changes to objects and >> how that affects the "automatic" serialized output since its our api. >> But I think a good set of test cases would solve this. >> >> I see the point but I see the same situation developing here as with the >> persisting of the old config system. Specifically that whenever we add a >> property to a config object, we have to update the config object, the >> reader, and the writer. This sort of duplication of work has seriously >> discouraged maintainance of that subsystem in the past. >> >> Also to add serialization and de-serialization of xstream is highly >> configurable. So we have full control over what output looks like if we >> want. >>>> Anyways, I think having a MapResource around is definitely useful for >>>> some cases, but I think another base class called something like >>>> "ReflectiveResource" would also be useful. >>>> >>>> * Freemarker Templates for HTML output >>>> >>>> Currently when a resource is serialized as html it uses a built-in >>>> template. I think it makes sense to make this customizable for users >>>> with our fancy template system. I don't think this will be too much >>>> work. Basically just configure the template configuration used by >>>> FreemarkerFormat to use the GeoServerTemplateLoader to find a template, >>>> and fall back on the built-in templates. >>> I don't see a use case for this. Could you elaborate on why this would >>> be a good feature to have? >>> >> The use case is the same as any other "customization" use case in >> GeoServer. Why do we provide templates for wms getFeatureInfo output? > > Well, the difference is that the HTML output should ideally be another > means of editing the configuration, so customizing it seems like a > headache. > >>>> Thats it for now :). >>>> >>>> -Justin >>>> >> > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
