I’ve officially launched the Facebook UI for ASP.NET project at CodePlex at http://facebookui.codeplex.com/. It’s kind of a preview edition of what’s to come – and there’s quite a bit. Here’s a quick overview:
- Design-time and run-time server support for about 30 FBML controls.
- Visual Studio IntelliSense support for FBML controls
- Web Site project templates in Visual Studio 2008
- All FBML tags within: Users/Groups, Profile-Specific, Embedded Media, Visibility on Profile, Tools, Forms, Message Attachments, Additional Permissions, Notifications and Requests, Status Messages, Page Navigation, Dialog, and Wall sections.
- Complete API support.
- Extensibility points within the FBML controls framework and API framework to enable updates from Facebook to be rolled in without requiring an immediate release of a new library.
- LINQ-to-FQL (or as some folks at the user group mentioned, perhaps it’ll be called LINQ-to-Facebook).
- Higher-level controls will be included, such as validators and simple logic controls, like a birthday display.
- Facebook internationalization should be supported.
- Mobile platform support should be extended.
Beyond that, I’m not sure where we’re going to take the project. We’ll have to see!
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.
I've officially released my property grid extension project, called "ShinyDesign," under the open-source BSD-like license. I blogged about this project just a few days ago, and I'm excited to be releasing it to the public domain.
In truth, there are some ugly hacks, and I'm sure I could have done a better job commenting on what I did. All told, the multiple-tab hack is probably the worst. The Windows Forms PropertyGrid does not allow you to directly add additional property tabs; rather, you add Type objects that represent the tabs. The good news is that there's a virtual method that allows you to create the tab given the Type. The bad news is that the PropertyGrid will block you from creating additional tabs of the same Type. The consequent solution is that, in the PropertyGridEx control, if additional tabs are used, I dynamically define an assembly and type for each PropertyTab being created. The type is a cleaned-up version of the tab name, and the closed types are cached (if the same property tab name is used on the same PropertyGridEx in the future). The types are then used to close a generic ExtensionPropertyTab<T> class, and the type parameter is then ignored from there. Oh, the things we do!
The ShinyDesign documentation is available on the web as well as a direct download. The code is also available from my website, and details for accessing it through Subversion are also provided.
Hopefully, people find it easy to use - simply drop the PropertyGridEx control onto your form, decorate your object with a few additional attributes, and you're set. Using the PropertyGridEx is just about as painless as a run-of-the-mill PropertyGrid.
If for some reason you are unable to change a PropertyGrid out, you can use the ShinyDesign.Design.TypeDescriptorSurrogate class. It gives you *almost* all of the benefits of the PropertyGridEx class - the key difference being that multiple property tabs are not available in this situation. You wrap the object being inspected in a new instance of TypeDescriptorSurrogate, and assign the surrogate object as the SelectedObject of the property grid. The actual object is updated, just as if you were working with the PropertyGridEx.
If you plan on using this in applications, I'd appreciate a nod, or at least an e-mail letting me know that you're using it and whether you found it helpful. The license terms stipulate that my copyright notice must appear in source code redistributions, but not in binary redistributions, with the exception of the disclaimer of warranties (which must be included in all forms in some way). Also, if you come across a bug, please drop me an e-mail so I can roll the fix into the main source tree.
Now that it's out, I'm not sure how much extra time I'll be putting into it, but I know that there are some updates I'd like to make to it, including the ability to inspect fields, methods, and events. If possible, I'd like the ability to as closely mirror Hawkeye as possible, except that I don't really care to write the code to inject into other processes. (This is where the multiple-property-tab idea came from in the first place). But at the end of the day, I see the most use in this coming out of people who want to use it for their user configuration screens - that's why I built it in the first place.