Idea feedback (pre-RFC)

[Steve Lime]

Different problem but it should be possible to handle now since browse templates
are only one document anyway. There's no reason you can't construct a JSON or
XML template. I've been doing that for a long time. With clients that manage size
and extents it's not as useful as it once was but it can be done. Just use mode=browse
instead of mode=map. The only limitation is that you can't set the browse mode
mime-type (default is text/html) but that minor in most cases and we could work 
around it.

Steve

>>> Jan Hartmann <j.l.h.hartmann at uva.nl> 10/18/07 10:37 AM >>>
Not sure if this is the same problem, but could this also include a way 
to return al MAP-parameters as XML or JSON? Currently, things like 
mapsize and mapextent are returned via templates, which need an extra 
template file. I could imagine to get them back directly as XML or JSON. 
Again, I'm not sure if this is the same as what Steve means, but it 
would be a nice thing nice to have.

Jan

Steve Lime wrote:
> Hi all: I wanted to float an idea that I been thinking about since the conference and talking about KML related to CGI templates and accessing drivers such as GML and KML (when implemented) when processing query results.
> 
> Problem: 1) Currently a driver like GML isn't available to the CGI as a means of presenting query results. 2) The templating scheme (HEADER/TEMPLATE/FOOTER) for queries isn't user friendly nor is it ammenable to multple presentation formats. That is, one layer => one template set.
> 
> Solution:
> 
> 1) Use output format objects to define formats that can be used to output query results in addition to drawing images. 
> 
> E.g. 
> 
> OUTPUTFORMAT
>   NAME 'gml3'
>   DRIVER GML3
>   MIMETYPE 'text/xml'
> END
> 
> Might need to extend that object to discriminate between map rendering and query formatters but that can happen in mapdraw.c and mapserv.c too. That is, drivers are explicitly referenced in those places so if someone tries to draw a map with a GML3 driver it would throw an error.
> 
> 2) Use the webObj QUERYFORMAT property to reference formats: 'QUERYFORMAT gml3'. Right now that property carries a mime-type but it could be used to reference a format too.
> 
> 3) Define a TEMPLATE driver. Basically this would just invoke the normal query templating scheme.
> 
> E.g.
> 
> OUTPUTFORMAT
>   NAME 'kml'
>   DRIVER TEMPLATE
>   MIMETYPE '...'
>   FILE 'myTemplate.kml'
> END
> 
> OUTPUTFORMAT
>   NAME 'geojson'
>   DRIVER TEMPLATE
>   MIMETYPE 'text/plain'
>   FILE 'myTemplate.js'
> END
> 
> 4) Note that in the above examples we reference a file, so I'm thinking of supporing a single template system for queries in addition to the current mechanism. To do this I'd propose 2 new template tags: [layer] and [feature]. These would be blocks. An example might be:
> 
> ...old web HEADER content goes here...
> [layer name=lakes]
>   ... old layer HEADER stuff goes here, if a layer has no results this block disappears...
>   [feature]
>     ...repeat this block for each feature in the result set...
>   [/feature]
>   ...old layer FOOTER stuff goes here...
> [/layer]
> [layer name=streams]
>   ... old layer HEADER stuff goes here, if a layer has no results this block disappears...
>   [feature]
>     ...repeat this block for each feature in the result set...
>   [/feature]
>   ...old layer FOOTER stuff goes here...
> [/layer]
> ...old web FOOTER content goes here...
> 
> This would allow for relatively complex text files of any sort to be built from multiple layers. All the normal template tags would still be supported but those normally available for query results would only be valid inside a [feature]...[/feature]. These tags would work with existing system too but just wouldn't be as useful as with the 1 template idea.
> 
> One gotcha is that by moving the template to the output formatting object we loose our mechanism to mark a layer as queryable, but we've wanted to provide an alternative to that anyway. 
> 
> Anyway, I see this as being much more flexible. One could define templates or just access drivers for GeoJSON, KML, Metacarta text files, or whatever with one layer defn and multiple output formats. We could add a parameter to the CGI to change formats easier (as opposed to map.web.queryformat).
> 
> Thoughts? If positive I'll write up a detailed RFC.
> 
> Steve
>