One thing that may seem obvious to some and not others, by allowing the dynamic script loading via url, there is the possibility of malicious code being written and supplied at the URL.

The rationale for even adding this was that our W-2 vendor did not want to re-write some oftheir source to allow our styling to persist via url, this meant that their links should all have the style appended to them. That seemed like a bit of work, so I suggested using the dynascript - and I would do all the heavy lifting of code via javascript.

After some conversations, we decided not to go that route...Although a good idea for us as we have an established trust and reuqests can only come from our portal for direct access to their application, adding this logic would open them up for anyone to supply js at the url, so that was a bad idea...

We finally got them to do url rewrites on their links, and even though their rendered code is table based and poorly formatted, I was able to override the styles and position elements in a nice looking and usable (familiar) fashion.

Enjoy!

I see no reason to use this construct:

Thanks for point out a flaw - it should only be looking for URL parameters - but the original code is taking the URI as a literal string and not parsing the pieces of the URL. However, the 'style' variable is only being pulled from the Request.QueryString so there would be an invalid or missing stylesheet.

I have updated this, see the modified code below.