One of the  great things in 2.0 .NET is that it supports XHTML compliance. For those who don't know XHTML is a newer w3c standard meant to replace HTML and, in a nutshell, is just a stricter version of HTML.

XHTML compliance is really just the first step towards compliance with the w3c Web Content Accessibility Guidelines (WCAG) and the US Government Section 508 guidelines. The big picture goal is to make the web site content accessible to the widest audience of people including those with handicaps that make web browsing difficult by supporting the widest variety of browsers and devices including everything from screen readers to electronic braille pads. The new standards and guidelines are desinged to do just that and I definitely want mojoPortal to comply with these guidelines wherever possible.

The biggest things to be aware of when trying to convert HTML to XHTML are that everything is lower case and eveything must comply with standard xml rules. Some of the HTML tags that did not require formal closing tags now do require them. <BR> for example must be <br /> so that it has and end tag.

The change in 2.0 ASP.NET is that the server controls like TextBox, Calendar, DataGrid, etc render XHTML compliant markup. You still have to make your own markup that wraps these controls compliant.

In mojoPortal I have had the forsight in most places to use <br /> and other XHTML compliant forms even before 2.0 .NET just to be prepared but there are some places where I had non-compliant markup. I am going through all the pages and controls now in the 2.1 branch and fixing these things, its really not that big a job. What is a big job is changing from html table driven layout to using div and span elements with css. This is fairly tedious work for me to go through the whole project and do this and these changes will likely require some effort to convert existing custom skins for those upgrading when I make the next release. if it seems like a lot of work to you just remember I did it for the included skins . When I'm done you should be able to tell what you need to do to upgrade your custom skin by looking at the included layout.Master files and style.css files

At first I thought I would wait and convert to web parts before making this change but I decided to do this first so that I will have cleaner markup when I get to that step. Best to get the skinning and layout really nailed down first. This will be a solid foundation for meeting our compliance goals.

I committed some stuff to svn today that will make it easier going forward to have consistent data initialisation accross the different supported dbs. It will no longer be needed to run the script to create initial site data during installation, only the table creation script and depending on the db maybe a stored procedure script will need to be run.

maintaining the different data creation scripts for each db as new features are added will no longer be needed

I encapsulated the data creation logic up in the business layer in a new class, mojoSetup.cs.

When the application starts it will check the count of rows in the mp_Sites table and if there are 0, it will create the initial site data by calling mojoSetup.CreateInitialData.

If you use the multiple sites on one installation feature of mojoPortal, it will call mojoSetup.CreateNewSiteData whenever you create a new site to populate the new site with the standard pages.

The content for the initial data and new site data comes from new files I added in the /Data/MessageTemplates folder

For example the intial home page content comes from en-US-InitialSiteHomeContent.config

You can localize these by creating your own files with a prefix matching the culture setting you have in the Web.config Culture key and dropping your files in the same folder.

For example a German translation of the same file would be named:
de-DE-InitialSiteHomeContent.config

If it can't find the file for the culture you have set in your Web.config file, it will fall back to using the english file.

As always any contributions of translated files is welcome and many thanks to all those who have contributed the culture files and translations already.

Those of you playing with mojoPortal from the Subversion repository using TortoiseSVN, if you are using VS 2005 I recommend you get:

svn+ssh://anonymous@forgesvn1.novell.com/svn/mojoportal/branches/2.1
rather than /branches/2.0
2.0 was the intial build against the 2.0 .NET runtime but it did not use any of the new 2.0 features.

All the fun stuff is happening in the 2.1 branch.

So far I've

