Forming Query String URLS in Xslt

Topics: XSLT
Sep 24, 2011 at 7:30 PM
Edited Sep 24, 2011 at 8:35 PM

I'm using 

Composite C1 2.1.3 (BETA 2)
Build no. 2.1.4204.22417
Modified heavily, but I think this is a C1 issue.  
Ampersands processed through Xslt are replaced by & which destroys query strings.
& is still replaced with the entity instead of the character.
  
<xsl:value-of select="concat('?a=', $A, '&amp;b=', $B)" />
<xsl:value-of select="concat('?a=', $A, '&#38;b=', $B)" />
Create query strings resembling "?a=1&amp;b=2" which have no parameter named b
How can I form a query string with multiple parameters in xslt?
This approach won't work for urls with dynamic parameters http://compositec1.codeplex.com/discussions/260547

EDIT:

Nevermind, I had some errors elsewhere

EDIT2:

Fixed errors, still an issue. 

Sep 24, 2011 at 9:34 PM
Edited Sep 24, 2011 at 9:37 PM

OK, so Xslt by design will output &amp; which is usually translated by browsers fine.

But I was looking at the page with Chrome, then viewing source (Ctrl+U). The source viewed there will have the entity string, and most urls with it won't work when clicked. 

When viewing the source by Right Click →Inspect Element well-formed urls are displayed. In essenece, multi-params in urls from xslt should work, and usually do.

I was running into I hope a C1 issue as described in another thread about Query String parameters and my Beta version of C1 and also trying to visit un-unencoded links from view-source: in Chrome.

http://compositec1.codeplex.com/discussions/262718

Coordinator
Sep 26, 2011 at 8:19 AM

>> OK, so Xslt by design will output &amp; which is usually translated by browsers fine.

Yes, it is by design, otherwise the result document won't be an well-formed xml. I would say - that's a bug in chrome source editor that you cannot follow those links.

>> I was running into I hope a C1 issue as described in another thread about Query String parameters and my Beta version of C1 and also trying to visit un-unencoded links from view-source: in Chrome.

>> http://compositec1.codeplex.com/discussions/262718

It is fixed in latest builds, and will work correctly in the next release

Sep 26, 2011 at 8:30 AM
napernik wrote:

It is fixed in latest builds, and will work correctly in the next release

unless you're actually pushing the source to codeplex, which you're obviously not, its hard for us, the users, to actually confirm that its positively fixed for the exact scenario, wouldn't you say?

Coordinator
Oct 14, 2011 at 9:34 AM

>> unless you're actually pushing the source to codeplex, which you're obviously not, its hard for us, the users, to actually confirm that its positively fixed for the exact scenario, wouldn't you say?

It looks like a hidden accuse that we aren't synchronizing the changesets often enough, the reason for that is that we do checkins only when we're sure that all up-to date functionality is tested. You can find the fix for that particular issue here 

http://compositec1.codeplex.com/SourceControl/changeset/changes/9323 file PageUrlHelper.cs, line 481