I'm getting asked for this a lot (lately on the Castle's usergroup, and on many other occasions)

You friend is ActiveRecordMediator.Execute

So here is a sample:

ActiveRecordMediator.Execute(typeof(ActiveRecordBase), delegate (NHIbernate.ISession session, object data)
{
   IDbConnection con = session.Connection;
   IDbCommand cmd = con.CreateCommand();
 
   // That's the key part - joining the current AR transaction scope
   session.Transaction.Enlist(cmd);   
 
   // now you have a IDbCommand instance - use it at will

}, null);

If you want to create a proper method for handling the delegate instead of the anonymous one, then you can pass data in there (using the third argument) and it would get into the delegate as the "object data" thing.

There appear to be yet another XML API.

So, when you want to generate:

<?xml version="1.0" encoding="utf-8"?>
<root>
    <result type="boolean">true</result>
</root>

instead of (using System.XML):

XmlDocument xd = new XmlDocument();
xd.AppendChild(xd.CreateXmlDeclaration("1.0", "utf-8", ""));

XmlNode root = xd.CreateElement("root");
xd.AppendChild(root);

XmlNode result = xd.CreateElement("result");
result.InnerText = "true";

XmlAttribute type = xd.CreateAttribute("type");
type.Value = "boolean";

result.Attributes.Append(type);
root.AppendChild(result);

one can (using the new API):

XmlOutput xo = new XmlOutput()
    .XmlDeclaration()
    .Node("root").Within()
        .Node("result").Attribute("type", "boolean").InnerText("true");

Exciting.

Or is it?

Why not just (using your template-engine of choice):

<?xml version="1.0" encoding="utf-8"?>
<root>
    <result type="<%=view.Type%>"><%=view.Value%></result>
</root>

works great for the "complex" scenarios on Mark S. Rasmussen's blog:

<?xml version="1.0" encoding="utf-8"?>
<root>
    <numbers>
        <% foreach (Number number in view.Numbers) { %>
        <number value="<%=number%>">This is the number: <%=number%></number>
        <% } %>
    </numbers>
</root>

and:

<?xml version="1.0" encoding="utf-8"?>
<root>
    <user>
        <username><%=view.User.Username%></username>
        <realname><%=view.User.RealName%></realname>
        <description><%#view.User.Username%></description>
        <articles>
            <% foreach (Article article in view.User.Articles) { %>
            <article id="<%=article.Id%>"><%#article.Title%></article>
            <% } %>
        </articles>
        <hobbies>
            <% foreach (Hobby hobby in view.User.Hobbies) { %> 
            <hobby><%#hobby.Name%></hobby>
            <% } %> 
        </hobbies>
    </user>
</root>

is Hobby and Article more complex? no probs. break it down to sub-views:

<?xml version="1.0" encoding="utf-8"?>
<root>
    <user>
        <username><%=view.User.Username%></username>
        <realname><%=view.User.RealName%></realname>
        <description><%#view.User.Username%></description>
        <articles>
            <% foreach (Article article in view.User.Articles) { %>
            <subview:Article article="<%=article%>"></subview:Article>
            <% } %>
        </articles>
        <hobbies>
            <% foreach (Hobby hobby in view.User.Hobbies) { %> 
            <subview:Hobby hobby="<%=hobby%>"></subview:Hobby> 
            <% } %> 
        </hobbies>
    </user>
</root>

Can you get more expressive that that?

Look how easy it is to visualize what we're rendering, and how easy it is to change.

I consider all those XML API (including ATOM/RSS writers) as a leaky and unneeded abstractions, just like WebForms. Do you?

Reading this post from Phil Haack made me jump a little. Oh no, I said, Please don't let the clean IMvcFramework become clumsy.

Ayende has ranted about it better than I would.

Now I see that Phil has issues with ABC as well.

The answers for the ABC problems he shows there are cumbersome. In order to gain "flexibility", you end up polluting your API with "CanSupportCrap" methods, etc.

So, to recap:

1. Phil, (probably inspired by Framework Design Guidelines) claim that using ABC over Interfaces is better as it won't cause breaking changes.
2. Ayende points out that the breaking change won't be to the end user (as in - developers who uses the framework) but rather to the framework maintainer (who works hard anyway and should know his way around), and to framework extenders (again, should not whine about those 'breaking changes'). As an aside, Ayende also brings up the sealed/internal/non-virtual rant.
3. Phil admits to the weaknesses of ABC, just by showing an even weaker way of overcoming them.
4. I recap all that.

