Razor and Mono on Ubuntu

I just thought I'd write a little about the process of getting Xizi's new Razor-based template system working under Mono on Ubuntu.

I followed the guide at http://www.integratedwebsystems.com/2011/06/get-mvc3-razor-running-on-mono/#more-1156 by Nathan Bridgewater. This is immensely useful with lots of no-nonsense information on the process.

However, I did encounter a problem with how I'd set up my project in Visual Studio 2010. I had used the "Add Deployable Dependencies" feature which created a folder containing the various System and Microsoft namespace DLLs that would be required for the deployment. This configuration does NOT work under Mono, and rather frustratingly I wasted a good couple of hours trying to fix the problem rather than taking a step back and re-reading the instructions in Nathan's article.

The error that is produced complains about the version of DotNetOpenAuth that is linked to by the Microsoft.Web.WebPages.OAuth.dll file included in the dependencies. I tried following the thread of fixing this by trying to source a copy of DotNetOpenAuth, including the project it is from, of finding the right version for Mono and this version of .Net and the further I got then the more it unraveled.

In the end, I stopped, removed all that I had done and went back to the original deployment set up. After removing the Microsoft.Web.WebPages.OAuth.dll file and then receiving the error "System.Security.SecurityException: No access to the given key" I read about the same message in Nathan's article which gave a very basic instruction - "Delete Microsoft.Web.Infrastructure.dll from you bin directory" [sic]. The simple act of removing the Microsoft namespace DLLs from the included dependencies worked perfectly.

So, thanks to Nathan Bridgewater for compiling such a good guide; I'll try to read it more thoroughly next time :)

Milestone: Events and Scripting

Big update today - added scripting and more efficient adding of instances.

Over the past few days I've been struggling with the composition of the event subscription model. I knew I wanted to have scripting in there somewhere, but I wasn't entirely sure where. However, I think I've reached the right kind of shape for it.

When Collections, Instances or Items are added to a Database, an event will be raised and broadcasted to any Subscribers that are listed in the Database. Each Subscriber is connected to an EventDefinition that describes both the trigger criteria and name of an action to be raised if that trigger fires.

An IronPython scripting engine has been added so that the trigger script of an EventDefinition can be interpreted as an expression yielding true or false. The event type, User, Database and the Collection, Instance, Item (as appropriate) are available to the IronPython script. At the moment, the test case is simply returning true if an Instance type matches a particular criteria.

The scripting engine is called asynchronously using a Task construct once the API has completed its operation. I've not used Tasks before so this is experimental for now and I'm not sure how they work under Mono yet. The engine is pluggable, so other scripting languages could also be made available in the future.

XmlReader

Working with XmlReader is horrifying, but it's much, much faster than parsing with XmlDoc.

XiziClient has a much simpler test for operation success, now and ScrobblerApp has an optimised method for parsing the database xml it receives back from Xizi.

I'm a little bit concerned about what happens when these databases reach a certain size, but will press on for the moment.

API, Caching Razor and Session

In my haste to switch to using RazorEngine, I accidently the whole API. This has now been fixed.

Caching has been added to the Razor templates as well, based on [template-domain]-[template-name] keys.

Timings with ScrobblingApp are down to less than 2 seconds to read a database (must look into this) and saving a new instance and item in 50 milliseconds total. Not quite sure why those are taking so long.

Also, I've added API calls to the list of things that are excluded from having a session saved in the master cache, although it will be created and added to the context for the duration of the request.

Edit:

By setting RazorEngine to emit raw strings instead of html encoding, this has increased the performance of the database read api call - the compiled, cached version is much faster at processing. Time is now down to 0.5 seconds to read the database of 10 items. Still needs massive improvement but it's a start.

Migration to MongoDB

Have successfully migrated some of the core application model (XiziApplication, User) over to be stored in Mongo (or wherever) and not be in the Asura master cache anymore. This leaves just Templates and Session in the master cache, and only Session backed by Redis.

Razor

This weekend I have refitted the underlying toolkit to use Razor templates, using the very good RazorEngine.

Login and User pages now are in a basic working state after these changes.

Milestone: Xizi staging server

After an evening of tinkering, I've managed to get the Xizi server working on my Ubuntu box, running under XSP4/Mono, with Redis and MongoDB all local. The machine hadn't been switched on since sometime last year so I took the opportunity to upgrade it to the current Ubuntu distribution while I was at it.

So, this box is essentially identical to the hosted testing server, which means it will be possible to just FTP the same code and config across and have it working there too.

Very pleased :)

Milestone: User profile page

First viewing of a user profile page just occurred.

Under construction

This will be the development blog for a project called Xizi.

Xizi is an application data storage framework, built using .Net and storage technologies like MongoDB and Redis.

More soon.