Homepage

Converting the whole theming system of Rainbow Portal is hard but work is going on. Current stage is very very encouraging. To summarize, after being able to create the new URL rewriting module and making UpdatePanels work inside Diavolo codebase, I had to convert the layout system. It's not over yet, however start was rewriting the PortalSettings class and its logic.

Result is I was able to create the new PortalConfiguration class, which embeds all PortalSettings functionalities plus some more. I can say that Diavolo now supports Master Pages so you can select a default one which will be applied to all pages of portal. Diavolo now also supports ASP.NET themes so selected theme will be applied to portal as well. That includes CSS stylesheets. I was able to simply move CSS files from Rainbow "Themes" folder to new ASP.NET theme folder.

Master pages embeds part of functionalities which were part of Page.cs class. This is a good design decision so you can simply draw your master page and then inherit from GenericMasterPageBase: that will automagically give your master page a base of code which will perform basic page tasks. If needed, designers could inherit from base class but add custom functionalities. That makes Diavolo very flexible. I estimate that almost 50% of Page.cs code has been converted to new design system.

PortalConfiguration class introduces new features like:

* a new flexible way to set DOCTYPE. Administrators will be able to choose DOCTYPE based on a list of presents which will include most used items. Diavolo also supports least used DOCTYPES like XHTML 1.1 and HTML 5. Designers will also be able to add custom DOCTYPEs to their master pages and that will override portal-wide setting. This means each page can have a different DOCTYPE if needed. Most likely, a few pages in a portal might require different setting, for example to support specific designs: this is now possible;  

* custom JavaScripts. Those scripts can be defined at portal level and will be added to each page. That makes it possible to support those tricky JavaScript libraries without hacking into Diavolo code;

* a script-manager (part of MS AJAX library) can be added to each page. This is key element to provide portal-wide compatibility with MS AJAX extensions which are now part of .NET3.5 framework. This however remains optional because it can be disabled via PortalConfiguration setting. While most modules we will develop will user AJAX, some portals might not want to add it to each page, using non-AJAX modules to replace Diavolo ones, and completely disable MS AJAX. This is now user-selectable; 

A new Portal Settings Administration module (which uses MS AJAX) has been developed anche some changes have been applied to Rainbow code to use this new class instead of old PortalSettings. New module has worked as a proof that MS AJAX is working without any problem and to administer new settings.

Now the hardest part of the whole conversion task is approaching. While Diavolo now uses master pages as a design template, it internally still uses DesktopThreePanes control to perform the whole page rendering operation. My first task is now to standardize an alternative to DesktopThreePanes to contain modules.

Additionally, ASP.NET themes will be selected and will apply both stylesheets and control skins and this is a very good starting point because that means you can:

* create a portal layout by designing a master page rather than Rainbow custom themes;
* assign stylesheets to pages;
* create skins for controls inside a .skin file.

So admins have now basically many more ways to create their styles and designs and incidentally this also made pages quicker to render as Rainbow was building page markup in a very basic way. Now most page rendering is delegated to ASP.NET infrastructure and that will positively affect performance.

However, as said, the hard part is now to convert the DesktopThreePanes control and delegate its functionalities to master pages. Then I will have to convert the module rendering code to a new system where containers will be used in place of XML templates. That will get rid of the whole Rainbow rendering code, including Zen library. Backward compatibility will not be assured there, meaning that designers will probably have to create new containers (that is, ASCX controls) to replace their themes.

I spent most of last few days trying to finalize changes to Diavolo theming system. My goal is to convert Diavolo to use master pages, ASP.NET themes and, after that, complete a full rewrite of theming system, changing the way themes are created and rendered and then removing old theming engines, including Zen.

Of course, another minor goal is to be able to support ASP.NET AJAX, UpdatePanels and AJAXControlToolkit since those weren't working with old Rainbow. I had very busy days trying to glue all those things into working code. I'm very surprised that UpdatePanels and AJAX as a whole have so many problems to take care of.

