Edit2: now did some testing and realized that I completely misunderstood the problem (I’ve never used registerScriptFile before or manually added similar links to a web page)
Actually i’d consider this a bug: registerScriptFile() accepts an URL. The script tag will be rendered through CHtml::scriptTag() which encodes the URL - i don’t see, why this should be necessary:
public static function scriptFile($url)
{
return '<script type="text/javascript" src="'.self::encode($url).'"></script>';
}
Ok, guess you’re right: I did a quick test and having encoded & in URLs is fine. It’s only a problem if you copy & paste these URLs into the browser bar. Then the ; got encoded again (e.g. a=b&c=d became a=b&%3bc=d), which gives wrong results.
So if you use registerScriptFile() with a full URL including the GET params, everything should be fine.
I agree with Mike, this is the bug. Because if I want to register script with ‘GET’ parameters (registerScriptFile with ‘POS_HEAD’-like options) - I can’t make this. So i need put this string manually in the main layout (or make another layout for pages, that used this JS code).
The same situation with CSS, if i need to render css ‘on the fly’ depends on GET parameters.
It can be google maps API, youtube js API etc… most of them use GET params.
Sorry to revive this old trhead, this bug seems to stil be there in 1.1.12.
For instance the following url: hxxp://maps.googleapis.com/maps/api/js?key=xxxxxxxxxxxxxxxxxxxxxxxxx&sensor=true&callback=initialize
Will be encoded into: hxxp://maps.googleapis.com/maps/api/js?key=xxxxxxxxxxxxxxxxxxxxxxxxx&sensor=true&callback=initialize
And will produce the following error from google (of course use your own key):
alert("The Google Maps API server rejected your request. The \x22sensor\x22 parameter specified in the request must be set to either \x22true\x22 or \x22false\x22.")
So it makes using registerScriptFile impossible in this case.