Opened 20 years ago

Closed 20 years ago

#521 closed enhancement (duplicate)

HTML Legend template parser ignores HTML outside [leg_*_html] tag pairs

Reported by: emiliom@… Owned by: sdlime
Priority: normal Milestone:
Component: MapServer C Library Version: 4.0
Severity: minor Keywords:
Cc:

Description 

The defined behavior of the HTML Legend parser ("Any text or HTML tags outside
the [leg_*_html] tag pairs in the legend template file are ignored by the
template parser.") is too limiting, and seems inconsistent with other template
parsers. Not being able to have HTML code before and after the legend tag pairs
limits the use of this template; for example, when the legend template output is
assigned to a frame or iframe, this output can't be a complete HTML document,
can't have the opening and closing of a table, can't load external CSS and
javascript files, etc.

Change History (8)

comment:1 by sdlime, 20 years ago

Cc: morissette@… added

comment:2 by dmorissette, 20 years ago 

I have seen similar requests a few times, but it's not as simple as it seems. A
legend template can contain up to 3 types of top-level objects... so what do you
do with the HTML that's stuck in-between the [leg_group_html] and the
[leg_layer_html] tags?  To which object does it belong? Do we repeat it for each
layer/group or not? New tags will probably have to be created... this needs much
more thinking. If someone wants to propose a complete and working solution for
the problem then you are welcome to contribute it to the bug report for discussion.

comment:3 by sdlime, 20 years ago 

Wouldn't you just echo them one time as encountered? Perhaps Emilio had some 
examples in mind when he found out this wasn't working.

Steve

comment:4 by dmorissette, 20 years ago 

The thing is that a legend template is not a sequential template like the main
html template of the app. It's a set of up to 3 small templates (layer, class
and group templates) that are going to be repeated inside a loop to generate the
legend.  So the stuff in-between those blocks doesn't naturally belong anywhere.

Here is an example.  Where should the line between the [leg_layer...] block and
the [leg_class...] block be echoed? 

------------
<HTML>
<BODY>
<H1>This is the title of my legend</H1>
<P>

[leg_layer_html order_metadata=WMS_ORDER visibility_flag=15]
<BR><a href="[leg_layer_name]">[metadata name=WMS_TITLE]</a><BR>
[/leg_layer_html]

???here is some text in between, where should we echo it???

[leg_class_html visibility_flag=15]
<img src=[leg_icon]> [leg_class_name]<br>
[/leg_class_html]

</body>
</html>
----------------

comment:5 by emiliom@…, 20 years ago 

I had not thought about HTML elements in between the legend tags. What I had in
mind only involved elements at the top and bottom of the legend file, to serve
as kind of headers and footers to surrournd the legend HTML output. For example,
to have open/close <table> tags, or to create a complete valid HTML page. One
specific use I had in mind was inserting a reference to an external CSS style
sheet via <link href= ... > in the <head> tag.

I can see that html elements in between legend tags would be useful, but is
ambiguous. However, I still think that allowing only html elements before the
first legend tag and after the last one would be a substantial enhancement, even
if it's not a long-term solution.

But talk is cheap! I'm not volunteering to implement this myself. I can program
in C, but haven't worked with the Mapserver code and have precious little free
time. BTW, I ended up solving my problem by using an iframe and some javascript,
in the context of Steve's Landview javascript application; I described this in
an email to the users list a while ago. However, this solution is unnecessarily
complex, I think.

Thank you for the tremendous work you've done with Mapserver! I wish I could
contribute more directly.

comment:6 by dmorissette, 20 years ago

Resolution: → duplicate
Status: new → closed 
Bug 1023 would address this in a simpler way. Marking as duplicate.

*** This bug has been marked as a duplicate of 1023 ***

comment:7 by dmorissette, 20 years ago

Resolution: duplicate
Status: closed → reopened 
Doh! I meant bug 1032 and not 1023!

comment:8 by dmorissette, 20 years ago

Resolution: → duplicate
Status: reopened → closed 

*** This bug has been marked as a duplicate of 1032 ***
Note: See TracTickets for help on using tickets.