First problem was to rewrite URLRewriting HTTPModule (as per my previous post). After doing that, I happened to change the way layouts and themes are rendered, replacing older code with new one and thus enabling Diavolo to use master pages to setup page designs (layouts) and ASP.NET themes. This wasn't too difficult since I expect most problems will arise later, then trying to rewrite the whole Page.cs class and the way modules gets rendered. However, got a major problem when I happened to understand that UpdatePanels weren't working anyway.

After days of googling and checking possible solutions, I found out that UpdatePanels weren't working because of URLRewriting module. Had to modify base classes to be able to set "action" attribute of <form> tag to original (non-rewritten, thus virtual) URL. Then, I happened to stumble upon a problem with RP design, which Server.Transfers execution from default.aspx to relevant *default.aspx (either desktop or mobile). That's a problem because rewriting to default.aspx caused errors (failed validation of ViewState MAC). That meant UpdatePanels appearing at non-rewritten paths were working but others weren't.

It took me two days to be able to understand that problem was caused by Server.Transfer. Then I thought to try to rewrite to desktopdefault.aspx instead of default.aspx, which was appropriate because that's the page which is being executed. However, I didn't want to break support for mobile-specific pages, even if I'm not using that at all. Luckily, it took just a line of code to check if browser is a mobile one or not and rewrite to relevant page.

I'm happy to be able to say that UpdatePanels are fully working now, on any page! That's a major achievement for Diavolo which is now able to supporto ASP.NET AJAX with all its advantages.

However, theming system is not complete yet. I'm working on rewriting the whole PortalSettings class and modules to manage portal settings in order to support master pages and themes and that will take a few more days.

I'm pretty amazed how simple modifying the whole theming system is turning to be, when compared to what I was expecting. I was sure I was embarking into a very difficult task but the way themes are implemented in Rainbow looked so natural that the switch to ASP.NET themes is not going to be a daunting task.

First of all, Rainbow Portal has a DesktopLayouts system which will replicate functionalities of ASP.NET master pages. That meant that by simply creating a master page and applying it to desktopdefault.aspx page (with a little bit of tweaking) we have just replicated the basic of templating in Rainbow Portal. Amazingly, that worked fairly well.

I'm also amazed how themes support was easy to implement at page level. By simply creating a theme and moving CSS files from legacy Rainbow themes to that new ASP.NET theme, we were able to enable support. Of course, there's much more to do because we should get rid of DesktopThreePanes control and switch to master pages support only. I already extended Page.cs class in order to add basic theming and master pages support.

My goal is to use master pages to get rid of DesktopThreePanes. Then I will change the way modules are rendered by introducing containers (both HTML or ASCX ones) and remove support for both legacy themes (and its XML files... not very handy) and Zen rendering engine. That will make the whole theming system a lot easier to manage and hopefully faster. But I'm fairly confident that this task won't be so long to complete, also given the good result I achieved in a few days of experimentation.

Going forward in checking new Diavolo release. I was able to successfully move upgraded database to our production servers and then tried to connect Diavolo to that portal. Result was very good as portal has been upgraded and successfully ran. I attempted to login a couple of users and everything went smoothly then made some changes to contents and again everything was fine.

Before moving our corporate website to Diavolo I will probably attempt to upgrade this website, as I did when converting .NET 1.x  solution to .NET 2.0.

But the hours spent on converting and debugging this solution seem to be worthy since everything looked fine and for sure our corporate website is our biggest Rainbow Portal installation so far. It's definitely great that we will be able to upgrade our code while still mantaining compatibility with old legacy code. Whew! 

I'm happy to announce that Diavolo reached two major milestones:

• first one is the new official logo you can see later on this post;
• second, we finally reached major milestone of a completed upgrade path from Rainbow Portal v2.0.0.1881 to the newest v3.0.0.1883 !

This represent a major step for Diavolo as r1882 and r1883 introduce many changes which are the foundation of future upgrade. Starting from r1883, RP portals can be upgraded to Diavolo and tested in a live environment.

