Now - after support for ASP.NET 2.0 with MCMS 2002 Service Pack 2 - has officially been announced lets have a short look on the new features coming with ASP.NET 2.0 and how they might give benefits to a MCMS site.
One of the key selling points for ASP.NET 2.0 is the new Master page concept. For ASP.NET this feature is much more important than for MCMS as with a ASP.NET based web site there can be thousands of ASPX pages. If you need to enforce a common look and feel then this can be a huge maintenance effort.
MCMS provides a huge relief for this problem as the MCMS templates provide a similar solution: one ASP.NET web form that can be used as “master” for thousands of postings. To change the look and feel you only need to change this single template file.
ASP.NET 2.0 supports master pages in a cascaded way: you can have content pages that utilize a master page which then also utilizes a master page.
In addition it is possible to host multiple content areas on a master page which allows a very flexible page design where the master page controls various parts of the page and has several sections that can be filled from content pages.
This is looks very similar to the placeholder control support of MCMS.
From what I have heard from a DevelopMentor Trainer in an ASP.NET 2.0 course, during compile time the content page and all master pages are compiled together as if everything would have been defined as a single web form.
Even for MCMS the master page concept can provide benefits as there are usually still 10 or more template files in a MCMS template project – and even the work to maintain the look and feel for these templates is something you might want to avoid.
It has been announced that MCMS will support ASP.NET 2.0 master pages. From my understanding this means as well for authoring and for presentation mode – which makes sense. The announcement limits this to placeholder support in the content page and not in the master page – not sure if this is only a limitation caused through the implementation of the web author dialogs… If content and master page are really compiled together to a single web form there should not be a problem in hosting a placeholder control on the master page. Maybe this is just something that has not been tested? That’s definitely something I will have to try as soon as I get hands on the first SP2 bits!
Themes are very nice idea now available in ASP.NET 2.0! With a single assignment of Variable or with a single setting in the web.config you are now able to completely redesign your web site! This is done by dynamically changing the path to the directory that hosts the styles for web forms (css files) and for user controls (skins).
There is only one caveat – but this hurts all MCMS users: when using themes ASP.NET 2.0 takes complete control over the insertion of the stylesheets into the web form. ASP.NET does this by dynamically generating the URL to the stylesheet in the current Theme directory. The problem with this is that ASP.NET generates this URL as a relative URL – relative to the web form. With MCMS this will not always work as the browser will request this file relative to the current web request. As the URL of this web request will point to the channel and not to the ASP.NET template this relative path would point to a wrong location. MCMS has a solution for this by rendering a <base> tag to the template through the RobotMetaTag Control. The base tag tells the browser which path to use as base for the relative path. The problem with this: in a hosting environment there is usually a publishing proxy server or firewall in front of the MCMS server and the server name in the URL points to the proxy or firewall server and not to the MCMS server. When forwarding the request to the MCMS server the proxy or firewall then replaces the server name with the internal server name of the MCMS server. As the base tag – per definition – needs to be a complete URL including the server name the generated base tag will then contain the internal server name and not the external server name the browser should use. So this will not work.
Intelligent proxy servers like Microsoft ISA server can take care of this and replace all references to the internal server name in the html content with the external name but lots of other proxy servers are not able to do this.
So in this situation the base tag needs to be disabled – which then breaks the relative path of the Themes.
So the Theme concept is something that will only work in some situations but not in bigger setups with publishing rules through proxy servers that are not able to do content rewrite.
A solution for this could be a custom http module that replaces the relative path with an absolute path starting at the web site root. But as such a http module would have to replace this string in all pages this could result in a measurable performance impact.
A better solution would have been if the URL to the stylesheet file would have been generated as absolute path by ASP.NET 2.0 itself – lets hope that this behaviour changes or is at least configurable till the final version of ASP.NET 2.0.
Btw: this is not a problem for the different skins for user controls which are also hosted inside the themes directory as these settings are directly compiled into the user control and are not referenced as external file.
Providers are another nice new concept in ASP.NET. Actually a provider is a DLL that can add functionality to your site using a specified interface. The difference to normal classes is that you are able to define which provider to use using the web.config.
This allows replacing the provider with a different one without recompile. In addition you are able to add multiple providers providing a similar functionality and selecting the provider to use during runtime using configuration files.
For example you could use an authentication provider that is able to handle forms authentication and another provider that can handle windows authentication or passport authentication.
Even if someone invents a new authentication concept you can add the functionality to authenticate against this authentication source without recompile of your solution by only creating the provider and adding this provider to your web solution by modifying the web.config.
The good thing with the provider model is that you are not bound to the provider types shipped with ASP.NET (e.g. authentication provider or site map provider) but that your are able to develop your own custom providers which work based on the requirements of your web site. E.g. if your site is an E-Shop that requires a method to validate credit cards then you could implement this verification using the provider model. As each credit card company has a different method to verify if a given card is valid you would add a provider for each credit card type.
If later a new credit card type needs to be added, just add another provider for this credit card type to the web.config and voila you are done!
An interesting build in provider type coming with ASP.NET is the SiteMapProvider. This provider works with the navigation controls shipped with ASP.NET but you are also able to utilize the Site Map Provider from your custom navigation controls or page summary controls (e.g. on a channel rendering script).
New Server Controls
A major topic for every MCMS website is the implementation of dynamic navigation controls. ASP.NET 2.0 makes it very easy to add nice looking navigation controls with just a couple of mouse clicks to a web form. For navigation the following controls are included: Site Map Control, Menu Control and Tree View Control. All these controls can be fully customized using CSS style sheets or skin files. In addition these controls are able to utilize a Site Map Provider as the data source.
So the only way to get the ASP.NET 2.0 build in controls working with MCMS is to implement a Site Map Provider that uses the MCMS repository as data source.
For a huge web site where many nodes need to be populated to the menu control it is also possible to load the information about the different nodes in the control dynamically when required. This can be a benefit when performance comes into play.
ASP.NET 2.0 now also includes a Web Part model. Unfortunately the web part model of ASP.NET is not compatible with the Web Part model of SharePoint – means you are not able to utilize the web parts of ASP.NET in SharePoint or vice versa.
Based on the information provided by Arpan there are currently no plans to support Web Parts will with MCMS. Not sure what this means in detail as a template is nothing but a normal ASP.NET web form with some special controls included.
I assume that web parts can still be on the template but that there might be a limitation about adding placeholder controls to a web part. And even here I assume that the limitation only affects authoring and not presentation mode.
So if the placeholder control is rendered outside a web part during authoring time and inside a web part during presentation mode I would not expect any problem. So that’s another thing I will have to test as soon as I get the first SP2 bits.