Dev Blog - Johan Danforth

That's the message I got from the people at a free wiki hosting site when I asked them to terminate my account. I'm thinking their wiki-system is either a mad hack with database dependencies all over the place, or they just want to keep their member count up...

They told me to "go to Account settings and disable everything you can find there"...

Sigh... what to say? I was invited by a friend for a project of his. I know this situation is not unusual, and sometimes it can be hard (like removing yourself from Facebook before they made it much easier due to the massive preassure from the users), but things like this upsets me.

I guess I have to blame myself for registering there in the first place and I guess it's more or less a fact that if you register yourself at a (most often free) site on the Internet, expect to get a number of newsletters and stuff from that site eventually and don't expect it to be easy to terminate your account.

This video gave me a few laughs :)

Hey, I'm just helping to spread the word! A sampled a few links and quotes that has already been posted to blogosphere for your pleasure and knowledge. :)

Download it here -> http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=16775

Phil Haack said:

We didn’t originally plan to have another preview. However, we implemented a few significant chunks of functionality and were dying to get feedback so that we could incorporate it into the product before Beta. It helps that with five or so of these interim releases, we’ve become pretty efficient producing these releases.

We plan to have our next release be our official Beta, which means we’ll have a lot more test passes to produce and run before we release the next one.

Some preview 5 related blog posts:

Brad Wilson wrote about changes to partial rendering and view engine in preview 5.

Maarten Balliauw wrote about easier form validation with preview 5.

Nick Berardi has a list of news and changes and also a few issues he's found and submitted bug reports for:

• AcceptVerbAttribute Not Following HTTP Standards
• ActionMethod Missing From ActionExecutingContext

Derik Whittaker had a few comments regarding sealed classes in preview 5:

It looks like that they removed the sealed keyword from many of the Attributes such as HandleErrorAttribute, AuthorizeAttribute and various other existing Attributes. 

However, looks like many of the other attributes (some new, some not) such as AcceptVerbsAttribute, ModelBinderAttribute and NonActionAttribute are still marked as sealed.  Guys, please unseal all your stuff.  If you have a very, very, very valid reason then fine seal them.  But if not, let developers loose and unseal them.

I've looked this up twice now so I'm posting it to my blog for future reference and as a quick-tip for others. Say you got a web page with a dropdown/select listbox and you want to reload/auto postback the page when the selection changes.

One way to do this without involving a Javascript or Ajax library like jQuery (which probably is a good idea anyway :) is to use the "htmlAttributes" parameter of the Html.DropDownList() helper method and add a "onchange" attribute through an anonymous type. Something like this:

    Select a name: <%=Html.DropDownList("Name", ViewData.Model, 
new { onchange = "doSomeJavascript()" })%>

To submit a form, for example:

    <% using (Html.Form<HomeController>(p => p.DropDown(), 
        FormMethod.Post, new { id = "myform" }))
       {%>
    Select a name: <%=Html.DropDownList("Name", ViewData.Model, 
        new { onchange = "document.getElementById('myform').submit()" })%>
    <%  } %>

The minimal DropDown() method of the HomeController class to support this sample looks like this:

public object DropDown()
{
    var list = new List<string> { "Adam", "Bob", "Charlie" };
    return View(new SelectList(list, Request["Name"] ?? list.First()));
}

As you can see, the htmlAttributes parameter is available on many of the Html-helper methods and I'm using ot to add a name attribute to the HTML form as well.

End Note About Basic Knowledge of Javascript and Html

Heh, ASP.NET MVC sure forces you to dust off that old, basic knowledge of HTML and Javascript that I think every web developer should have but the ASP.NET programming model has made us forgot... One could argue that it's niggy gritty stuff that we shouldn't have to worry about, but for me it feels good to know I'm in full control of the generated HTML and I'm not sending one byte more on the wire than what's needed. Yes, it's possible to have the same control with standard ASP.NET applications and controls, but I've seen experienced developers make mistakes around this more than once. ViewState anyone? :D

Someone commented on an earlier blog post I did on REST, POX/POJO and WCF and the comment read:

How about REST WCF bits from .NET 3.5 SP1? Is it possible now to let the user decide in which format he wants the response (xml or json) like MySpace API for example?

The convention is to use a file like extension at the end of the resource to specify data return type (.xml or .json)

api.myspace.com/.../details.xml

api.myspace.com/.../details.json

UPDATE/EDIT: Turns out I was doing this the hard way as there is support for json serialization right from the ServiceContract which makes this extremely easy. Just make sure to specify the ResponseFormat to be json. In a previous "version" of this blog post, I used the JavaScriptSerializer class, which is... dumb :)

First go take a look at the sample that Kirk Evans had on his blog.

Note that it may be easier to create a RESTful interface with ASP.NET MVC if you're into that tech, but that's another blog post.

