In an aspx page, how do you add the html element "script" and make use of the tilde feature on it?

For example, when I put this code in an .aspx or .ascx page:

It is rendered as is. I want the tilde to be resolved as the root path of my webserver. Whenever I use an asp element, it works:

But it seems like there are no asp element for the html element "script".

It's crazy because the preprocess will complain that the file does not exist when using a relative path but when using the tilde, the preprocess will find the file and won't complain. But at run-time it does not resolve the path correctly. So stupid.

It's not stupid really.

As far as the .NET page parser is concerned, the script tag in the HTML:

    <script type="text/javascript" src="~/javascript/dynMenu.js"></script>

is as meanful as a pile of jumbled text:

    lkjoiflkjadkfjaiweraasdfk jaosdfj alsdfkj asdfasfj asdfj aslkfj asdfoi

ASP.NET doesn't care what you have there. It's all just literal HTML. You are directing the BROWSER to deal with the ~ character.

The <asp:hyperlink...> on the other hand is parsed into a server control. When ASP.NET renders that control it pumps the value of NavigateUrl thru the ResolveUrl() method that is found on the System.Web.UI.Page class. This translates the ~ into the full application page:

   ~/images/mypic.jpg -> /myapplication/images/mypic.jpg

The resolved URL is what ends up in the image tag:

   <img src="/myapplication/images/mypic.jpg" />

You need to add programmatic processing to write the javascript tag out, or at least its src attribute.

If you want the script on an ASPX page, you don't need to use the ~ because the page is always in the same place. Just provide the right number of back reference directories to get you back up to the right directory the js file lives in:

    <script type="text/javascript" src="../../javascript/dynMenu.js"></script>

However, if you want to put a script tag on a user control you won't know where the HTML will be emitted (i.e. the user control could be used on a page at the application root or on a page 20 directories deep). Then you need to emit the script tag programmatically to provide a root relative file reference. I usually do that like this:

Markup:

   <asp:literal runat="server" id="litJSTag" />

Codebehind (C#):

   string strTag = "<script type=\"text/javascript\" src=\"{0}\" runat=\"Server\"></script>";
   litJSTag.Text = string.Format(strTag, ResolveUrl("~/javascript/dynMenu.js"));

This will resolve the js file name to the full application path and give you the correct script tag in the literal control. (A literal control doesn't render any HTML other than the .Text property contents. Very handy for emiting various bits of script block of the like.)

You could also use the RegisterClientScriptBlock() method which eliminates the need for a literal control on the page.

-Peter

Thank you very much. That's what we decided to use (the literal trick). We cannot use option 1 because the html is in a template that can be added to any page anywhere. It's a menu.

Alternatively, you can do something like this:

<script src="<%=Helpers.GetCurrentServerRoot()%>/Scripts/Scripts.js" type="text/javascript"></script>

where GetCurrentServerRoot contains code like this:

return HttpContext.Current.Request.ApplicationPath;

I use that a lot, and created a few overloads for GetCurrentServerRoot that can return various flavors of the root path, including the trailing / and the protocol prefix.

Peter: good to see you're back. Let's catch up soon!

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
Want to be my colleague? Then check out this post.

Yes let's. The new job permits for a little more ... er ... 'educational' time. ;)

Yes, a helper method for URL resolution is a very good thing to have lying around. Particularly if your application generates emails in which you want to include links back to the app. Being able to have an easy way to get either a root relative or fully qualified url is essential.

Yet Another alternative; there's no reason you can't resolve only the application root:

<script src="<%=ResolveUrl("~")%>/Scripts/Scripts.js" type="text/javascript"></script>

-Peter

Then how come the following tag is parsed correctly:

    <link href="~/Stylesheets/Standard.css" rel="Stylesheet" type="text/css" />

which also only is literal?

I can't believe this could possibly work. Is this the actual markup in the markup file? If so, I can't see how it works.

-Peter

The problem is a little different.

<link href="~/Stylesheets/Standard.css" rel="Stylesheet" type="text/css" />

does indeed work when you put inside a <head> tag with a runat="server" attribute. .NET will parse paths in the <head> for the ~ and replace them with the correct path.

Theoretically, this could also work for JavaScript files. However as soon as you have a script reference with a runat="server" attribute, .NET thinks it's a *server script* and will try to run it through the parser / compiler, resulting in major errors.
Not sure why a <link> tag doesn't need an explicit runat attribute while the <script> tag does....

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
Want to be my colleague? Then check out this post.

Like Imar says I too believe it's because it's located in the <head runat="server"> tag. If you remove runat="server" the <link> tag will NOT parse the tilde path.

But I don't understand why the <script> (without runat="server") won't parse correctly - this must be a bug, I can't see the logic otherwise.