Well the site skinning is essentially complete. From the Admin page you can select from available skins. This is the IBuySpy skin. I plan to make some new skins soon but it tickles me that I was able to make all the changes I made without losing the original look. I really can't think of any limits on the design possibilities with the new skinning. The skmMenu fits right in nicely and has its own skinning that integrates easily. I also created a MetaContent control and setup the abilility to specify default meta content at the site level and over-ride it at the page level if desired. Now its easy to move the menu around and change it from horizontal to vertical within the skin template. I still need to implement the page hierarchy for sub menu items. I also got about 80% of the culture localization support completed. The goal is for no hard coded labels in the site. All labels get their content from a Culture.config file. I'm providing a CultureUSA.config file and hoping that as others convert to their own cultures they will contribute additional Culture.config files that I can provide with the downloads.

I'm making more progress on the site skinning. Today I integrated Scott Mitchell's skmMenu, an open source cross-browser Dynamic HTML menu for ASP.NET. It took me quite a bit of experimentation before I could get it to display the same as IE using Mozilla and Firefox when it was served from Mono. It looked pretty much the same right away in all browsers if served from IIS. I think it is a behavioural difference in mono's implementation of ASP.NET. The same code was rendering a rules="" attribute on the menu table on Mono but not under IIS on Windows. This was eliminating the border between menus when viewed in Mozilla or Firefox but not IE, when served from Mono. This was kind of mysterious because I could not find anywhere in the skmMenu code where it adds a "rules" attribute. I also experimented and Mono doesn't automatically add a "rules" attribute when you add an HtmlTable to the control tree. I never did figure out the cause, but I finally discovered that I could control it by explicitly setting the GridLines property of the menu.

I finally got all the pages in the site using Paul Wilson's MasterPages implementation. I've also changed my mind about needing to skin the site header separately. It will be better to break the site header control up into its constituent components and make them into their own controls and then position them within the MasterPage template. This will allow a great deal of flexibility in terms of design and make the design work very easy to understand for anyone who understands HTML. The templates are just .ascx files with markup. I plan to display them in a dropdown on the admin page. You would simply create a new one and drop it into a folder to add a skin. Of course you would have to include any supporting images and style sheets.

IBuySpy, was not implemented in an OOP style. It uses mostly static methods in its "components" which are really just data access code and are embedded right in the web project. In mojoPortal I have already separated the layers cleanly allowing for interchangeable data layers. I wrote the Blog Module in an OOP style and plan to re-write the other modules in the same fashion. In particular the ModuleSettings and ModuleItems really reperesent the same thing and have overlapping properties that map to the same row in the Modules table. Same thing with the TabSettings and TabItem they will be combined into one class. I also plan to re-name Tab to Page and Portal to Site as I believe they are more intuitive conceptual abstractions. I've never liked the DesktopDefault.aspx page and plan to make that just Default.aspx. I'm not really focused on supporting mobile devices at this point but if I do I'm pondering a separate web site implementation since I think of the whole web site as a presentation layer. I could easily create a thinner presentation layer using the same business objects and I make no assumption at this point that it would be easier to design one site to handle all devices. Then again, maybe that will just be part of a skinning aproach, who knows.

As I recall, the IBuySpy Portal reference architecture was released while Visual Studio.NET was in beta and was the first good sample code to help Classic ASP developers make the leap to this new .NET thing. It was later updated for the release and has been used as a starting point in countless private projects and at least 2 notable open source projects, RainbowPortal and DotNetNuke

A lot has happened since then. The .NET Community has blossomed into a wealth of sites with articles, code samples, forums, blogs, and open source projects. Now we have the approaching release of ASP.NET 2.0 and the first release of The Mono Project, a port of the .NET framework that runs on Unix, Linux, and Mac OS X. These are exciting times! The vision of cross platform applications is within reach!

But its not a slam dunk. Chances are the ASP.NET code you've already written will need some massaging to make it work in the case sensitive file and url world of GNU/Linux/Apache. You will also have to add some new skills to your repetoire to learn web server administration in the apache world. My plan with this project is to use what I've learned over the past several years of ASP.NET development and create an improved reference architecture that teaches Object Oriented implementation by example while at the same time fleshing out a truly cross platform, feature rich web site framework that can be used by others as a starting point for their projects as well as my own. When I complete my vision, there won't be much resemblence to the original IBuySpy architecture, but even today it makes a good starting point in terms of functionality.