Can't believe I haven't ran into this before but I'm trying to create a URL using an xsl:variable but can't find the correct way to add query string parameters.
I want to render an <img> tag but the source URL of which is created dynamically, (for WebTrends). The "WT" variable is where I intended the magic to happen but I just can't the "&" in the query string parameters without either:
Thinking about this for another few seconds I'm not sure you'll even need the disable-output-escaping="yes" portion of the <xsl:text> tag. Try it without first and you should be okay.
Do bear in mind that though you don't usually see & on the querystring of a browser it is perfectly valid and supported by all browsers, so don't let it bother you if the url you end up with has & in it rather than the shortened & only... both work just fine in the real world. :)
I always though it had to be "&" not "&". Its crucial that the query string parameters are retrievable - otherwise the WebTrends tracking will not work.
Note that replacing & with
& is only done when
writing the URL
in
HTML,
where "&" is a special character (along with "<"
and ">"). When writing the same
URL
in a plain text email message or in the location bar of your browser,
you would use "&" and not "&". With
HTML,
the browser translates "&" to "&" so the Web server would
only see
"&" and not "&" in the query string of the request
XSLT problem
Can't believe I haven't ran into this before but I'm trying to create a URL using an xsl:variable but can't find the correct way to add query string parameters.
I want to render an <img> tag but the source URL of which is created dynamically, (for WebTrends). The "WT" variable is where I intended the magic to happen but I just can't the "&" in the query string parameters without either:
Thanks for any help,
The problem is that the ampersand character is a 'special' character in XSLT, so it must be escaped in your xslt, as &
In your code, I would do something like this:
or...
cheers,
doug.
Thinking about this for another few seconds I'm not sure you'll even need the disable-output-escaping="yes" portion of the <xsl:text> tag. Try it without first and you should be okay.
Do bear in mind that though you don't usually see & on the querystring of a browser it is perfectly valid and supported by all browsers, so don't let it bother you if the url you end up with has & in it rather than the shortened & only... both work just fine in the real world. :)
cheers,
doug.
Hi Neil,
Remember CDATA is your friend! (modifications in bold below)
Cheers, Lee.
Thanks,
As Doug pointed out, this results in the following URL:
dcs.gif?WT.seg_2=mobile&RAND=11111
I always though it had to be "&" not "&". Its crucial that the query string parameters are retrievable - otherwise the WebTrends tracking will not work.
Neil
In fact, using "&" only breaks xhtml validation. Browsers can work with both though so it's not something to worry about. From the linked page...
-----------------------------------------------------------------------------------------------
To avoid problems with both validators and browsers, always use & in place of & when writing URLs in HTML:
<a href="foo.cgi?chapter=1&section=2&copy=3&lang=en">...</a>
Note that replacing & with & is only done when writing the URL in HTML, where "&" is a special character (along with "<" and ">"). When writing the same URL in a plain text email message or in the location bar of your browser, you would use "&" and not "&". With HTML, the browser translates "&" to "&" so the Web server would only see "&" and not "&" in the query string of the request
-----------------------------------------------------------------------------------------------
Dan
Thanks Dan,
But when I click the created link:
the browser (Chrome) windows open with the "&" intact in the address bar. That's to be expected? It wouldn't "translate" the "&" back to "&"?
Neil
Did my XSLT not work for you Neil? Take another look... check you are using the CDATA data - and disable-output-escaping on the value-of.
Cheers, Lee.
It did Lee - once I read the page Dan linked to and realised that "&" is the valid approach.
It was just throwing me a little when I clicked the link and saw the "&" in the address bar - I just assumed the browser would change this.
Thanks
is working on a reply...