So, first I'm modifying the REST interface somewhat, adding support for /details.xml and /details.json URI:

[ServiceContract]
public interface IService
{
    [OperationContract]
    [WebGet(UriTemplate="customers/{id}/details.xml")]
    Customer GetCustomer(string id);

    [OperationContract]
    [WebGet(UriTemplate = "customers/{id}/details.json", 
            ResponseFormat=WebMessageFormat.Json)]
    Customer GetJsonCustomer(string id);
}

As you can see, on the GetJsonCustomer() method, I'm specifying the ResponseFormat to be json. That's it :)

A sample implementation for this interface looks like this:

public Customer GetCustomer(string id)
{
    return new Customer { ID = id, Name = "Demo User" };
}

public Customer GetJsonCustomer(string id)
{
    return GetCustomer(id);

}

Using Fiddler to simulate client request and see what comes out of our RESTful service, we get this result from the /customers/123/details.xml request:

  <Customer xmlns="http://schemas.datacontract.org/2004/07/RESTfulWCF" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><ID>1</ID><Name>Demo User</Name></Customer>

...and this from the /customers/123/details.json request:

  {"ID":"123","Name":"Demo User"}

I had a laugh when I saw James Kovacs' blog post abot Why Developers are Interested in REST:

I'm doing some WCF work for a client, specifically around WS-Security. I stumbled upon the System.ServiceModel.MessageSecurityVersion class today. Its static properties alone should explain why developers are craving simpler technologies like REST...

• WSSecurity10WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10
• WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10
• WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12
• WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10
• WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11
• WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10

I think he's got a point there actually. Web services with WCF can be very easy to use, and it can be so very complex it'll get your head to spin. The REST and POX/POCO style of services is definitely getting more attention, even from within Microsoft. WCF now supports RESTful interfaces, and we've seen REST-related demos by well known Microsoft presenters several times now, especially around WCF, EF and Astoria/ADO.NET Data Service. Also, it's very easy to create a RESTful service with ASP.NET MVC. We saw several REST-related presentations at Mix07 and Mix08 and I'm sure there will be a lot of REST/POCO/POX/Atom demos at PDC later this year.

Ofcourse there will be a number of situations and type of applications which require a more complex protocol than what REST can offer, but as a developer and software architect who prefers simple solutions, I just love the simplicity of it all. Or maybe I'm just old and smilingly recognize old techniques coming back again - we did XML on (S)HTTP with ASP years and years ago, didn't we? And it worked pretty darn well I can tell you ;)

The "REST effect" is perhaps the result of the WS-* race, which in my opinion exceeded the speed limit a long time ago. It's just impossible for an average human beings to keep up with it unless you want to become a WCF/WS expert and do nothing much else, which is not an option for me. I know, there are people out there, like my colleague Eric, who groks it all, but he's not human ;)

Version 2.0 of SyncToy has been released on MSDN Downloads. SyncToy does not replace FolderShare for syncing files between different computers, but is a more effective way to copy/move/sync files on your computer. The dev-team uses the tool primarily to move pictures and music from devices (cameras, mp3 players etc) to folders on their computers or network shares in a more effective way. It's not a service/system tray kind of thing, just a utility that remembers a number of different "syncs" you've setup so that you can run them again and again when you need to.

The download page says:

SyncToy, a free PowerToy for Microsoft Windows, is an easy to use, highly customizable program that helps users to do the heavy lifting involved with the copying, moving, and synchronization of different directories. Most common operations can be performed with just a few clicks of the mouse, and additional customization is available without additional complexity. SyncToy can manage multiple sets of folders at the same time; it can combine files from two folders in one case, and mimic renames and deletes in another case. Unlike other applications, SyncToy actually keeps track of renames to files and will make sure those changes get carried over to the synchronized folder.

The tool has got a number of new features added from version 1.0, and I'm listing a few interesting ones:

• Dynamic Drive Letter Assignment
• True Folder Sync
• Exclusion Filtering Based on Name
• Filtering Based on File Attributes
• Command line enhancements: Added the ability to manage folder pairs via the command line interface.
• Sync Encrypted Files
• 64-Bit Support

SyncToy is built upon the Microsoft Sync Framework, which seems to get better and better all the time. Worth keeping an eye on for everyone involved in developing applications which requires replication or off-line modes.

This video has been around for a few months now, but it's still cool. It's not one of Bill's better demos as he's kind of standing in the way of the screen all the time, but it still shows off the Touch Wall/Surface capabilities pretty well. I'm sure we'll see something like this in class rooms and larger meeting rooms in the future. It's easy to learn to use, but the presenter will have to learn how move on the podium as well as work with the presentation and give the talk. Interesting... what do you think?

The video sequence is from the Microsoft CEO Summit 2008.