JoeAudette.com

I signed up for a locker at mp3Tunes this weekend and so far I am very impressed.

My iPod had freaked out last week. It lost track of all its music and then the Mac didn't even recognize it as an iPod. I was able to get it going again using the Updater Utility but I had to restore it to original to fix it so it lost all of its music and could only get it back by re-syncing which took a long time for my nearly 40 gig music library.

So having my large music library backed up out in the cloud and available to me on any internet connected device for about $40 a year seems like a great deal to me. It looks like it will take about 10 days to get it all uploaded. Wonder if that will raise any red flags with my isp, we'll see...

But I can't wait to get it all uploaded. It will be nice no matter where I am or which machine or operating system I'm on to have my music available.

I hope its going to be around a while, its another Michael Robertson (of mp3.com back in the bubble, and more recently Linspire fame) site.

You might think they would use file signatures to not duplicate a million copies of thriller but it seems in fact that they upload every file and it is my private locker with nothing shared accross users. At least thats my impression.

I've been working hard on getting mojoPortal to XHTML compliance and I'm happy to report that now almost every page is valid XHTML 1.0 Transitional according to the W3C Validator. Some pages would even validate as XHTML 1.1 but since the FCKeditor only supports 1.0 I decided to use the 1.0 doctype. In .NET 1.1 is was not possible or at least very difficult to get XHTML compliance because the server controls in 1.1 were not intended to emit XHTML but now 2.0 .NET makes it all possible. I had to fix one minor bug in the .NET wrapper for FCKeditor to get it to validate correctly.

One thing about ASP.NET is that the server controls are built to downgrade gracefully on legacy browsers so if it can't detect the browser it will not render as XHTML which made it not validate just by pointing the validator at my site. Then thanks to google I found Barry Dorran's blog post where he created a w3cvalidator browser definition file for 2.0 .NET. You just drop it in your App_Browsers folder and recompile, then you can point the w3c validator at your site and it will render as it would for a high level browser, or in other words XHTML.

Until I got the browser definition in place I had to view the page in a browser like Firefox and then right click to get the source, save to disk and upload it to the validator but now with the link it is easy to find the pages that still need some work.

So I thought it might be interesting to survey the sites of some competing ASP.NET portal and framework projects and here is what I found:

Community Server uses XHTML 1.0 Frameset for the DOCTYPE and the validator reports 76 errors

DotNetNuke uses HTML 4.0 Transitional for the DOCTYPE and the validator says 148 errors

Rainbow Portal uses HTML 4.0 for the DOCTYPE and the validator reports 84 errors

interestingly even the ASP.NET site doesn't validate, it uses XHTML 1.0 Strict for the DOCTYPE and the validator finds 168 errors

I used Firefox to get the page source in testing each of these.

To be fair I have to say that the current releases of mojoPortal probably don't fare well at the validator either but the next release of the 2.x branch will be compliant. This site and mojoportal.com are running on the latest mojo code from svn and they are both validating nicely on most pages and thats something even the big boys can't say right now

I recently got Andrew Troelsen's new book Pro C# 2005 and the .NET 2.0 Platform, Third Edition and I can't say enough how good this book is. I knew he was a good writer from his first version of the book which is what I used to learn C# a few years ago. I will say this is a serious developer book with comprehensive coverage of C#. The explanations are well thought out and written in a very clear style.


There are a lot of improvements in C# 2.0, one of the most interesting and most useful is generics. Amoung other things, generics bring elegence and economy to custom strongly typed collections. Even better, since this is one of the most important chapters in the book, Apress has made the generics chapter available for free as a pdf on their web site under book extras along with all the source code examples from the book. Read this chapter and I think you will want the rest of the book. Its an enjoyable read and a great reference.

Noted ASP.NET guru Scott Hanselman has recently started podcasting at his new site http://hanselminutes.com/
and his most recent podcast is titled The State of The Mono Project
Its a good show but a slow download.
Enjoy

In my previous post I showed the code for a custom SiteMapProvider I'm building for mojoPortal. Later I ran into another issue.

I wanted to be able to link to an external site from my menu but it was raising an error in the AddNode method:

[HttpException (0x80004005): 'http://www.google.com' is not a valid virtual path.]
   System.Web.Util.UrlPath.CheckValidVirtualPath(String path) +745179
   System.Web.Util.UrlPath.Combine(String appPath, String basepath, String relative) +155
   System.Web.StaticSiteMapProvider.AddNode(SiteMapNode node, SiteMapNode parentNode) +302
   ...

I tried just taking off the http:// but that didn't work either. When you add the node it wants a virtual path that exists in the site.

The solution required a few things
I had to  turn off securityTrimming in the Web.config

<siteMap enabled="true" defaultProvider="mojoSiteMapProvider">
    <providers>
        <add name="mojoSiteMapProvider"
          type="mojoPortal.Web.mojoSiteMapProvider"
          securityTrimmingEnabled="false"
           />
    </providers>
</siteMap>
    
Having this enabled would automatically show or hide menu items based on your security roles, turning it off means the SiteMapProvider will server up all nodes to all users regardless of their role membership so you have to filter the menu yourself. This is not a real problem because you can hide things in the MenuItemDataBound event of the Menu Control by doing your own role checking. My method for this looks like this:
void pageMenu_MenuItemDataBound(object sender, MenuEventArgs e)
{
    System.Web.UI.WebControls.Menu menu = (System.Web.UI.WebControls.Menu)sender;
    SiteMapNode mapNode = (SiteMapNode)e.Item.DataItem;

    if (SiteUser.IsInRoles(mapNode.Roles))
    {
    System.Web.UI.WebControls.MenuItem itemToRemove = menu.FindItem(mapNode.Title);

    if (itemToRemove != null)
    {
        menu.Items.Remove(menu.FindItem(mapNode.Title));
    }

    }

}

Now the other thing you need to do to avoid this error, is to set the Url for the node to an internal link before you add it to the nodes collection, then set it back to the external link after it is already in the collection. Apparently when you add it to the nodes collection, the base class is making sure it points to a real virtual path in the site, but after it makes this check you are free to change it.

My code for this looks like this:
SiteMapNode node = CreateSiteMapNode(page, i);
AddNode(node, GetParentNode(page));
if ((page.UseUrl) && (page.Url.StartsWith("http")))
{
    node.Url = page.Url;
}

CreateSiteMapNode has logic to set it to an internal link if it sees that the url starts with http. Internal links have a relative path.
So after the node is in the nodes collection you can get away with changing the Url to an external link.

Hope this helps anyone having the same problem.

Wow! I hope this is true. Mike Gundelroy blogged about this.

http://www.larkware.com/editorials/vmware.html