• Converted from Paul Wilson's MasterPages to the new intrinsic ASP.NET MasterPages. This was very easy thanks to Paul's version being very similar to the shipping 2.0 version from MS
• Came up with a way to store the theme.skin file for the new Theme feature in ASP.NET in the site specific skin folder along with the other elements like layout.Master, style.css, and supporting images. This keeps everything together and keeps things private between sites when running multiple sites from one mojoPortal installation. Themes allow you to set all the visual properties for the built in server controls. Now its a tedious task of moving markup off the controls in the pages and modules into the theme.skin file but it will be well worth it to gain complete control of control presentation from the skin. I predict more interesting looking skins after this!
• Implemented a SiteMapProvider, mojoSiteMapProvider on top of the mojoPortal SiteSettings object. This is used to bind to the new Menu or TreeView controls and also the new SiteMapPath control which provides Breadcrumbs and will probably replace our current breadcrumbs control soon.
• I setup the new Menu control and styled it in the theme.skin fairly close to how the older skmMenu is styled in the current skins. I also moved the style for the blog calendar and events calendar into the theme.skin file. I plan to make the menu have 3 options you can set in to enable either the new Menu, the new TreeView, or the skmMenu for the menu. I still need to style the treeview at least a little

I will be working on implementing the membship api and trying out conversion to WebParts in the near future after I get some more of the theme grunt work done.

Note: the 2.x branch of mojoportal is Windows only at this point, it will not run on mono until the mono 2.0 implementation catches up. It will probably be a while before this happens so mono users should stick with the 1.x branch aka trunk

I got mojoPortal loading its content using MasterPages on Mono tonight at http://dev.mojoportal.com
On Windows it was working with AutoEventWireup=true but it was not firing the events on mono so tonight I set it to false on Windows and hooked up the events manually and it worked both on Windows and when I deployed it on mono.

Sweet! I'll merge this into the 2.0 bnranch after I get the rest of the pages and skins converted.

So the current 2.0 runtime status of mojoPortal on mono (r54948 compiled 1/1/2006) is illustrated as follows:

http://demo.mojoportal.com = 1.1 framework version

http://demo2.mojoportal.com =  2.0 framework version not using any 2.0 features  with 1 outstanding mono bug

http://dev.mojoportal.com = 2.0 framework with main pages using MasterPages

progress...

Update 1/5/2006: After another evening of struggle trying to find a way to get other pages than the main Default.aspx page to load their content I have to say something is either broken or not implemented yet in mono that is preventing the other pages from loading their content inside the ContentPlaceHolder controls within the master pages. The Default.aspx page is the main CMS page and loads its controls all dynamically based on database settings but other supporting pages have controls nested within the markup of the place holders like this:

<asp:content runat="server" id="MPContent"contentplaceholderid="mainContent">  

<asp:panel runat="server" id="pnlLogin">  

Hello World

 </asp:panel>  </asp:content>  

on windows it works but on mono you don't see the controls nested within the Content regions and if you try to access them in code you get NullReferenceExceptions

Currently on http://dev.mojoportal.com the Register page is throwing the NullReferenceException and the login page is not showing the login controls due to this. I'm going to try and produce a small test case this weekend.

Update 1/10/2006: I was able to make a little test case this past weekend with this issue on mono. The null reference exception is occuring when trying to hookup button click events and such. If you set the MasterPage for the page programmatically in OnPreInit it somehow loses its reference to controls nested within the ContentRegions on the page.

I made some progress tonight converting from Paul Wilson's MasterPages to the built in ASP.NET 2.0 MasterPages. I got the Default.aspx page converted and working on Windows, it was pretty straightforward given that Paul modelled his version from early specs for the real thing. Now it will just be a machanical repetitious task to update the remaining pages and skins, but not tonight, I'm spent.  I tested on mono at demo2.mojoportal.com, it did load the MasterPage but something went wrong loading the rest of the page content as you can see. I'll follow up with that and see if I can pin down the problem.

I've been getting very excited learning about the Web Part framework. I know I said I would pace my changes with mono support but I think what I will do is keep a separate branch in step with mono support until the mono support catches up so I can move forward taking advantage of 2.0 ASP.NET features. Some of them are just too compelling to wait and besides it will take some time to make the changes and figure out exactly how I want to do it. Right now I'm thinking the Web Part model will replace the existing implementation for Feature Modules.

I definitely will try and help implement some of the missing mono features if I can, or at least provide testing and feedback for the guys who are doing it.