NHibernate 2.0 Wiki can be found here. This wiki already includes the entire NHibernate documentation, so you can head there and start learning.

Have fun...

I am currently working on an interesting application, basically, rule engine, data + DSL, and other fun stuff. Unfortunately, here is how the UI is right now:

Yes, the disclaimer is in the UI.

Therefor, I currently looking for a WPF dev / designer. I am currently in New York, but there is no location limitation.

If you are interested, please contact me.

Here is a question that came up in the book's forums:

I can't figure out how to get the text of the expression from expression.ToCodeString() or better yet, the actual text from the .boo file.

It appears to automagically convert from type Expression to a delegate. What I want is to be able to when a condition is evaluated display the condition that was evaluated, so if when 1 < 5 was evaluated I would be able to get the string "when 1 < 5" - Any way to do this?

Let us see what the issue is. Given this code:

when order.Amount > 10:
	print "yeah!"

We want to see the following printed:

Because 'order.Amount > 10' evaluated to true, executing rule action.
yeah!

The problem, of course, is how exactly to get the string that represent the rule. It is actually simple to do, we just need to ask the compiler nicely, like this:

public abstract class OrderRule
{
    public Predicate<Order> Condition { get; set; }
    public string ConditionString { get; set; }
    public Action RuleAction { get; set; }
    protected Order order;
    public abstract void Build();

    [Meta]
    public static Expression when(Expression expression, Expression action)
    {
        var condition = new BlockExpression();
        condition.Body.Add(new ReturnStatement(expression));
        return new MethodInvocationExpression(
            new ReferenceExpression("When"),
            condition,
            new StringLiteralExpression(expression.ToCodeString()),
            action
            );
    }


    public void When(Predicate<Order> condition, string conditionAsString, Action action)
    {
        Condition = condition;
        ConditionString = conditionAsString;
        RuleAction = action;
    }

    public void Evaluate(Order o)
    {
        order = o;
        if (Condition(o) == false)
            return;
        Console.WriteLine("Because '{0}' evaluated to true, running rule action",ConditionString);
        RuleAction();
    }
}

The key here happens in the when() static method. We translate the call to the when keyword to a call to the When() instance method. Along the way, we aren't passing just the arguments that we got, we are also passing a string literal with the code that was extracted from the relevant expression.

Another interesting question from Chris Ortman:

So I write my dsl, and tell my customer to here edit this text file?
How do I tell them what the possible options are? Intellisense?
This is a web app, and my desire to build intellisense into a javascript rich text editor is very low.
It might be a good excuse to try out silverlight but even then it seems a large task.
Or I put express or #Develop on the server and make that the 'admin' gui?

This is actually a question that comes up often. Yes, we have a DSL and now it is easy to change, how are we going to deal with changes that affect production?

There are actually several layers to this question. First, there is the practical matter of having some sort of a UI to enable this change. As Chris has noted, this is not something that can be trivially produced as part of the admin section. But the UI is only a tiny part of it. This is especially the case if you want to do things directly on production.

There is a whole host of challenges that come up in this scenario (error handling, handling frequent changes, cascading updates, debugging, invasive execution, etc) that needs to be dealt with. In development mode, there is no issue, because we can afford to be unsafe there. For production, that is not an option. Then you have to deal with issues such as providing auditing information, "who did what, why and when". Another important consideration is the ability to safely roll back a change.

As you can imagine, this is not a simple matter.

My approach, usually, is to avoid this requirement as much as possible. That is, I do not allow to do such things on production. Oh, it is still possible, but it is a manual process that is there for emergency use only. Similar to the ability to log in to the production DB and run queries, is should be reserved, rare and avoided if possible.

However, this is not always possible. If the client needs the ability to do edit the DSL scripts on production, then we need to provide a way for them to do so. What I have found to be useful is to not provide a way to work directly on production. No, I am not being a smartass here, I actually have a point. Instead of working directly on the production scripts, we start, as part of the design, to store the scripts in an SVN server, which is part of the application itself.

If you want to access the scripts, you check them out of the SVN server. Now you can edit them with any tool you want, and finish by committing them back to the repository. The application monitors the repository and will update itself when a commit is done to the /production branch.

This has several big advantages. First, we don't have the problem of partial updates, we have a pretty good audit trail and we have built in reversibility. In addition to that, we avoid the whole problem of having to build a UI for editing the scripts on production, we use the same tools that we use during development for that.

As a side benefit, this also means that pushing script changes to a farm is builtin.

And yes, this is basically continuous integration as part of the actual applicatio.