[Geoserver-devel] Freemarker templates editing via REST

GeoServer GeoServer Developer
1

Hi,
the current support for editing ftl templates in GeoServer is kinda lacking, currently
the only way to add/manipulate them is to go on the file system, which is blatantly
against our policy of not manually editing the contents of the data directory.

While I have no funding to support GUI editing at the moment, I have a mandate to
add template support in REST config.

Since the REST config tree structure follows closely the on disk structure I was thinking
to add template support as an extra resource under each of the main ones, for example:

/workspaces/templates/.ftl
/workspaces//templates/.ftl
/workspaces//datastores//templates/.ftl
/workspaces//datastores//featuretypes//templates/.ftl
/workspaces//coveragestores//coverages/templates/.ftl

/workspaces//coveragestores//coverages//templates/.ftl

Given that the template names are well known the only writing operations I foresee
are PUT and DELETE against the template resources (e.g., no POST against templates).

As for what to return on the various resources, we have two choices:
a) not returning defaults or inherited values, but just mimick the on disk structure
b) apply full defaults and inherited values, so if you ask for a certain template and
it is not there we’ll go look in the parent dirs and eventually return the default values

a) seems clearer to me from an editor point of view, since you always know what’s
really there, and besides that, once you DELETE a resource it really disappears
instead of reverting to a default.

Also wondering if this change warrants a small proposal.

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

On Tue, Oct 2, 2012 at 4:53 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
the current support for editing ftl templates in GeoServer is kinda lacking, currently
the only way to add/manipulate them is to go on the file system, which is blatantly
against our policy of not manually editing the contents of the data directory.

While I have no funding to support GUI editing at the moment, I have a mandate to
add template support in REST config.

Nice!

Since the REST config tree structure follows closely the on disk structure I was thinking
to add template support as an extra resource under each of the main ones, for example:

/workspaces/templates/.ftl
/workspaces//templates/.ftl
/workspaces//datastores//templates/.ftl
/workspaces//datastores//featuretypes//templates/.ftl
/workspaces//coveragestores//coverages/templates/.ftl

/workspaces//coveragestores//coverages//templates/.ftl

Makes sense to me.

Given that the template names are well known the only writing operations I foresee
are PUT and DELETE against the template resources (e.g., no POST against templates).

I wonder, since we don’t support collections it makes sense to cut out the “/templates” directory, and just have the .ftl resource live right under its feature type/coverage/workspace, etc… I guess it might be harder to do the rest mappings that way… nevermind :slight_smile: Not supporting POST on the collection makes sense.

As for what to return on the various resources, we have two choices:
a) not returning defaults or inherited values, but just mimick the on disk structure
b) apply full defaults and inherited values, so if you ask for a certain template and
it is not there we’ll go look in the parent dirs and eventually return the default values

a) seems clearer to me from an editor point of view, since you always know what’s
really there, and besides that, once you DELETE a resource it really disappears
instead of reverting to a default.

Agreed, returning a template under a feature type that is actually backed by the one registered globally at the workspace level would probably be confusing imo.

Also wondering if this change warrants a small proposal.

It can’t hurt. Always nice to have a proposal to send out to other folks (like javascript devs, restconfig client maintainers, etc…) who may not be on the developer list.

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

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

I agree that it would be confusing to have the global template returned for a local template request. Is there any plan to expose information about which template is being used directly from the REST API (as opposed to forcing clients to walk up the tree checking for 404s/empty templates)?

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Oct 2, 2012 at 9:23 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Tue, Oct 2, 2012 at 4:53 AM, Andrea Aime <andrea.aime@anonymised.com1268…> wrote:

Hi,
the current support for editing ftl templates in GeoServer is kinda lacking, currently
the only way to add/manipulate them is to go on the file system, which is blatantly
against our policy of not manually editing the contents of the data directory.

While I have no funding to support GUI editing at the moment, I have a mandate to
add template support in REST config.

Nice!

Since the REST config tree structure follows closely the on disk structure I was thinking
to add template support as an extra resource under each of the main ones, for example:

/workspaces/templates/.ftl
/workspaces//templates/.ftl
/workspaces//datastores//templates/.ftl
/workspaces//datastores//featuretypes//templates/.ftl
/workspaces//coveragestores//coverages/templates/.ftl

/workspaces//coveragestores//coverages//templates/.ftl

Makes sense to me.

Given that the template names are well known the only writing operations I foresee
are PUT and DELETE against the template resources (e.g., no POST against templates).

I wonder, since we don’t support collections it makes sense to cut out the “/templates” directory, and just have the .ftl resource live right under its feature type/coverage/workspace, etc… I guess it might be harder to do the rest mappings that way… nevermind :slight_smile: Not supporting POST on the collection makes sense.

As for what to return on the various resources, we have two choices:
a) not returning defaults or inherited values, but just mimick the on disk structure
b) apply full defaults and inherited values, so if you ask for a certain template and
it is not there we’ll go look in the parent dirs and eventually return the default values

a) seems clearer to me from an editor point of view, since you always know what’s
really there, and besides that, once you DELETE a resource it really disappears
instead of reverting to a default.

Agreed, returning a template under a feature type that is actually backed by the one registered globally at the workspace level would probably be confusing imo.

Also wondering if this change warrants a small proposal.

It can’t hurt. Always nice to have a proposal to send out to other folks (like javascript devs, restconfig client maintainers, etc…) who may not be on the developer list.

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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

Don’t let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

On Tue, Oct 2, 2012 at 3:28 PM, David Winslow <dwinslow@anonymised.com> wrote:

I agree that it would be confusing to have the global template returned for a local template request. Is there any plan to expose information about which template is being used directly from the REST API (as opposed to forcing clients to walk up the tree checking for 404s/empty templates)?

I don’t have such plans, no.
But it does not hurt to talk about it anyways.

Wondering, how do you see that working?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

5

Well, I hadn’t thought about how it might work when I asked the question (and indeed, I don’t really have a use-case in mind, but it does seem like useful information for an interactive editor.)

One approach could be to use HTTP headers (in this example let’s assume that there is no template for the states layer, but there is one at the global level.)

GET /workspaces/topp/datastores/shapefiles/featuretypes/states/templates/content.ftl

HTTP/1.1 302 Found
Location: /templates/content.ftl

This is tidy and uses pre-existing mechanisms, but might result in naively written clients following the redirect and lead to mistaken editing of the wrong template.

Alternatively, we could introduce a custom header (X-GeoServer-Template-Location) or provide a payload on 404 requests (json or something with the information about which template is used.)

Another idea might be to include this information in the response to requests against the templates/ resource.

–
David Winslow
OpenGeo - http://opengeo.org/

On Tue, Oct 2, 2012 at 9:37 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 2, 2012 at 3:28 PM, David Winslow <dwinslow@anonymised.com> wrote:

I agree that it would be confusing to have the global template returned for a local template request. Is there any plan to expose information about which template is being used directly from the REST API (as opposed to forcing clients to walk up the tree checking for 404s/empty templates)?

I don’t have such plans, no.
But it does not hurt to talk about it anyways.

Wondering, how do you see that working?

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

6

On Tue, Oct 2, 2012 at 3:48 PM, David Winslow <dwinslow@anonymised.com> wrote:

Well, I hadn’t thought about how it might work when I asked the question (and indeed, I don’t really have a use-case in mind, but it does seem like useful information for an interactive editor.)

One approach could be to use HTTP headers (in this example let’s assume that there is no template for the states layer, but there is one at the global level.)

GET /workspaces/topp/datastores/shapefiles/featuretypes/states/templates/content.ftl

HTTP/1.1 302 Found
Location: /templates/content.ftl

This is tidy and uses pre-existing mechanisms, but might result in naively written clients following the redirect and lead to mistaken editing of the wrong template.

Right, I agree this would be the clean way, also fully agree on the issue with client automatically following redirects

Alternatively, we could introduce a custom header (X-GeoServer-Template-Location) or provide a payload on 404 requests (json or something with the information about which template is used.)

Wondering what would happen if we send out a 404 but keep on providing the Location header.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

7

Hi,

I'm working on adding Freemarker templates editing using REST...
I've added these mappings as suggested by Andrea:

/workspaces/templates/{template}.ftl
/workspaces/{workspace}/templates/{template}.ftl
/workspaces/{workspace}/datastores/{datastore}/templates/{template}.ftl
/workspaces/{workspace}/datastores/{datastore}/featuretypes/{featuretype}/templates/{template}.ftl
/workspaces/{workspace}/coveragestores/{coveragestore}/coverages/templates/{template}.ftl
/workspaces/{workspace}/coveragestores/{coveragestore}/coverages/{coverage}/templates/{template}.ftl

Now I need some suggestions for urls used to list available templates.
If I follow the same pattern used for other resources I should add
mappings like:
/workspaces/templates.{format}
/workspaces/{workspace}/datastores/templates.{format}

But these urls will be intercepted by other Finders, because we have
these mappings:
/workspaces/{workspace}.{type}
/workspaces/{workspace}/datastores/{datastore}.{format}

On the other hand, if I put my new mappings on top, and someone create
a workspace or a datastore called 'templates', the
freemarkerTemplateFinder will intercept calls which isn't supposed to
handle. :slight_smile:

A solution could be to use these mappings:
/workspaces/templates/index.{format}
/workspaces/{workspace}/templates/index.{format}
...

Another solution:
put everything, editing and list urls under /templates/:
/templates/workspaces/{template}.ftl
/templates/workspaces/index.{format}
...

Opinions?

Regards,
-

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Davide Savazzi
@svzdvd
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

8

Yes, this does seem a bit messy. What prevents a workspace from being named ‘templates’?

It seems like the /templates prefix is the simplest solution. I could also imagine templates being “merged in” to the main resource, for example the XML representation of a feature type could include an optional element with children representing each template (content.ftl, header.ftl, etc). I recognize that this would present a greater technical challenge to implement, though.

–
David Winslow
OpenGeo - http://opengeo.org/

On Oct 29, 2012 12:21 PM, “Davide” <davide.savazzi@anonymised.com> wrote:

Hi,

I’m working on adding Freemarker templates editing using REST…
I’ve added these mappings as suggested by Andrea:

/workspaces/templates/{template}.ftl
/workspaces/{workspace}/templates/{template}.ftl
/workspaces/{workspace}/datastores/{datastore}/templates/{template}.ftl
/workspaces/{workspace}/datastores/{datastore}/featuretypes/{featuretype}/templates/{template}.ftl
/workspaces/{workspace}/coveragestores/{coveragestore}/coverages/templates/{template}.ftl
/workspaces/{workspace}/coveragestores/{coveragestore}/coverages/{coverage}/templates/{template}.ftl

Now I need some suggestions for urls used to list available templates.
If I follow the same pattern used for other resources I should add
mappings like:
/workspaces/templates.{format}
/workspaces/{workspace}/datastores/templates.{format}

But these urls will be intercepted by other Finders, because we have
these mappings:
/workspaces/{workspace}.{type}
/workspaces/{workspace}/datastores/{datastore}.{format}

On the other hand, if I put my new mappings on top, and someone create
a workspace or a datastore called ‘templates’, the
freemarkerTemplateFinder will intercept calls which isn’t supposed to
handle. :slight_smile:

A solution could be to use these mappings:
/workspaces/templates/index.{format}
/workspaces/{workspace}/templates/index.{format}
…

Another solution:
put everything, editing and list urls under /templates/:
/templates/workspaces/{template}.ftl
/templates/workspaces/index.{format}
…

Opinions?

Regards,

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Davide Savazzi
@svzdvd
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

The Windows 8 Center - In partnership with Sourceforge
Your idea - your app - 30 days.
Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

9

On Mon, Oct 29, 2012 at 6:10 PM, David Winslow <dwinslow@anonymised.com> wrote:

Yes, this does seem a bit messy. What prevents a workspace from being named
'templates'?

It seems like the /templates prefix is the simplest solution.

Hmm... let's see this one. If we put it in templates, and we look at
the fully developed
url allowing us to reach any template we get:

/templates/workspaces/<template>
/templates/workspaces/<workspace>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/featuretypes/<featuretype>/<template>