Please Please Please keep IHttpContext in place ...

I'm terribly sorry, but it seam that I've had a problem with my mail server, so during the last two month I did not receive any mail sent to my mail address on this domain.

I was able to access some of those now, and I'm going over the messages, so if you were waiting for a response regarding any Castle / AspView / Other issue, I hope Ill get in contact soon.

Lately there has been some noise around the lack of documentation on the Castle project.

I have expressed my view on the matter on the mailing list, and in short I'd say that having an undocumented feature is way better than not having that feature at all.

During the ALT.NET UK conference, one of the guys approached me and said that he has solid background in technical documentation, and that he is willing to put some effort to that end.

I'm terrible with names, so I forgot his (sorry ...), but if it's you dear reader (or if it's not you, but you are willing to help with that) then please do contact me should you need any help in kicking it off.

Thanks a bunch,

Ken.

I guess we are all crazy.

I swear that this post's content is true:

I certainly remember a few occurrences of going to sleep with some coding/design problem or idea (of late - SQL Query Generator), just to wake up with a solution. I also tend to wake up from disturbing dreams, with some of those being just the regular night horrors, but at times they involve irresolvable build errors, ASP.NET yellow screens, and TortoiseSVN irritating noises.

Anyone like to share his Coding Dreams?

Given the following code:

public void UpdatePerson(int id, string name)
{
    Person p = peopleRepository.Get(id);
    p.name = name;
    peopleRepository.Update(p);
}

One answer would be (using a pseudo mocking framework):

Person p = new Person();
Expect.Call(peopleRepository.Get(0))
        .Returns(p);

Expect.Call(peopleRepository.Update(p));  

...  

service.UpdatePerson(0, "MyName");

Other approach would be (using pseudo coding again):

Person p = CreateAndInsertToDB();
service.UpdatePerson(p.id, "New Name");
 
FlushAndRecreateTheSession();
 
Person updated  = GetFromDB(p.Id);
Assert.Equal("New Name", updated.Name);

What would you do, and why?

(I'm tagging that also under altnetuk as it has been inspired by a session around test-granularity, mocking frameworks, etc.)

This weekend I've had to pleasure to attend the altnetuk conf in London. This has been quite an amazing experience. I have really liked the way it has ben organized into open-spaces, and I just wish I could've split myself to four, so I'd be able to be at all of the sessions (the F# one was greatly missed ...)

I have met great people, have discussed exciting things, and had a lot of fun.

Most of the people referred to me as "the MonoRail guy" which was quite amusing, as I am only the creator of AspView (which in turn is a shameless idea-and-code ripoff from Brail), and I have very little to do with the actuall coolness and usefulness of MonoRail ... I do hope though that I did manage to address pepole concerns regarding MonoRail, and the Castle Project as a whole.

Interesting (however not surprising) moment:

On the panel dealing with MVC frameworks for ASP.NET, about 25 people were around the table. When people who are actually using MonoRail/ASP.NET MVC for commercial production environment, only 4 have raised their hands. however, all the others said that they wish the could have done that, and the only reason they do not, is the reluctance from their bosses/clients.

Yep, I've made yet another noob mistake.

I needed to compare two enum values, on a method that was accepting objects.

public string Whatever(object currentOption, object selectedOption)
{
    return
        currentOption == selectedOption
        ? "class='active' "
        : string.Empty;
}

Didn't work.

However,

public string Whatever(object currentOption, object selectedOption)
{
    return
        currentOption.Equals(selectedOption)
        ? "class='active' "
        : string.Empty;
}

Did work.

so, it appear that == isn't polymorphic so it did the object.Equals method which apparently looks for reference equality, rather than the enum Equals.

And that has been yet another future-reference-post ...

After being told that MonoRail would not make his dreams come true, Dylan Beattie have answered:

"MonoRail would not make my dreams come true. It would however, make my nightmares disappear"

Brilliant.

Last Thursday I was informed by the organizers of alt.net UK conference that they have managed to squeeze me in, so I immediatly booked a flight to London, and have attendet.

I was superb, and I've written a few posts, but since I was not online during the last few days I had no chance of publishing 'em. Hopefully they'll get during the next few days.

A lot have also been piling up on my MonoRail and AspView "desktops" so I appreciate the patience of the users, and I promise to do my best to keep up with the requests and patches being sent to me ...