Main Points

This page runs off the same ASP.NET master page as version 8, however, it accesses the master page from a different directory (a common situation we'll frequently implement, a subdirectory).

Master Page Initial Evaluation

The initial page condition is pretty much as I expected. The links that were giving me so many problems on version 8 are working beautifully with the runat="server" in the <head> tag. The page is coming out fully styled and includes the favicon. However, the javascript, is not in any kind of evidence. Rollovers don't work, menus are inoperative, and the clock isn't working. We'll have to attack the JS stuff now.

Skip to Main Points

Javascript and Root Relative Paths

OK, there turn out to be a number of ways to incorporate javascripts. One that does NOT work, I was already familiar with. In ASP.NET the runat="server" and use a ~ trick which is basically how I'm hooking up the CSS, does not work for Javascript. I ran across enough information when dealing with the css <link> tags that I knew it was not a viable option. It simply makes the server think the tag is running a server side script. Ooo... that's bad.

There were three recommendations I got on Javascripts. One was to use a ScriptManager object to incorporate the javascript; the guy who recommended it uses it routinely for his AJAX which is cool. This might be something to look into, but I'm not really up to any kind of speed on AJAX yet, so that's probably more fire power than I need right now. Another guy recommended using a RegisterClientScript object. I spent enough time studying it to figure out how to piece together a RegisterClientScriptInclude to incorporate my js file neatly. However, I don't know if this allows any control over where the script tag is written into page, my Javascript is programmed unobtrusively and has to come at the end of the file right before the </body> tag.

Another guy said that a leading slash, /, turns a relative reference into an application root relative reference (much like a ~). I believe I had tried this working with the CSS so I was not very kosher on it. But then... I tried a LOT of stuff to get the CSS up and running and I don't have a very good handle on what I did and didn't test and what else was going on with the files at the time. Since the / was the simplest recommendation I got, I tried it first.

I first tried throwing a leading slash in front of the relative link, ie src="/Scripts/earthchronicle.js". However, when I uploaded it, it didn't work. I was about ready to go looking for the syntax on the RegisterClientScriptInclude when I realized that the Scripts folder was not actually in the application root so even if the leading slash was working, my syntax wouldn't. I revamped the script source to src="/ECBeta/Scripts/earthchronicle.js" and voila! Everything javascript based started working. The leading slash method seems to work fine and until it breaks somewhere, I'm going to run with it.

Skip to Main Points

Javascript File Fixes

Or at least it worked with one important exception. While the image in the contact form was referenced in .NET and pulls fine, the mouseover and mouseout images were defined in the .js file. When you rollover the image and rollout the image disappears replaced by the alt text only and never comes back. However, the guy on the board said that the leading slash technique was not ASP.NET based, but Windows based. I decided to put that to the test and add /ECBeta/ to the page relative references in the rollover code. The images work fine after that.

if (document.getElementById("ctl00_compContactForm_contactImage")) {
document.getElementById("ctl00_compContactForm_contactImage").onmouseover = function() {rollover("/ECBeta/Images/ContactUsBoxHighlight.jpg")};
document.getElementById("ctl00_compContactForm_contactImage").onmouseout = function() {rollover("/ECBeta/Images/ContactUsBox.jpg")};
}

So the entire javascript seems to be working now that the image rollover has been modified. I was also able to achieve application root relative hrefs on anchor tags using the leading slash technique. While I had read enough that I was not worried about building root relative links, this implementation indeed made it very easy. I rebuilt the webpage links with leading slash root relative paths and checked pages version 8 & 9. Looking good! I will need to conduct a full review, but does this really complete my master page testing? After further review, I believe it does. At least enough that I'm going to build full mock ups for all three sites (EC, Beta, and Atlas) to get all those configurations up and working structurally.

Skip to Main Points

Master Page Final Notes

Optimally, it would be more object oriented to put the unchanging part of the document head in a component .ascx file. In fact, I have already done so. Those lines can be replaced with the component tag and the "attribute" can be removed from the head tag. However, on my server forward slash references must be made /ECBeta and on my development machine they must be made /webroot/ECBeta which I don't understand. That means for now I'm stuck with it. So I'm incorporating the doc head into the master page because the ~/ECBeta works on both. This will make it MUCH easier to continue to develop and I can always deploy the .ascx file later if it becomes more important than ease of development. This approach will at least allow the pages to compile and for me to view what the page basically looks like on my development machine.

There are a couple issues that remain unresolved. While I have limited my use of the forward slash technique the development server in Visual Web Developer 2005 assumes that /webroot must be included while my IIS production server demands that this initial directory be removed. Therefore, the current setup does not accurately reflect the production server's CSS and javascript. I have to add /webroot to the beginning of the path reference in the master page in order to get the script tag to work, and I have to do the same to the path in the css file to get the structural stylesheet in the EC/AllSites/CSS folder to operate. But I can get the page to compile and display, with those exceptions. I intend to leave things set up this way for the production server, and on those occasions where I need to test the Javascript or the "real" CSS, I can temporarily add the /webroot so I can take a look.

This problem is now mostly buried. Thanks to the ResolveClientUrl() method, I can address any .NET active files to the appropriate paths. In most cases the tilde version, ~, of the application root relative reference is sufficient. It does not work however, for <link> tags that insert CSS and <script> tags that insert javascript, ie its not supportive of Separation of Concerns. (SoC) Grrrrr... Using ResolveClientUrl(), I can now insert path names that are understood by both the dev box and production server, meaning I no longer need to modify the link and script elements when moving files from one server to another.

[chroniclemaster1, 2009/09/18]

Skip to Main Points
<-- Back to 8. Wiring It All Up
Continue to 10. Nested Master Page -->
<---- Jump back to Master Page Development