Some of you may have noticed in the last month or so that the mojoPortal Mono Demo site (mono.mojoportal.com) was not performing well and was offline frequently and I'm afraid that was giving the wrong impression that either mono or the mono version of mojoPortal was unstable. But I assure you this was not the case. The problem was that I was hosting the site over a cable modem on a dev machine. Not exactly robust.

I think it was not the best way to make a good impression for people new to mono and not exactly fair either.

Before the 2.0 .NET framework came out, this site was hosted on Mono for about a year with excellent uptime, performance and stability at GrokThis.net and now thanks to their gracious sponsorship, the mono demo site is hosted there. GrokThis.net, hosts quite a few mojoPortal sites on mono and everyone I know has been very happy with their sites running there. I think having the mono demo site hosted there will make a much better impression.

It is only natural that it will take some time for the mono project to catch up on the 2.0 .NET implementation but progress is being made. It is only a matter of time and the 2.x version of mojoPortal will run on mono and we will be back to having one version of mojoPortal that runs on all platforms.

In the meantime I'm shooting for a release this weekend of 2.1 for Windows/.NET 2.0 which has some very exciting new features I'll blog about soon and a 1.0.2 maintenance release for linux/mono or 1.1 NET

If you've visited this site before you've probably noticed the new menu icons. Just added that over the weekend into branches/2.1. It was low hanging fruit. There was already a field in the mp_Pages table for MenuImage that had been there a long time but not implemented as a feature. So I added the UI elements to pick an icon and hooked it into the menu.

The only interesting bits about the implementation was that while the ASP.NET Menu items have an image property, the standard SiteMapNode does not so there was no where to store it when populating the node tree from within a custom SiteMapProvider. Not a difficult problem at all though, I just implemented a mojoSiteMapNode that inherits from SiteMapNode and add a property to store the image url. Then when I build the node tree I populate it with mojoSiteMapNode objects.
Since I'm already handling the MenuItemDataBound event to filter the menu based on roles I just had to add a little code ther to populate the image like this:

mojoSiteMapNode mapNode = (mojoSiteMapNode)e.Item.DataItem;
if (mapNode.MenuImage.Length > 0)
{
      e.Item.ImageUrl = mapNode.MenuImage;
}

Pretty sweet!

The other cool thing that landed in svn branches/2.1 this weekend was my further WebPart work including the WebPartModule and WebPartAdminModule features mentioned in my previous post, allowing use of 3rd party WebParts (if you can find some) both in the MyPage feature and anywhere in the content system. Also I have implemented the feature on MyPage to allow users to create as many "pages" of personailzed content as they like similar to pageflakes.com.