Don't we have the same issue than before? What if someone names a
template like a workspace?

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

10

On Mon, Oct 29, 2012 at 6:24 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Oct 29, 2012 at 6:10 PM, David Winslow <dwinslow@anonymised.com> wrote:

Yes, this does seem a bit messy. What prevents a workspace from being named
'templates'?

It seems like the /templates prefix is the simplest solution.

Hmm... let's see this one. If we put it in templates, and we look at
the fully developed
url allowing us to reach any template we get:

/templates/workspaces/<template>
/templates/workspaces/<workspace>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/featuretypes/<featuretype>/<template>

Don't we have the same issue than before? What if someone names a
template like a workspace?

To clarify, what if a workspace is named "header", "footer",
"contents", "time" and so on?
It would seem we'd end up with even more collision cases.

A solution out of it could be to force the template url to always have
.ftl at the end, but I'm
not sure this is kosher REST wise (don't we have a default representation), plus
workspace names can contain points as far as I can remember (but ok, someone
naming a workspace header.ftl is really looking for trouble).

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

11

On Mon, Oct 29, 2012 at 6:28 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

/templates/workspaces/<template>
/templates/workspaces/<workspace>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/featuretypes/<featuretype>/<template>

Don't we have the same issue than before? What if someone names a
template like a workspace?

Actually, the issue above is easily solved by using this hierarchy:

/templates/<template>
/templates/workspaces/<workspace>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/<template>
/templates/workspaces/<workspace>/datastores/<datastore>/featuretypes/<featuretype>/<template>

(just changed the location of the main templates).

This way a template can only conflict with the name 'workspaces',
'datastores', 'featuretypes' and 'coverages',
which is no conflict today and unlikely to happen in the future too.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

12

If the new top level hierarchy is simplest then no super strong objection but it does seem like sacrificing api because of an implementation detail. There is also the issue of security… keeping the top level resource as workspace makes it easier to apply workspace security… whereas continuing to add new resource “roots” basically means a special case.

I kind of like David’s suggestion of just having template support merged into the main set of catalog resources and basically ensure that templates is a reserved word.

Also can we get around this by in the mapping file hardcoding the “.ftl” suffix? So the mappings would look like:

/workspaces/templates.ftl
/workspaces/{workspace}/datastores/templates.ftl

Or does that still lead to a conflict?

On Tue, Oct 30, 2012 at 3:18 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Oct 29, 2012 at 6:28 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

/templates/workspaces/
/templates/workspaces//
/templates/workspaces//datastores//
/templates/workspaces//datastores//featuretypes//

Don’t we have the same issue than before? What if someone names a
template like a workspace?

Actually, the issue above is easily solved by using this hierarchy:

/templates/

/templates/workspaces//
/templates/workspaces//datastores//
/templates/workspaces//datastores//featuretypes//

(just changed the location of the main templates).

This way a template can only conflict with the name ‘workspaces’,
‘datastores’, ‘featuretypes’ and ‘coverages’,
which is no conflict today and unlikely to happen in the future too.

Cheers
Andrea

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

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.

13

On Tue, Oct 30, 2012 at 2:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I kind of like David's suggestion of just having template support merged
into the main set of catalog resources and basically ensure that templates
is a reserved word.

Hum, I like this path, seems cleaner, but I have a concern.
Later down the road I'd like to request the PSC that this change to be
backported
to the 2.2.x series.
I did not foresee any particular trouble since this was meant to be purely
additive functionality, but adding a constraint on valid workspace name may
increase the likeliness of a negative vote.

Also can we get around this by in the mapping file hardcoding the ".ftl"
suffix? So the mappings would look like:

/workspaces/templates.ftl
/workspaces/{workspace}/datastores/templates.ftl

Or does that still lead to a conflict?

Would lead to a convention breakage, when we ask for templates.ftl we
are supposed
to get back a xml or json file.

Besides, can workspaces have dots in the name? I think so, in this
case templates.ftl is less likely
to generate a conflict than templates, but still possible

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

14

On Tue, Oct 30, 2012 at 7:52 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 30, 2012 at 2:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I kind of like David’s suggestion of just having template support merged
into the main set of catalog resources and basically ensure that templates
is a reserved word.

Hum, I like this path, seems cleaner, but I have a concern.
Later down the road I’d like to request the PSC that this change to be
backported
to the 2.2.x series.
I did not foresee any particular trouble since this was meant to be purely
additive functionality, but adding a constraint on valid workspace name may
increase the likeliness of a negative vote.

Sorry I don’t quite understand, you are saying that the additional constraint of “templates” being an invalid workspace name will make this less backportable?

Also can we get around this by in the mapping file hardcoding the “.ftl”
suffix? So the mappings would look like:

/workspaces/templates.ftl
/workspaces/{workspace}/datastores/templates.ftl

Or does that still lead to a conflict?

Would lead to a convention breakage, when we ask for templates.ftl we
are supposed
to get back a xml or json file.

Right, my idea was that you would only have one representation, the “ftl” one. I agree if the template is going to be returned in an XML or JSON representation this doesn’t make sense.

Besides, can workspaces have dots in the name? I think so, in this
case templates.ftl is less likely
to generate a conflict than templates, but still possible

Cheers
Andrea

–

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

15

On Wed, Oct 31, 2012 at 3:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I did not foresee any particular trouble since this was meant to be purely
additive functionality, but adding a constraint on valid workspace name
may
increase the likeliness of a negative vote.

Sorry I don't quite understand, you are saying that the additional
constraint of "templates" being an invalid workspace name will make this
less backportable?

Not really, just that if someone already has a workspace named like that
and installs the xslt module there will be troubles.
But I'm probably overthinking it, all we need to do is to explicitly state the
issue in the module documentation.

We'll go this way.

> Also can we get around this by in the mapping file hardcoding the ".ftl"
> suffix? So the mappings would look like:
>
> /workspaces/templates.ftl
> /workspaces/{workspace}/datastores/templates.ftl
>
> Or does that still lead to a conflict?

Would lead to a convention breakage, when we ask for templates.ftl we
are supposed
to get back a xml or json file.

Right, my idea was that you would only have one representation, the "ftl"
one. I agree if the template is going to be returned in an XML or JSON
representation this doesn't make sense.

Indeed it is, automated clients can do little with the HTML representation,
since "templates" is the list of templates, not a particular one.

Cheers
Andrea
--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

16

On Wed, Oct 31, 2012 at 8:30 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Oct 31, 2012 at 3:19 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I did not foresee any particular trouble since this was meant to be purely
additive functionality, but adding a constraint on valid workspace name
may
increase the likeliness of a negative vote.

Sorry I don’t quite understand, you are saying that the additional
constraint of “templates” being an invalid workspace name will make this
less backportable?

Not really, just that if someone already has a workspace named like that
and installs the xslt module there will be troubles.
But I’m probably overthinking it, all we need to do is to explicitly state the
issue in the module documentation.

We’ll go this way.

Also can we get around this by in the mapping file hardcoding the “.ftl”
suffix? So the mappings would look like:

/workspaces/templates.ftl
/workspaces/{workspace}/datastores/templates.ftl

Or does that still lead to a conflict?

Would lead to a convention breakage, when we ask for templates.ftl we
are supposed
to get back a xml or json file.

Right, my idea was that you would only have one representation, the “ftl”
one. I agree if the template is going to be returned in an XML or JSON
representation this doesn’t make sense.

Indeed it is, automated clients can do little with the HTML representation,
since “templates” is the list of templates, not a particular one.

Well my idea was that it would a plain text representation, the contents of which would be the raw ftl sources.

What will the json/xml representation look like?

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

17

On Wed, Oct 31, 2012 at 3:41 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Well my idea was that it would a plain text representation, the contents of
which would be the raw ftl sources.

What will the json/xml representation look like?

Ok, we have two types of resources:
a) rest/workspaces/templates
b) rest/workspaces/templates/footer.ftl

a) is the list of templates available on disk, the actual ones.
It's not ftl, it's a list of links to the actual ftls.
This one would be html, xml or json, just like the layer list or anything else.

b) is the actual ftl, I only foresee the ftl representation itself, and the
idea of using text/plain as the content type makes a lot of sense

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------