Blog comment spam has been a massive frustration for our users over the last few months. Although the original release of MonoX blog subsystem followed the Google recommendations for preventing comment spam, the guys behind this obviously lucrative business don't really care about "nofollow" tags - they are submitting non-relevant comments agresivelly. On a side note, there are several companies that allow you to buy spam comments in batches of 100 or 1000, as described in this article. It's no wonder that some of our users got more than 20k spam comments submitted in less than six months to only a dozen blog posts.

This is going to change with the new, "social networking" release of MonoX later this month. We provide a pluggable, provider-based architecture that enables users to pick one or more public antispam services or develop their own solutions. Akismet and Defensio are suported out-of-the-box; if you want to develop your own filter we recommend starting with the article on Bayesian spam filter on CodeProject.

You may choose manual or automatic comment approval modes - in any case, if the comment is considered to be spam, it will not show in the comment list without your approval and your resident spammer will have to search for his next victim somewhere else.

You may noticed that we've been quiet for the last couple of months. The vacation season is not the primary reason for the lack of updates - quite contrary, we are adding new features to MonoX on a daily basis. Just to give you a test of things to come, here is a short list of features that will be included in the next version that will be released later this year:

- MonoX is switching to .NET 3.5, allowing us to use LINQ, Dynamic Data, portions of MVC technology and similar stuff in the core libraries
- we have switched to the Web application project model, as it offers way better development experience on larger projects - compilation process is now shortened dramatically
- we have introduced some exciting changes to the licensing scheme - more on that later
- MonoX will include a complete Social Networking module set: friend lists, invitations, messaging, wall, notes, groups, profiles...
Stay tuned for more news and let us know which features do you want to see included in next releases.

New version of MonoX was published today, featuring many improvements in back-end functionality (especially data access) and a brand blog module set. Although MonoX can be completely integrated with third-party blog tools like DotNetBlogEngine, our users  often requested a custom subsystem that can be customized using standard MonoX administration utilities. So here it is, an easy to use module set that offers a complete functionality of "stand-alone" blog engines:

• multi-user support
• WYSIWYG editor
• support for multiple categories
• role support
• template/theme support
• automatic tag extraction
• support for ping services
• Search engine Optimization (SEO) support
• support for gravatars
• ... and, of course, full integration with the MonoX portal engine.

We are planing to release a complete set of ASP.NET social networking tools in the near future, so stay tuned and keep sending comments about this version and suggestions on how to make MonoX a better tool.

Recently we have published an application optimization package - Web Application Optimizer (WAO), and a few of our users requested a short example on how to build a custom ViewState provider. We have built two sample providers - one for the "beginner level" and one for more advanced developers.

1. Session provider - beginner-level provider that saves the ViewState data to the session.
2. Memory provider - advanced-level provider that saves the ViewState data to the memory (Asp.net worker process).

Building custom ViewState provider is a rather simple process. The first thing you need to do is to create a class that inherits from the BasePageStatePersister (a WAO base class for all ViewState providers). BasePageStatePersister contains a few useful properties and methods that you should understand before building custom WAO view state provider, and these are:

1. StateKey – used as a key that needs to be stored to maintain view state between postbacks (can be overridden for custom functionality).
2. LoadStateKey – used to get previously saved key (can be overridden for custom functionality).
3. Load method – you should override this method and implement any custom "load" functionality here.
4. Save method – you should override this method and implement any custom "save" functionality here.
Note: You need to call the “base.Save();”to be sure that proper ViewState key is saved. For more details on "Load" and "Save" method implementations please refer to the sample providers source code.

Notes:
1. When building your own ViewState providers keep in mind that if you are using custom storage (Cache, SQL, Memory, etc.) you need to release these resources after some time.
2. If you have custom properties implemented on any of the custom providers you can set them under the “customProperties” tag in the web.config's WAO ViewState section and they will be initialized when needed.
3. To add your custom provider to the ViewState provider configuration section please use the template below: 

<add workingFolder="" sqlConnectionString="" name="MemoryProvider" type="MonoSoftware.Web.WAO.Providers.MemoryProvider, MonoSoftware.Web.WAO.Providers.MemoryProvider" customProperties="RecycleTime=5;ViewStateTimeout=30;" />
<add workingFolder="" sqlConnectionString="" name="SessionProvider"type="MonoSoftware.Web.WAO.Providers.SessionProvider,MonoSoftware.Web.WAO.Providers.SessionProvider" customProperties="" />