Now I still have some work to do in styling the User Page Menu on MyPage in the various skins (so far I've only been working in subblue). I'm not the greatest designer as I'm sure you have observed but hopefuly it will come out looking something like tabs.

With this, almost all of the compelling new 2.0 ASP.NET features are being used to good advantage in mojoPortal which means we are getting close to a time when I can try and focus on identifying what needs work in mono to get mojoportal 2.x working. There is still just one more big 2.0 feature I would like to take advantage of and that is the new improved localization features. I shied away from the conventional 1.1 .NET localization in the current mojoPortal localization implementation because I felt it had one fatal flaw. It required storing resource strings in satellite assemblies which meant a developer would need to be involved just to change a label. I felt very strongly that it should be possible to change any label with a text editor and not require any compilation. This and more is now possible and efficient in 2.0 .NET and would give us some ability to adapt labels in the site to the culture of the user's browser (if we have resources for his culture) with fallback to a default culture if not available. I still think the value added is very limited because the bulk of the content comes from the db and will never localize unless a person translates it but it is worth doing because there is some benefit if the login button and other buttons are localized as well as calendar and date time formats, it may help someone who knows some english for example but is not fluent.

I think I am leaning toward making the 2.1 release before tackling the localization changes. It will not be difficult but it will be a lot of grunt work copying strings from the culture files into the resource editor and going through the site to make the changes.

So I guess its a little more polish on the MyPage stuff, some QA and then make the 2.1 release

For those of you following along with the sources from svn, I pretty much work in branches/2.1 most of the time except when making changes that require db schema changes. To avoid breaking things for users who are working from svn I do the db change work in my sandbox branch and only merge it back into 2.1 once I have all the data layers implemented. This weekend I merged quite a bit, you may need to look for the newer stuff in the upgrade scripts if you are working with an existing db. There is still quite a bit of things to do before the release but I think the db changes are done for this coming release.

I implemented the WebPartModule and WebPartAdmin module in my sandbox over the weekend using the MS SQL data layer. I still have some work in the other data layers but I'm waiting until I complete all the schema changes In this db before moving through the other layers.

These modules work just as I planned using a test dll I made with a simple web part. I was able to drop it in the bin folder, it showed up on a list in the WebPart Admin module as a WebPart available to install. Installing was 2 clicks and 2 check boxes to indicate whether it should be made available for MyPage and the Content System. I checked them both and then was able to use the WebPart on MyPage and in the content system. Pretty Sweet!....but, if you build it wil they come?

Googling I could not find any webpart libraries available for download except those for Sharepoint which are not compatible with ASP.NET WebParts. Often, people don't realize these are not the same thing because they are both named WebParts, but they are not the same thing.

So the utility of this feature is good for developing your own WebParts as features for mojoPortal or other projects using WebParts but we have yet to see much of anything out there right now as far as 3rd party WebParts. Maybe that will emerge later, we shall see.

But anyway, there is still more that I want to do in the MyPage implementation of WebParts.

Similar to what they have over at www.pageflakes.com, I want the user to be able to have multiple pages on MyPage, with the ability to create more as needed.

Also, I want to do something more elaborate with the WebPart Catalog. You can only show so many choices in the default presentation without it getting obnoxious so I need to figure out how to implement it so that the most popular ones show up in a short list and there is a more link where you can open a screen that lets you page through them so that it is not too cumbersome having a large catalog and browsing through them.

I think after those 2 things are implemented I will start the QA process towards a release. Not sure how long that will take, hopefully it will go quickly.

Now that I've had a chance to think more about WebParts and play with the first iteration of WebParts in mojoPortal as implemented in the MyPage feature I'm starting to get a vision for the next steps and here is what I've come up with and will be working on this weekend. Basically, I'm envisioning 2 new modules WebPartModule and WebPartAdminModule.

WebPartModule will allow us to use any installed WebPart as content anywhere in the site. When I say installed I'm talking about assemblies dropped in the bin folder, in other words third party WebParts or WebParts developed as pure WebParts outside of mojoportal and compiled into a class library like MyCustomWebParts.dll and placed in the bin folder beneath the web. Of course WebParts used this way won't have the drag and drop and personalization but will be just like any other content in the site (not including MyPage) and will stay where the Admin puts it. So this module will just be a way to make any WebPart available for the Content System. When installed WebParts are used on MyPage they will have all the WebPart features but the WebPartModule is not part of that equation, its job is just to load a WebPart as if it were any other site content wherever you tell it to. In this context the WebPart will be treated like an ordinary Control.

WebPartAdminModule will allow the admin to "install" the WebParts by entering the Assembly Name, the Class Name, and Description to display in the WebPart Catalog on MyPage. It will also allow configuring whether each installed WebPart is available for MyPage and/or available for the Content System using the above WebPartModule. To make it friendly I may use Reflection to iterate through the assemblies in the bin folder and make a list of WebParts in those assemblies that aren't yet installed. I've already done preliminary work on loading WebParts dynamically from assemblies. The WebPartAdmin module will just give them permission to be used on a site by site basis. In a multi site installation the root site will be able to determine which WebParts are installed in each subordinate site just as we currently do with the Installed Feature Administration in Site Settings. This feature will show the currently installed WebParts and the WebParts found in the bin assemblies that are not installed to make it easy to install them.

So these features will allow us to use third party WebParts on MyPage where they will have all the WebPart bells and whistles or anywhere else in the site where they will be treated like ordinary controls.

I think this will work, should be fun.