[Geoserver-devel] Exposing freemarker templates on rest config

GeoServer GeoServer Developer
1

Hi,
I’m evaluating the possibility of adding rest config support for the freemarker templates.
The simplest way to expose the template list that came to mind is to use two resources,
template list and template, that would react to a path templated as follows:

/templates///

where the bits in // are all optional, so that

/templates would list the global templates,
/templates/ would list the per workspace templates
and so on.

And then the single file could be retrieved/modified/deleted via:

/templates////<file.ftl>

I’ve also considered embedding /templates under each existing resource,
but it seems that would make it more difficult to integrate since we’d have
to add links in all lists, which at the time of writing are relative flat and
made of catalog resources only.

Opinions?

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

2

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//templates/
/workspaces//templates/.ftl

/workspaces//stores//templates/
/workspaces//stores//templates/.ftl

But yeah, i see the rationale about having to update all the “collection” resources to add the links for the templates. Another alternative could be:

/templates/workspaces//templates/

/templates/workspaces//templates/.ftl

…

Just spitballing here.

On Thu, Mar 29, 2012 at 3:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I’m evaluating the possibility of adding rest config support for the freemarker templates.
The simplest way to expose the template list that came to mind is to use two resources,
template list and template, that would react to a path templated as follows:

/templates///

where the bits in // are all optional, so that

/templates would list the global templates,
/templates/ would list the per workspace templates
and so on.

And then the single file could be retrieved/modified/deleted via:

/templates////<file.ftl>

I’ve also considered embedding /templates under each existing resource,
but it seems that would make it more difficult to integrate since we’d have
to add links in all lists, which at the time of writing are relative flat and
made of catalog resources only.

Opinions?

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

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

On Thu, Mar 29, 2012 at 6:32 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> 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//templates/
/workspaces//templates/.ftl

/workspaces//stores//templates/
/workspaces//stores//templates/.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?

Another alternative could be:

/templates/workspaces//templates/

/templates/workspaces//templates/.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

4

On Thu, Mar 29, 2012 at 1:41 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Mar 29, 2012 at 6:32 PM, Justin Deoliveira <jdeolive@anonymised.com> 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//templates/
/workspaces//templates/.ftl

/workspaces//stores//templates/
/workspaces//stores//templates/.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//templates/

/templates/workspaces//templates/.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.