PrimordialCode is now powered by the open source Dexter Blog Engine

It's time for another new beginning.

Over a month ago I joined the Dexter's Developers Team, cause I felt that the project was indeed good and I liked the idea to participate in developing something I could also have used.

When I entered the project it was missing some features I considered vital for me to switch over:

  • The ability to import all my previous data from Wordpress.
  • The support for multiple categories for every post.
  • A better integration with Windows Live Writer (the primary tool I always used to make my posts) to support hierarchical categories, tags and slugs.

I've worked on all these in my spare time during the last month and now that all of them are implemented (there's still some work to do to improve the import section and integrate it in the blog engine instead of using an external tool), I see no reason to not switch over.

So let's say good-bye to my Wordpress version of the blog that accompanied me during this almost two years of blogging experience and say welcome to the new PrimordialCode powered by Dexter (the actual skin is kindly stolen from Ugo’s blog).

There's still more room for improvements and we have a lots of new features on the horizon to implement.

If you are curious about Dexter go check our feature list and download the source code from our
project page on CodePlex: http://dexterblogengine.codeplex.com/

A big thank to all the guys of the team for making this possible.

Related Content


JQuery, WCF and the JSON DateTime serialization

Days ago I blogged about how to call a WCF service from a jQuery application to retrieve and send data to the server to realize a small interactive chatting application. Everything was working fine until it came to format any DateTime data passed from the server to the client.

We ended up having a call like this:

var msg3 = { "msg": { "Id": "2", "Sender": "Webpage", "Text": "Sended Text" }, "id": "1" };

Working on Dexter

I’m not writing many posts in the last days and the main reason is I’ve actively joined the development of Dexter a new open source blog engine written in ASP.NET MVC, you can find it on Codeplex at this link: http://dexterblogengine.codeplex.com/

When my friend Andrea Balducci, talked to me about this project I was so excited I decided to give it a try...and it was good (there’s always room for improvement, but it was good!).

I do love Wordpress, it’s a great product and works very well, why working on another blog engine then? well the answer is short: I’m a developer and I don’t know how to put my hands on the WP engine...simply cause I hate php and never spent more than a couple of hours trying to learn it.

With Dexter is all another story...C#, ASP.NET MVC, NHibernate, Castle etc etc I feel home and (even better) I have the freedom to make experiments on the core engine too.

Since I joined I focused on looking at the implementation and adding the features I needed first. So what I was working on the past days:

  • Improve the import engine to support Wordpress (I’m very close to fix all that I need), you can see a live version of my blog using Dexter at this link: http://dexter.primordialcode.com/
  • Adding a better support for Windows Live Writer improving the different Metaweblog APIs support.
    I just added the hierarchical visualization of category (no more flattening out) and the ability to post the tags related to each post using WLW (no more need to add them at the body of the message).

Here’s a screenshot of the thing:

DexterLive

What I’m working on now:

  • Adding the ability to tie a single Post to more than a single category.
  • Improving the import routines.

All the changes are actually in my private Branch and will be merged to the main trunk once all the developers have reviewed them.

Related Content


Passing JSON serialized objects to a WCF service with jQuery

You can find a lot of posts on the web on the subject, why writing another one then? Simply because despite all the documentation I’ve already found on the web, while trying to put it in action I’ve spent a couple of hours in making that work, so I’ll use this post to recap all the action I made as a reference guide for my future implementations.

The scenario is: we have a WCF service that is able to accept call to methods with complex parameters (like Messages object in a simple web chat project) and we want to be able to use those methods with jQuery with the minimal impact on the service implementation.

WCF Service setup

We consider a very simple implementation, you don’t have to use any ‘strange’ or unusual attribute here:

The message class we are sending back and forth:

/// <summary>

Castle Windsor enabling XML configuration files in Silverlight

When a version of Castle Windsor able to run in Silverlight was released I started to play with it, basically because I have a lot of code that use it inside my line of business infrastructure framework. I’m working on a WPF/Silverlight solution and I’ve developed a framework that work in both the environments.

One of the biggest thing I miss in every ‘Silverlight-enables’ IoC system I tried is the ability to read and parse XML configuration files.

The current release does not allow Silverlight to parse XML configuration file, because all the parser is based on classes that are in the System.Xml namespace and that weren’t included in the Silverlight runtime.

The good news is Silverlight has a very good support for Linq To Xml, so I decided to do a ‘test of feasibility’ and switched the current implementation from using the XmlDom to Linq To Xml.

I have to admit it was more complex than I thought at start (mainly because I had to understand how the parser was written), here are the steps I followed:

  1. Download the ‘Inversion of control’ portion the Castle Windsor trunk an check the project to find the classes to modify: the good news is: all of them are inside a single folder ‘Castle.Windsor\Configuration\Interpreters’
  2. Start with the .Net solution and replace the usages of the ‘old’ XmlDom classes (XmlDocument, XmlNode, etc...) with the new one from System.Xml.Linq (XDocument, XElement, XNode...). Beware it’s not that easy!
    Both these systems act in slightly and sometime subtle different ways so I had to make ‘heavy’ modifications to all the class of the parser.
  3. Keep modifying and fixing the XmlInterpreter and all the other classes until all the tests for the .Net solution pass. At this stage the major modification were the introduction of a LinqToXmlConfigurationDeserializer to replace the standard one and a LinqExtensions class that contains extensions methods to mimic functionalities present in System.Xml.* classes and not directly exposed by Linq classes.
  4. Open up the Silverlight solution, include the new files and verifies it compiles...here some more minor modification were needed to exclude a couple of portions of code that really aren’t available in Silverlight.
    Good! It compiles!
  5. Let’s see an overview of all the files that were modified:
    CastleSilverlightInterpreters All the files we touched are inside the Configuration/Interpreters folders, no other section was modified.
  6. Let’s create a very simple Silverlight Test Application and check it on the ‘Field of Glory’: 
    [TestClass]

Castle DynamicProxy - a dirty trick to call invocation Proceed() multiple times in an interceptor

This is a typical scenario: you have a remote service (a database a web service...anything) which can have connection problems; obviously you don’t want your application to crash the desired behavior can be to retry the operation for a couple of times and then ask the user what to do (with a message box maybe).

Implementing this in Spring.Net is quite easy, here is some ugly code that build up a skeleton for the feature:

[System.CLSCompliant(false)]