There's been a lot of talk about the new ASP.NET MVC (Model View Controller) framework and its interoperability with the "standard" Web form applications like MonoX. MVC approach brings a lot of neat features to ASP.NET developers:

• it gives you a total control over the rendered HTML (no client-side ID pollution and similar by-products of the Web form approach)
• it provides clean separation of concerns
• it enables test driven development (TDD). Web forms and TDD were not a really happy couple, since Web form (aspx) code is running inside the ASP.NET worker process. Your pages need access to the HTTPContext, the Request and Response objects, and everything else that ASP.NET provides them at runtime
• search engine-friendly URLs (in MVC you don't have to have a physical server file for every URL)
• easy integration with javascript frameworks
• absence of ViewState and PostBacks

We are aware that many of ASP.NET developers will not really appreciate the last feature. After all, ViewState and Postback events were at the very centre of the ASP.NET programming model for almost a decade. In my opinion, while it was certainly useful to use the same mental model of development for both Web and desktop environments, this approach was rather clumsy and produced many side-effects. On the other hand, MVC will have its share of problems, especially in this early stage. ASP.NET MVC views are rather hard to read beacuse of the tag soup we thought was left in the good old classic ASP days. While the separation of concerns is a very good thing, the separation of the HTML markup and the inline code cannot be completely disregarded as a non issue. Due to the vast marketplace of powerful ASP.NET controls that are available today, many of the developers we know will have a tough time switching to the "use foreach loop instead of the repeater" mentality. Although this can look rather extreme, there are a few techniques for RAD-style MVC development: using lambdas, MVC UI Helpers, custom view engines,... Additionally, many of the major control development companies already announced MVC versions of their products.

In any case, we love the MVC framework and are starting to use it in our MonoX-based projects. Scott Hanselman recently published an excellent article on using Web Forms and MVC side-by-side in your projects. For those of you that feel that routing rules should never go to the compiled code file, Jonathan Holland built a MVC RouteBuilder HTTP module that allows you to move all routes to the web.config file. We encourage you to give MVC a try - please let us know if you need any additional help with it.

Designing new portal themes or templates (we use both terms, template is a set of all files needed to give a portal a certain look and feel, while a theme is just an ASP.NET theme) is one of the tasks that our users perform very often. The process is described in the user manual, but sometimes it is difficult to grasp what exactly needs to be done in order to produce a fully functional portal theme, especially if you don't have any experience with ASP.NET themes and master pages. We decided to publish a design template gallery to provide our users with ready-to-use designs that could be used instantly. You just need to unzip the template package in the root folder of your portal and start to use the new page template.

There is just a single Theron template in the gallery at this moment, but it will grow steadily over the next few months. All templates are free for MonoX users.

Please take a moment and study the structure of the package. In essence, a portal template is just a set of images and CSS files placed in the appropriate App_Themes folder. This theme is than applied to the template's master page (placed in /MonoX/MasterPages folder, but could be placed elsewhere). You can than just use this master page for your content pages. Additionally, MonoX allows you to place all control templates in the App_Templates folder to control all visual aspects of the portal controls.

Localization is one of the areas in which we made a very significant progress during the past few years. First release of MonoX included only a default support for localization: you were able to localize the user interface elements using the standard .resx approach, but you had to open an additional portal for each of the target languages that were required for localization. Content synchronization was rather difficult, so we decided to redesign this feature and introduce a flexible arhitecture with support for run-time localization. This means that you don't have to use Visual Studio or other tools to change localization resource files; everything can be done through the browser-based administration interface.

A single portal instance can support unlimited number of localized sites, where each site has the same structure, but different (localized) content. You can change the navigation hierarchy and modify the layout of every localized page. Each of the existing pages (administration etc.) can be fully localized using the Language management section. Note that MonoX can use both resource (resx) files and a database to store localization values. You can switch between resx and database modes by changing the globalization tag in the Web.config file. The database mode is specified by adding the following attribute to the globalization key:

resourceProviderFactoryType="MonoSoftware.Web.Localization.DBResourceProviderFactory, MonoSoftware.Web.Localization"

This feature gives you a complete control over the localization process, since it would be impossible to localize all resources at run time (both built-in and custom ones) using only a resx approach. It is possible to export values from database to resx files and vice versa, both for a single page/control or for a whole portal at once. Additionally, MonoX uses a translation engines to suggest a correct translation for each localization resource.

The default portal demo at http://www.mono-software.com has its localized Croatian version at http://monox.mono-software.com/language/hr-HR/Default.aspx 

We received a lots of comments and questions regarding the data access layer in MonoX. Many of our new users never heard about LLBLGen Pro - an Object Relational Mapping tool of our choice, and they consider it as too exotic.
MonoX lets you choose the DAL generation tool that will be used in your portal projects. We used various ORMs in our projects (NHibernate, Subsonic, ...) but LLBLGen remains our favorite due to the richness of its features and the very high level of the support provided by its authors.

Of course, we don't want to avoid LINQ - MonoX was concieved when LINQ was in the alpha stage, but we quickly started to adopt it. Essentially, LLBLGen still offers a richer set of features, but if you are in doubt, guys from Solutions Design recently developed Linq to LLBLGen - now you can use both technologies interchangeably.

One of the design decisions we had to make quite early was whether to develop our own blog, forum and similar packages, or to use the existing software from third-party vendors. Integrating the old ASP.NET forums (now Community Server) with the first version of MonoX was quite a challenge, as we had to rewrite the portions of the original code, change SQL stored procedures, introduce triggers to keep portal and forum users in sync, etc. At the end, so much effort was invested during the integration process that writing a new package from scratch seemed much more attractive.

This time we again made a quick overview of the existing third-party packages and soon realized that we will have a much easier job this time. There are a few excellent open source systems - it wouldn't make too much sense to reinvent a wheel with yet another blog or forum or whatever. The key to success in this story is ASP.NET  2.0 provider model. As you probably know, a provider is a software module that provides a uniform interface between a service and a data source. Providers abstract physical storage media, in much the same way that device drivers abstract physical hardware devices. In our case, integrating MonoX with the leading blog, e-commerce and forum engines requires just a few changes in their configuration files. The benefits are huge: you can enable single sign-on feature and have all the user and role information stored in the main portal database. All authorization and authentication tasks will be performed by the main portal, so there will be no multiple login pages that confuse users; moreover, user maintenance tasks will become much easier, as all relevant data are kept in the single location.

Information regarding the integration with BlogEngine.Net and YetAnotherForum can be found in our MonoX support forum.

This week we are finally releasing the new version of MonoX, our portal engine built on top of ASP.NET Web Parts framework. The main idea of Web Parts Framework is to let end users create and configure Web pages by dragging in functional blocks (called Web Parts) and setting properties on these blocks. This configuration happens right inside the Web page, using nothing but a standard Web browser. To change a page in the site, you browse to this page, switch to edit mode and change it. Non-technical users can change the layout of their page by dragging and dropping the web parts to different zones on the page. Each of the parts exposes a configuration user interface to change its behavior and appearance.

We have used a concept similar to Web parts in the first commercial release of MonoX portal framework (published during 2003). It was based on a very popular IBuySpy portal application, and introduced drag and drop and visual configuration features that are now accepted in the new Web part framework. However, the initial version was not using the standard API, as it was not available at that time. Nevertheless, it enabled us and our clients to build very sophisticated portal solutions

This new version of MonoX fully supports all the features of ASP.NET 2.0 Web part framework. To the best of our knowledge, it is the only commercially available product including this feature, as other portal products use proprietary Web part/module architectures. In addition, MonoX fully support all other standard ASP.NET 2.0 features, including personalization, master pages, themes and provider models, and adds significant additional functionality described in the user manual that is a part of the installation package.

There are a few custom large-scale portals that were built on top of the MonoX v2. EmployIreland.ie is one of them; it includes dozens of custom Web parts and shows how far can you go with MonoX. We encourage all potential users to download the trial version and try it on their local machines - there are so many features that cannot be presented on a public Web site.