Major changes for r1882 were a complete rewrite of users management system in order to make it compatible with ASP.NET 2+ Membership sub-system. Newest r1883 introduce a brand-new update system whose features are detailed in a new PDF document which has been published on this website and will be published soon on a dedicated website.

This new sub-system can be very powerful and has proved flexible enough to perform a clean upgrade from Rainbow Portal r1881 to Diavolo r1883, thus jumping r1882 which haven't been released and won't be. I'm very happy about this result because it will make upgrading and updating a Diavolo portal much easier for administrators while still mantain an high degree of flexibility. For example, while r1883 was already completed, to perform an upgrade from RP r1881 to Diavolo r1883, we had to setup special version of custom components which will then be replaced during upgrading process.

While this was not a daunting task, it was possible to automate this whole process without the need to manually upgrade code, DLLs or other components. So this new sub-system works and it's very powerful. So look for these new documents on this website.

I will try to open a new Codeplex project for Diavolo very soon. In meantime, comments and feedback are welcome for our new logo (courtesy of Altereco):

Can't believe ! I spent last 2 days trying to debug why FCKEditor v2 wasn't working with Diavolo (and in the meantime I fixed a couple of little bugs). I was really going to stop and maybe remove FCKEditor v2 support from Diavolo when it turned out that the problem was only occurring in VS 2008 integrated Web server ! Gosh!

Can't believe I spent days trying to fix that. Now, don't ask me why it happened (as it was happening for IE only and it was working in Chrome and Firefox)... so I was going to assume it was a IE 7 problem. And then... the miracle!

Now we're really close to first Diavolo release. I can confirm Diavolo can successfully upgrade a Rainbow Portal v1.6 intallation... so I just have to decide if I'm willing to release this version with .NET 2.0 Membership system or I can wait until I introduce more original features...

I'm not very sure I will release first version of Diavolo, yet. I'm very happy to say that my tests during weekend showed that Diavolo can successfully upgrade a Rainbow Portal v1.6 installation without any problem and this can be considered a milestone itself. While functional, I still have a few problems, just little bugs, to fix.

First of all, my Role provider has a little bug when you run it just after upgrading a portal. This only happens after upgrading, I mean the very first run after you press the Finish button. Other calls will work as expected but this bug, though minimal, should be fixed. I know where it is and what causes it so it shouldn't take too much to fix it.

Next little bug is about FCKEditor v2. It took me a few hours to understand that editor was causing a bug. I think this is because of changes in framework, I guess but couldn't investigate further. As a generale rule, RP supported multiple editors, that is FCKEditor v1 and v2 and a couple more, including a plain text  box. Of course this is a good feature but I'm not sure it's worth the pain of generalization and abstraction. A more specific approach, tied to FCKEditor and plain text, for example, could be more useful as it could integrate more features.

However, I'm just considering that. Being able to support multiple editor could mean having more value though I don't think many users will switch among editors. Users usually tend to exploit the best editor integrated, which is FCKEditor v2 for sure. I believe the problem lies in client scripts so I will check integration to be sure. I don't think it will be difficult to spot the problem. However, this is not a showstopper since other editors are available for now.

EDIT: found out that the FCKEditor problem only occurs with IE but it works fine in Firefox, Chrome etc. I think there's something wrong here in the way themes and pages are handled. Should perform more checks to understand where the problem lies.

With the first release approaching, choosing a license for Diavolo is something important for the future of this project. Original Rainbow Portal v2 has been licensed according to Apache License v2.0 and this allowed the whole Diavolo effort to sparke. So Apache License is a possible choice.

Personally I way prefer Microsoft's Public License (MS-PL) so that would be my first choice. I was also considering EUPL, open-source license approved by European Union, expecially because it has been compiled to stand in EU courts and available in 23 languages. The former reason is very interesting, when you consider that most GPL doubts are wether it could stand a court trial (if I'm not wrong, it passed a few courts tests but still...). However, EUPL is a copyleft license, so it has the viral clause which makes GPL popular but also not desiderable for business reasons.