Last month we've published an application optimization package - Web Application Optimizer (WAO) - with features that include HTTP compression, ViewState optimization and CSS/Javascript optimization. WAO significantly increases the response time for Web applications of all sizes, and, most importantly, there is no need to modify the source code of your applications!

The package works in very different application scenarios and we've got plenty of useful feedback from the first group of users. There has been a slight confusion related to the availability of WAO in our MonoX framework. I wanted to formally announce that  WAO is available by default in all versions of MonoX. It is easy to tell if the WAO is active by the absence of big ViewState data chunk from the page source.

Declarative parameter binding is one of those small gems that will save you a lot of time that was usually spent of writing QueryString parameter retrieval code. We started for an idea that was described a long ago by a guy named Piers Williams on CodeProject. His article discusses a reflection/attribute based strategy for automatic population of instance fields and properties on an ASP.NET page from parameters supplied via properties of the Request object - GET-based Request.QueryString or POST-based Request.Form.
As a result, you are able to populate instance fields and properties using attrubutes which specify the QueryString or Form parameter to bind to. No need for repetitive chunks of code that parses the Request.QueryString["whatever"], checking for nulls, casting, error handling, etc. New MonoX syntax is clean and elegant:

[QueryParameter("PublicName")]
public string PrivateName;

[QueryParameter("MyName", DefaultValue="default")]
public string MyName{
      get{ return (string)ViewState["MyName"]; }
      set{ ViewState["MyName"]=value; }
}

[QueryParameter("IntParam", DefaultValue="0")]
public int MyIntParameter;

Note that there we were striving for a minimalistic solution that could be used with existing portal projects. There are alternative approaches, and PageMethods by metaSapiens is probably known to most of our users. Although it provides additional benefits (like strongly-typed navigation, another useful technique that will be described here soon), it also adds some overhead. An additional file - PageList.xml - is automatically generated in a process that is not really compatible with the portal page navigation generation. It is available as a VS add-in only and introduces problems in the command-line build process that we use on our contionous integration server.

Service Pack 1 for the Microsoft .NET Framework 3.5 introduced a number of important changes, including the ASP.NET routing engine. Although routing is traditionally associated with ASP.NET Model View Controller (MVC) framework, Microsoft decide to package the routing logic into the System.Web.Routing assembly and to release this assembly with SP1. This was a nice move, since it enabled us to easily integrate the routing technology into MonoX.
However, you may wonder what's the difference between the ordinary URL rewriting and this new technology. Both allow us to build friendly, "hackable" URLs for our Web applications - however, the routing engine can decouple the URL in an incoming HTTP request from the physical Web Form that responds to the request. This is natural to developers that are using MVC - 1:1 relationship between an incoming URL and the physical aspx page is now gone. Additionally, URL rewriting is a one-way translation mechanism because there is no easy mechanism to let the URL rewriting logic work in both directions.  In another words, it was difficult to give the rewriting logic the internal URL of a Web form and have it return a public URL required to reach this form. Routing engine allows you to translate URLs both ways.

There are many more important design decisions behind this new feature. Scott Allen has a nice article on MSDN magazine that describes all you need to know about routing with Web forms. Phil Haack and Chris Cavanagh recently published a series of in-depth blog posts related to this topic - a mix of their techniques were used to introduce the full routing support in MonoX. Daniel Fisher helped us with his implementation of query parameters support, something that was neccessary since MonoX relies on query parameters for localization and similar purposes.

Attached is a simple package that can be used to add the support for routing in your MonoX-based projects. Include the classes from the routing folder in the App_Code of your application (change the namespace as you wish), and use the skeleton code from the BasePage in your project's base page. Additionally, make sure that the routing-dependant entries from the attached web.config file are present in your web.config.

For a taste of things to come, read more about WebForm routing in ASP.NET 4.0.

On a side note, SP1 also introduced Dynamic Data, a very neat scaffolding mechanism that enables developers to create data-driven applications with minimal or no code. We will cover this technology and its integration with MonoX in a few weeks.

 

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