emptytemplate as new keyword in mapfile

[silke@…]

Instead of only returning a static html-page by the empty-tag in the
mapfile we often would like to return a template where some query 
specific information such as the coordinates of the query etc. can 
be filled in.

We therefor added the keyword "emptytemplate" to the mapfile.
It can be defined in the WEB object. Such you can specify a template 
which will be returned when the query has no results.

We are working quite a while with this enhancement and would like to 
see it in the main mapserver code. So it would be nice if you could 
have a look on it and submit it into cvs if appropriate. The patch 
on [1] is based on mapserver 4.2.3 since this is the version I am 
currently working on.

[sdlime]

Actually, instead of adding a new keyword I would prefer changing the behavior 
of the EMPTY parameter. Treating it like a normal query template would 
probably suffice, except that there would be no results to process. Both 
filebased and URL templates could be supported then. Does that sound 
reasonable?

This may be scope for 4.4, cc'ing Dan on that...

Steve

[dmorissette]

No problem with me.

[silke@…]

I am not sure whether this is a good idea. Currently the EMPTY parameter is
provided as URL to a html page. If we define EMPTY as template the new mapfile
will not be compatible with the old one. This is the reason why we introduced a
new paramter.

But if you don't want to introduce a new parameter this is OK for me as well.

[sdlime]

Actually changing the EMPTY parameter this way (unless I'm missing something) 
quite compatible. The CGI has always supported URL templates and they could be 
static pages just as easily URLs that took on feature attributes. So a query 
template of:

  TEMPLATE 'http://www.google.com'

is perfectly valid.

Did you have additional template tags defined (eg. [foo]) or are the standard 
template tags enough?

Steve

[silke@…]

Oh, I didn't knew that URL templates are supported. If this is the case I don't
see any reason why EMPTY shouldn't just be enhanced to work as template as well. 

The standard tags are absolutly sufficient. 

Greetings, Silke

[sdlime]

I've committed a fix for this just a few minutes ago. Both the ERROR and EMPTY
values are processed as URL templates so all normal substitutions will work
fine. I also added a new template tag [errmsg] (and [errmsg_esc]) so that the
current error stack can be passed along as part of the URL. Errors in the stack
are seperated by semi-colons. This obviously impacts only the CGI application.

So, you can do things like:

EMPTY 'http://www.yourserver.com/notfound.html?xy=[mapxy_esc]'
ERROR 'http://www.yourserver.com/error.html?error=[errmsg_esc]'

The [errmsg] will evaluate to an empty string if no errors are present in the
stack at the time of processing. Might be a helpful debugging tool. If the error
is in the mapfile parsing (so we can't get to ERROR or EMPTY) then the generic
MapServer error page is produced.

Silke, I've tested here and this is backwards compatible, but please check to
make sure it meets your needs. Marking fixed for now.

Steve

[sdlime]

*** Bug 264 has been marked as a duplicate of this bug. ***

[silke@…]

Sorry for my late reply. I thought that I already tested the new EMPTY tag but
it seems that it slipped through my attention.

In fact it seems that there has been a misunderstanding. What I am interested
for is to use the tags inside the HTML-page to give some additional information
to the user, something like the coordinates he clicked etc. Your patch just
enables me to get the values into the URL.

So I would again like to ask you to apply my patch to the UMN MapServer to
enhance by this functionality.

Thanks, Silke

[sdlime]

I don't want to add another keyword and would propose extending EMPTY to allow 
file templates as well...

Steve

[silke@…]

This is OK with me as well. Shall I enhance the EMPTY keyword by adapting our
patch or will you bother to do this?

      Silke

[sdlime]

Still a good idea, but for 5.2 or beyond...

Steve

[sdlime]

Silke: There was mention of a patch, did it ever go anywhere? I have time to address if you folks did more work along those lines. I realize it's been ages though.

Steve

[sdlime]

Moving to future, I see no reason to spend time on it at this point.

Steve