Dealing with Master Page Shortcomings

M

Mark Olbert

Has anyone found useful tutorials on how to deal with the shortcomings of master pages, specifically, the fact that they don't
handle HTML file references when used to create web pages anywhere other than the root folder of a website?

I'm familiar with using the runat="server" workaround for img tags (and supposedly that works for <a> tags, too). And I've noticed
that you can use absolute addressing if you're willing to forgoe seeing images on your webpages at design time. But both these
approaches seem like kludges. Frankly, Microsoft should've done a better job of addressing this issue (Dreamweaver handles the
problem pretty well, and has for years).

- Mark
 
Y

Yuan Ren[MSFT]

Hi Mark,

Welcome to MSDN newsgroup!

Based on my understanding, the current problem is that the Master Page can
not be applied to the Html page. If I have misunderstood anything, please
let me know.

As far as I know, the Master Page function is only designed for the ASP.NET
page not the Html page or something else. Since the Visual Studio is the
development tool, I suggest you use the Microsoft FrontPage to design the
Html page. I think the FrontPage has more function for design the Html
page. I appreciate your understanding and hope you have a good experience
with it.

Regards,

Yuan Ren [MSFT]
Microsoft Online Support
 
M

Mark Olbert

Yuan,

Sorry, you misunderstood me and/or I wasn't clear.

The problem is this. If you create a master page in the root of your website that references an html resource:

<!-- master file example, details omitted -->
<img src="path/to/some/picture.gif" />

And then you create a content page in a subdirectory of the website, the image file will not display because the file path is
searched relative to the subdirectory. This problem isn't limited to <img> tags; it affects any plain HTML element that uses a url
reference.

I know of two ways to resolve this problem. Add a runat="server" tag to the <img> (or <a>) tag in the master page file:

<img src="path/to/some/picture.gif" runat="server" />

or use absolute references:

<img src="/root/path/to/some/picture.gif" />

The absolute reference approach prevents you from seeing the images in your master file while you edit it. The runat approach might
increase server load (I'd like to know if that's the case).

I'm wondering if there is any other workaround.

- Mark
 
S

Scott Allen

The absolute reference approach prevents you from seeing the images in your master file while you edit it. The runat approach might
increase server load (I'd like to know if that's the case).

I'm wondering if there is any other workaround.
Click to expand...

There are a couple other apporoaches. One is to use a skin, and a
SkinID on the image. Images inside of themes are a little easier to
manage (it's still essentially a server side control, though, because
that would be skinning an asp:Image tag.

Another approach is to specify the image using a class inside a style
sheet. Images are pulled relative to the stylesheet location, so you
only have to worry about including the stylesheet from the correct
directory (which is easy with themes, since the runtime auto-magically
adds them to the <head>).
 
C

Christopher Reed

I believe that you need to reverse your thinking regarding master pages.
When the ASPX page is rendered, it uses the master page to accomplish some
of that rendering. So, the ASPX page is really the base and master page is
associated with it, meaning that everything in the master page should be
associated to the potential location of your ASPX pages.

I hope this makes sense.
 
M

Mark Olbert

Christopher,

It makes perfect sense. But that kind of master page is less useful than the one that works the other way (which is what is implied
by the term "master page" in the first place).

- Mark
 
C

Christopher Reed

It's my guess that the phrase "master page" is the confusion. For example,
a master document in Word is just that: the main document that controls the
rest of the Word documents.

A master page in ASP.NET, as I see it, is nothing more than a fancy include
file (a la Classic ASP) or a grand user control (a la ASP.NET 1.x). In
fact, I prefer its role because it allows me as I'm working on a website to
be able to pull items that I keep using over and over and put them there in
the master page. So, I guess maybe the naming convention of "master page"
could have thought out more.
 
T

tdavisjr

Christopher said:
It's my guess that the phrase "master page" is the confusion. For example,
a master document in Word is just that: the main document that controls the
rest of the Word documents.

A master page in ASP.NET, as I see it, is nothing more than a fancy include
file (a la Classic ASP) or a grand user control (a la ASP.NET 1.x). In
fact, I prefer its role because it allows me as I'm working on a website to
be able to pull items that I keep using over and over and put them there in
the master page. So, I guess maybe the naming convention of "master page"
could have thought out more.
Click to expand...

Yes. Your are correct. Once again, the marketing folks dropped the
ball again. In v 1.1 with the concept of user controls and now in V 2.0
with MasterPages.
 
M

Mark Olbert

Or maybe they didn't. "Master Page" sounds a lot more impressive than "super user control" :)...and it also sounds like it delivers
on a known need, even if it doesn't, quite.

- Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

trouble with rollover buttons on master page 4
Asp.net Important Topics. 0
comp.lang.c Answers to Frequently Asked Questions (FAQ List) 15
comp.lang.c Answers to Frequently Asked Questions (FAQ List) 1

Members online

No members online now.
Total: 127 (members: 1, guests: 126)
Robots: 358

Forum statistics

Threads
474,432
Messages
2,571,682
Members
48,796
Latest member
Greg L.

Latest Threads

Top