>>
>> * Reflection vs Maps
>>
>> Currently "resources" in rest config all extend from a generic class
>> called MapResource. MapResource works by having subclasses transform an
>> object (say a FeatureTypeInfo) into a map, and vice versa.
>>
>> While this approach is straight forward and simple I think a reflection
>> based approach would result in a lot less code. Especially for the new
>> catalog and configuration interfaces. We all ready have a bunch of
>> reflection utility classes (used by the ows dispatcher and xml parsers).
>> And Andrea even made them fast by introducing a cache.
>>
>
> While such a resource would probably be useful in a quick release, I am
> not sure it should be used in the final version of the API. For
> example, the current API proposal specifies the path to a datastore as:
> /workspaces/{wsid}/datastores/{dsid}
>
> 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
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?
>> Thats it for now :).
>>
>> -Justin
>>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
