On March 10th, I’ll be presenting an ASP.NET control library for Facebook at the Phoenix ASP.NET Users Group. Among other things, we’ll be talking about how to create a Facebook application using ASP.NET, debugging aids, and the Facebook API. Along with that, Terralever will be releasing our library to the open-source community on Codeplex. (This post will be updated once we’ve done so).
The library is currently in varying degrees of maturity. We’ve got about half of the FBML controls supported in the library with full design-time support:
If you haven’t worked with Facebook before, aside from having design-time support, the best part about having Facebook controls with runat=”server” on them is that you have full access to them in codebehind. Because of the way Facebook controls are accessed (using the XML fb: prefix), we couldn’t do that before without causing exceptions because ASP.NET would try to access them. That generally led us to using ugly ASP.NET databinding syntax:
<fb:name usereflexive=”true” useyou=”true” capitalize=”true” uid=’<%# Eval(“FbUserID”) %>’ />
We still have the ability to use this type of syntax, but we have the flexibility to do specific databinding (for instance, within a repeater control), accessing that control within a type-safe way.
There are a few big differences, though. Facebook has this concept of a meta-control called fb:else; it’s used in conjunction with several other controls (such as the one shown in the screenshot above). But that’s DEFINITELY not supported in the ASP.NET code editor, and it’s fairly irregular for an ASP.NET application. Fortunately, we already have a way around that problem, templates:
By using designer templates we’re able to provide that metadata to the editor. (More on that before too long).
For the release in early March following the user group presentation, we’ll release a subset of the FBML user controls (the Terralever.Facebook.UI.FbmlControls namespace) to the community, as well as some base-level utility classes, such as base classes for Canvas- and IFrame-based pages. Hopefully, there will also be a preview of LINQ-to-FQL, although that’s not necessarily going to happen. Debugging aids, including specialized and extended tracing HTTP modules, will be part of the release. We’ll also include a couple controls we’ve had to model, including a Pager control, a Birthday List control, and a control template for hosting on user profile boxes.
Additional FBML controls will be added as time goes on, but the second biggest release is going to be adding support to the Terralever.Facebook.UI.CanvasControls namespace. Just like the System.Web.UI.WebControls namespace is to the System.Web.UI.HtmlControls namespace, .CanvasControls is to .FbmlControls. It provides support for some of the higher-level functionality that we’ve come to expect from ASP.NET. If you’ve tried to use the normal validation controls on a Facebook Canvas page, you’ve known the bitter defeat of it. I’m not so sure it’ll get to some of the more data-centric controls we’ve come to know and love, like DataGridView (because let’s be honest – it just doesn’t fit into a Facebook page). But we’ll see some support for postbacks (on that note, Microsoft, ClientScriptManager shouldn’t be sealed and Page.ClientScript should be virtual), all the regular validator controls, and some Facebook-friendly client UI controls.
We’ll include much greater support for the Facebook REST-based API. I haven’t decided yet whether we’ll consume them as WCF services or simply use an XML parsing strategy, such as LINQ-to-XML. It it isn’t already included, we’ll definitely include a LINQ-to-FQL implementation.
Long-term (version 2 and beyond) will most likely add support for the Facebook internationalization platform, the Editor control, and the Mobile platform. We’ll see how it goes and what is requested by the community.