On Thu, Mar 29, 2012 at 1:41 PM, Andrea Aime
<[email protected]>wrote:
> On Thu, Mar 29, 2012 at 6:32 PM, Justin Deoliveira
> <[email protected]>wrote:
>
>> Nice, will be a good addition.
>>
>> I do think embedding under each of the existing structures would slot in
>> more and correspond to how the api is structured today. Which would look
>> like:
>>
>> /workspaces/<workspace>/templates/
>> /workspaces/<workspace>/templates/<file>.ftl
>> /workspaces/<workspace>/stores/<store>/templates/
>> /workspaces/<workspace>/stores/<store>/templates/<file>.ftl
>>
>> But yeah, i see the rationale about having to update all the "collection"
>> resources to add the links for the templates.
>>
>
>
> I guess extending the collection of resources class to cope with the
> templates inclusion
> would not be that bad, but that would result in new elements in the
> existing
> json/xml representation.
>
> Probably most clients won't care about the extra element, but what if
> someone bound the
> xml with jaxb or other schema oriented tool and we extend the xml under
> their feet?
> There is a desire to have templates being exposed on 2.1.x too.
> Have we already dealt with something similar already in the past, that is,
> adding new
> information in the resource(s) representations?
> I guess it happened implicitly whenever we added new fields in CatalogInfo
> objects,
> but that was done so that the new elements would appear only on trunk,
> while
> on the stable series the extras appeared in the metadata map.
> But... in this case there is no metadata map I can peruse.
> Suggestions?
>
Hmmm... right, that is a good point. But yeah, i would say on trunk it is
fine to simply add the new elements, especially in light that we don't
publish or support a schema for the contents.
On 2.1.x... not sure, perhaps adding a config option to publish the
templates or not?
All in all i don't have too strong an opinion. If it makes it simpler and
safer to have the templates under their own hierarchy I saw we go for it.
In that case I would prefer the structure below which mirrors the existing
catalog structure.
>
>
>> Another alternative could be:
>>
>> /templates/workspaces/<workspace>/templates/
>> /templates/workspaces/<workspace>/templates/<file>.ftl
>>
>
> Right, more in line with the normal hierarchy on the resource side
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
