The Html Content and Blog features now support keeping a history of every edit (like a wiki). You can compare any historical version of the content to the current version and you can restore any version to the editor so that you can restore it as it is by saving it or modify it further then save it. Versioning can be enabled at the feature instance level or it can be enforced site wide from Site Settings or it can be enforced from Web.config. Site administrators and content administrators can delete history but no other roles are allowed to delete the history. The ContentHistory is built into the core so that it does not have to be re-implemented for each feature. Each feature does implement its own UI to show or restore the previous versions, but they leverage common business classes to store and retrieve their history. In the future we will implement versioning for product and offer descriptions in the WebStore, developers may also leverage this in their own features to keep version history for their own feature data. This is one more thing to mark off our Road Map as complete. Next up is a general Content Tagging/Category system that can be re-used across features, and a Content Comment system that can be re-used across features.

See my previous post for more information about the new Chat feature. This was not even on the roadmap but when I saw how easy it was to implement I decided to work on it. It was fun and it only took a few days. One of the things I like best about my job is that I can just decide to work on something for a few days because its fun.

Some of you may have checked out my Site Office UI prototype in the past. Its a separate plug in system than the main content system designed more for a consistent application user interface rather than for creative design like we use for the public facing web site via our skins. You can see the Site Office layout on this site or the demo site if you login and click the "Site Office" link at the top of the page, or you can look at the origianl layout demo for ExtJs here. I still have not implemented any real features for Site Office, but the plug in system itself works and I've even received emails from developers who have implemented their own plug features using it. I got kind of side tracked off of the Site Office idea partly because I had spent quite a bit of time implementing .NET wrapper cntrols around the ExtJs javascript to make it easy to use and then the ExtJs project changed their license to GPL which is not compatible with our CPL license, so I could no longer get upgrades of ExtJs and include them with mojoPortal. Since then we've been stuck on version 2.0.2 of ExtJs which was the last version they shipped under the LGPL (which was compatible). I had also used a little ExtJs in the Contact Form for the messaage list page. For a long time I've been thinking I really need to build new .NET wrapper controls with similar functionality but using the YUI javascript instead of ExtJs.

 

So again in the name of fun (because I like building .NET controls around javascript) I spent some time implementing some new controls with YUI to replace the ExtJs stuff I've been using. I have now removed the dependency on ExtJs from the Contact Form feature and I've got a good start on the layout framework to replace the current SiteOffice. I still have more work to do to finish, but the goal will be to eliminate all use of ExtJs in favor of YUI. The ExtJs javascript we include in mojoPortal is 6.36 MB, so it will reduce the size of our downloads once we no longer need to it. Anyway, you can see the work I've done so far on the YUI layout here, its very similar as you can see to the current Site Office layout with ExtJs. Once I get some more of the YUI things wrapped up so they are easy to use, I might even change the site administration area so that it uses this kind of layout instead of the site skin.

Some of you may have noticed that the FCKeditor project has shifted gears from the next upgrade of FCKeditor to their next generation version named CKEditor. I think they are basically taking the good parts from the FCKeditor implementation but doing a new redesign of the implementation using things they have learned and new techniques that have emerged to improve the architecture. The CKEditor does not yet have image upload or server browsing so I have disabled it by default, but anyone who really wants to check it out can un-comment it in the mojoEditor.config file in the root of the web. It really looks just like the FCKeditor but does not have all the functionality yet, I just figured it was good to get started with it so we can be ready as they make imporvements.

 

So all of the above (other than the contributions from the community) is work I've done since the last release on March 24, less than 30 days ago, but in that time I've also made a substantial start on my next paid product Web Invoice Pro. It still has a ways to go before release though. Its one of those things where I started out with a very simple vision for it but it quickly changed to a more complex feature the more I thought about it after getting a few little pieces of it built. I needed to step away from it a little to think about it more and that is part of the reason I worked on some fun things as I got to a point where I was frustrated and needed to work on something that made me feel productive.