> > Since workspaces are equivalent to namespaces (for the time being) we
> > should exclude the namespace from the returned representation of the
> > datastore. Similarly, redundant info such as the lat/long vs. native
> > bounds for featuretypes should be omitted (so we don't have deal with
> > self-inconsistent representations).
> I don't quite understand. What i am taking about is populating an object
> reflectively from a xml/json representation. For instance say someone
> POST's the following to /workspaces
>
> <workspace>
> <name>foo</name>
> </workspace>
>
> I should be able to create a Workspace object reflectively without
> having to 1) write some dom code to read it 2) create a map from the dom
> 3) create a workspace object from the map
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>
?
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?
>
> 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
> >>
> >
>
>
------------------------------------------------------------------------------
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
