I've now implemented master pages formally across all three sites though I have no "real" content pages to show for it. However, it is a successful bench test with a page in the website directory and another in the subdirectory both hooked up and working beautifully. Building master page based sites is no longer a matter of theory and testing, they are now up and running. I can adjust the different pieces to change anything I want and differentiate the sites as I wish (within the limits discussed in these test pages from master page version 8 on). Now I'm going to see If I can implement some pieces across all websites not just by swapping components in and out, but by using a primary master page for what pieces I can and nested master pages for parts that are custom to each website, ie I'm attempting nested master pages.
This is something unusual for a test page. I am revamping the site structure a bit to accomodate a new more standardized beta testing folder structure, and the idea is to freeze the page so it can be appreciated in the "state" that it was in at the time. However, in this case, a key development was running the navbars and other items from a primary store which all websites would draw from. Therefore, I have several imperfect options. I can "freeze" those items locally in the beta site (which is a significant step back from what this page actually accomplished), leave "special" files for testing lying around the primary store (bad management), or not change anything in which case the page won't be frozen. Developments to those user controls would transform this page. So any of the three choices represents a partial compromise. I think I will freeze the files locally here in the beta site. It will preserve the page for people to look at the state of the site in the future, it will prevent leaving files lying around in awkward places, and the changes I need to make will all be behind the scenes and mostly out of people's way.
[chroniclemaster1, 2008/11/25]
Sharing Website Files
I was very disappointed that I could not get references to directories in the app root to work, mainly because I don't understand why it doesn't work. (and can't find anyone else who does either) I wanted to put a Master and a Components folder in the app root and store all my master pages and user controls there for all the websites. However, all references failed to register and returned ASP.NET errors saying that the files could not be found. "~/Master/myMasterPage.master" wouldn't work for beans. I had to place the Master folder inside a subdirectory, "~ECBeta/Master/myMasterPage.master". This is why I didn't realize there was a problem in the first nine master page versions because I was doing all my testing inside the Beta website folder. I'm still hoping to get an explanation why this doesn't work or better, a solution. I'm hoping even more fervently for an explanation why Visual Web Developer 2005 needs a /webroot/ prefix to the application path but the Windows Server 2003 using IIS6 blows up if you have it, but that's a whole other issue. ;)
:D One down. Thanks to a recent tip, we've been able to use the ResolveClientUrl() method to properly address paths for <link> tags that insert CSS and <script> tags that insert javascript. Both the dev box and production server understand this format, do I don't have to changes these references anymore when moving files between the server and the dev box. :)
[chroniclemaster1, 2009/09/18]
In the meantime, I have resolved the issue inelegantly. I placed a folder inside the Earth Chronicle website folder, EC/AllSites. I have placed my Master and Components folders in the AllSites directory and all my references throughout the three websites work beautifully. The primary folders should be in the app root, but this will do because it works.
Skip to Main Points
Nested Master Page Paths
Well, it looks like this test may already have determined that this is not really workable. It's more ridiculous trouble with root relative addressing. I can't believe that Microsoft hasn't built in a more robust system for this by default. I'm sure there are ways of doing this, but from talking with everyone I've spoken with on the various forums, it's clear that these are neither easy or simple solutions. And they are absolutely fundamental to being able to effectively implement master pages so using master pages in not really a technique that can be used except by professionals. Infuriating. They poured blood sweat and tears over making data access easier, but ignored adding CSS and Javascript according to even the loosest best practices. Completely lazy. And it does not inspire my confidence in the real professionalism of the MS development community that a server active script tag has not been implemented as an open source component.
People recognized and poured blood sweat and tears into the CSS Friendly Control Adapters which is an amazing project. That kind of best practices awareness is exactly what is needed here. How can you not build a server control to allow a <link> tag to reference an external style sheet simply and robustly. Creating one for <script> tags and <link> tags is definitely a server control building project that I would like to tackle, but I'm quite sure it's over my head at this point. :( You can tell I'm bitter at the moment. This seems like such an unbelievable oversight, I'm so frustrated. Here's what's happened...
On master page versions 8 & 9, I was able to specify the <link> tags in a component that I pulled in from a .ascx file. However, doing so caused my development computer to stop compiling. While it would be more object oriented to pull out that section, it was not a compelling reason to give up a development server and work strictly on the production box. My solution was to leave the references as tilde technique references and keep the <link> tags in the master page. Well, it turns out it must be in the MAIN master page. Making such a reference even in a Nested Master Page causes ASP.NET to completely ignore the tilde reference just like when I tried to put it in a component. The result is the tilde gets passed straight through to the XHTML output.
This turns out not to be completely true. The <link> tags do not take the runat attribute. The <head> tag does and the <link> tags must be in the SAME master page. If the <head> tag is in the main master page, that's where the links need to be. However, the <link> tags can go in the nested master page, it just means you must have the <head> tag there as well. A significant limitation to master page design, but troublesome not insurmountable.
[chroniclemaster1, 2008/12/26]
Skip to Main Points
Root Relative Path Variations
OK, I am somewhat less peeved now that I've spent a couple hours and found a workaround. Still it's not pretty. ASP.NET will process the URL if the runat="server" and the <link> tag are in the same master page file. However, since .NET isn't smart enough to process a link tag with a runat="server" attribute this means the <head> tag and the link have to be in the same master page. This creates some fundamental limitations. In order to craft robust master pages, I've required that all opening tags be accompanied by their closing tag in whatever page they appear in (ie page objects must be complete). This new work around means that while I can move non-active portions of the document header to a subordinate page (nested master or content page), wherever I put the <head> tags, not only must the closing <head> tag be present but all active server tags must be there. This creates serious questions about whether I can pull a separate css file into one content page, a technique I had assumed I'd be able to use for unique pages. I will have to burn that bridge when I come to it. There may be more elegant ways of designing master pages that I will learn between now and when I actually need to do that. One technique I read about and like, is using default content in a content placeholder for multiple pages and adding alternate content on select pages. This creates the outward appearance of two templates while using only one master. (or nested master)
I would also think it would be obvious that in the page life cycle you would prefer to pull in all the shared code from the various parts of your application into the page first and then process the complete code after. I hope that there are issues in the ASP.NET page life cycle which I don't appreciate yet which makes Microsoft's model much better than my simple plan. However, you would think that given this difficulty you'd build the fundamental components necessary to work around this problem. But the application root relative references are a critical .NET feature which master pages are completely dependent upon and they are so much less powerful than I would like.
Skip to Main Points
Master Page Links
I had assumed that I would need to use forward slash references for all my links. I think this is still a basically sound way to do it, however, it will compromise my ability to test that links work on the development server. I should at least experiment with the ASP.NET linking options to see if that's an acceptable way of constructing master pages. Not checking links until they're posted live would be a royal pain in the @ss.
HTML Server Controls
HTML Server Controls are HTML tags with runat="server" commands in them this makes them accessible to C# programming. (provided you include an ID attribute for C# to lock onto) We'll see if this also enables tilde technique paths in a link and an image tag. Try this html server Anchor control to get to master page 11. Here is an image html server control to reference the image source using a tilde technique root relative path.
Web Server Controls
Web Server Controls are ASP.NET components that can be processed, I believe, more efficiently by .NET than HTML server controls. Again, we'll see if this enables tilde technique paths. Try this web server Hyperlink control to get to master page 11. Here is an image web server control to reference an image using a tilde technique root relative path.
Skip to Main Points