So here's a quick facts summary:

• Apache License : good. That's the original RP 2.0 license;
• MS-PL : good. It's short and easy to understand and basically provides the same conditions of Apache License;
• EUPL : good in general terms but bad because of viral clause.

Additionally, since I plan to release Diavolo on CodePlex, MS-PL might be the right choice, even if that website welcomes basically most of open-source licenses.

So be it: MS-PL has been choosen for first releases. This license could be changed later if it proves not to be well-suited for my goals.

Since I completed migration to .NET2+ membership system (see previous), first release ever is approaching. I'm pretty confident that no major bugs will arise since I basically reproduced most original Rainbow features via a Core sub-system. That sub-system, as most in Diavolo, can be switched by simply replacing its assembly with a compatible one (thanks to MEF).  I will focus on debugging for a few days in order to test the whole system but I don't expect to find major bugs as original Rainbow calls have been preserved and migrated to new system.

The most important thing is to check for user IDs bugs. Since I switched from INTs to GUIDs, there could be places where code might assume that it is dealing with INTs (for example, loggin user's login errors assume user IDs are INTs and tries to convert them into that, which causes an exception of course). The good news is I already converted modules code as it was easy to spot where breaking could occurr once you changed return values and attempt to compile modules (beauty of pre-compilation...). So as of now, there should be no major bugs in code but some minor could still be there. I will focus on fixing that before my first attempt to release Diavolo will happen. First version will be 3.0.0BETA, as homage to its Rainbow Portal roots and to allow portal upgrades.

Oh, did I mention the fact that upgraded portals can have its users upgraded on their first login?  That's very hot ! You could set Diavolo to upgrade legacy Rainbow users to new membership system via web.config setting. Then, once you're sure no legacy user still needs to be migrated (or once you fed up waiting they log on), you can disable that feature, speed-up login process and only allow logins via new membership system. Details about this will be released soon.

Wow! It took me two months more to reach this stage but I'm very proud to say that Diavolo migration to .NET2+ membership and role system has been completed ! This is a very huge jump-start as I had to evaluate many different design choices before going on and complete development. Particularly, I'm happy to say that Diavolo can upgrade a Rainbow 1.6 or 2.0 portal but can also install in a new fresh portal. Since it's compiled for .NET3.5 SP1, it shares all benefit of that platform and can work both in 32 or 64bit fashion.

I dad to change many things inside Rainbow codebase but I'm glad that I was able to assure compatibility with ASP.NET SQLMembershipProvider and SQLRoleProvider. This is important because that means Diavolo is table-level compatible with such providers and basically means that your other applications can share users and roles data with Diavolo itself. That opens a wide range of possibilities and it makes SSO (Single Sign-On) services possible as you could simply let other .NET applications point to main Diavolo database and set them to use standard membership and role providers. Et voilà : your other applications will shared users and roles data. The only real change was extending MobileAlias field to 256chars, since MobileAlias is Diavolo is always set to e-mail address (standard field was 16 chars long). But I don't think that will be a breaking change unless you validate its length.

I'm also very happy to state that core Diavolo features will be supported via runtime-discovery-and-binding features via MEF (Managed Extensibility Framework). This is great code by Microsoft and I told you about that in a earlier post. This means many sub-systems of Diavolo could be replaced by simply dropping a compatible DLL inside its bin folder. Through auto-discovery, MEF links to such code without the need to change anything inside your web.config file. That's even better than provider model ! I used MEF to build an implementation linked to membership and role providers and tied to CoolStorage library but that way I could basically switch to another implementation (say, a LINQ one) by simply dropping its assembly inside Diavolo bin folder.

I have to say that upgrading Rainbow 2.0 to first Diavolo release was huge. Since I changed many core attributes too (for example, basic table keys were changed from INTs to GUIDs), I had to refactor much Rainbow code, to a point where I started to think it was very difficult to complete that as Rainbow, taken as a whole, is a very HUGE application.