Breaking URL's in Master Pages

Monday, March 31, 2008

Breaking URL's in Master Pages

Hi,

This blog post summarizes a how url breaks in Master Pages.

Breaking URL’s in Master Pages

·                You must be careful when using relative URLs in a Master Page.

·                Relative URLs are interpreted in different ways, depending on whether they are used with HTML tags or ASP.NET controls.

·                In Master page when you put any link or image [Whether Server control or HTML control], the url that we provide is always relative the Master page.

·                Now When we include this Master Page in the content page below happens

o                      If the Master & Content page lies in the same hierarchchy then the link or the image behaves properly.

o                      If not then

§                             The Server Control behaves perfectly, but

§                             The HTML Control do not.

·     i.e the link or the image won’t be visible.

·     Reson being: For HTML controls, the URL is always  is interpreted relative to the Content Page.

o                      .i.e

o                      As long as the master page and the web form live in the same directory, the company logo will display in the browser. When the master page and web form live in different directories, the image will not appear.

o                      Solutions:

               Solution 1:

There are few solutions for this:

·                            Include the runat=”server” attribute to the HTML controls.

·                            This will result into a new feature said to be ‘Re-Basing’.

·                            The ASP.NET runtime will also rebase paths it finds inside of the head tag, as it also contains runat=”server” attribute.

o   E.g.

<head runat="server">
<title>Untitled Page</title>

  <link href="styles/styles.css" type="text/css" rel="stylesheet"/>

</head>

o                      Here If we request a webform from a subdirectory, the runtime will catch the href inside the link tag and rebase the URL to "../styles/styles.css".

               Solution 2:

§                            Is to use a method to reinterpret relative URLs in a Master Page.

§                            E.g.

§

Public Function MasterUrl(ByVal url As String) As String

Return String.Format("{0}/{1}", Me.TemplateSourceDirectory, url)

End Function

</script>

<title>Image Master</title>

</head>

<body>

<div>

<img src='<%=MasterUrl("Logo.gif") %>' alt="Website Logo" />

<asp:contentplaceholder id="ContentPlaceHolder1" runat="server" />

</div>

</form>

</body>

</html>

Situations where Rebasing does not work.

§           However, the runtime doesn’t catch everything. If we included our style sheet with the following code, the runtime  won’t  rebase the relative href.

<head runat="server">

<style type="text/css" media="all">
@import "styles/styles.css";
</style>

</head>

§           Also, the runtime doesn’t rebase URLs inside of embedded styles, and not all attributes are covered (the background attribute, for instance).

Solution for embedded styles:

§                            When working with image paths in embedded styles, it’s often a good idea to move the style definition into a .css file.

§                            Relative paths are safe inside a .css file because the browser will always request logo.gif relative to the location of the stylesheet.

body
{
background-image:url('images\logo.gif');
}

Solution for Background Attributes:

§                            If you need to use a relative path in an area where the runtime does not provide the rebasing feature, you can compute a client side URL using ResolveClientUrl and passing a relative path. ResolveClientUrl, when called from inside a master page, will take into account the location of the master page, the location specified in the HTTP request, and the location specified by the relative path parameter to formulate the correct relative path to return.

Hope this helps.

Arun Manglick

Arun Manglick - Technical View

Labels

Monday, March 31, 2008

Breaking URL's in Master Pages

Breaking URL’s in Master Pages

No comments:

Post a Comment