to FBML or not to FBML

if you've looked into developing for Facebook, you've hopefully recognized that your first big design decision involves the choice between an iframe style app, and a Facebook Markup Language (FBML) style app. many pros and cons for either can be found in the Facebook documentation and around the net, no need to regurgitate them in depth here.

however, i was a little concerned over the lack of guidance on this topic out there in the vast tube pile, both from Facebook and otherwise. for example, i didn't see many "this is what i need to do, this is what i tried, this is what worked and what didn't" type articles.

well, i'm still new to everything, but i did commit to creating an FBML app. and i figured i'd share some brief points on why i eventually made that choice.

first, the only reasons i considered iframe in the first place was 1) the obvious, that is, low learning curve and ease of porting, and 2) my prototype app is using a slick slider control built on top of the Asp.Net Ajax Toolkit Slider Extension control. in fact, the slider control was kind of a show stopper at first. it makes my app very ergonomic and i've become attached to it, but it uses a lot of javascript, and that doesn't really fly well in the FBML model.

but then it occurred to me: while my slider is slick and works well, so are all the Facebook controls i'll have access to with FBML. weighing the options, i'll spend a lot less time retooling my slider for FBML than i would reinventing all the functionality available with FBML. more importantly, Facebook will surely extend FBML going forward and who knows what else i'll have access to down the road as FBML feels more functionality demand.

and then i saw a headline that Facebook will be rolling out overall site design changes soon and it kinda sealed the deal for me. i'm never in the mood to hand mod CSS and image files and to unjumble html according to some whim.

so it goes like this, man up and learn FBML because:

• Easy integration with the FB user experience
  
  
• Easy integration with the FB aesthetic
  
  
• Performance. Performance. Performance. FB includes a caching scheme with FBML, so why spend ur own money on extra bytes and cycles when FB is willing to?
  
  
• The learning curve on FBML is minimal, you can do it, i beleive in you!
  
  
• Automatic exposure to any upgrades FB makes to FBML, upgrades they will surely make

debugging facebook fbml Asp.net apps locally with Visual Studio 2005

the title is a bit of a mouthful, but that's the best i could put it. i've been planning the port of my prototype app, Like a Candidate, to Facebook for the last couple days and, naturally, debugging my app as it's called from Facebook was one of my early concerns.

but before i get to the solution, i should explain that i specifically included "fbml" in the title of this post because my solution might not be so involved were i developing an iframe app. i previously posted a little on why i chose the FBML route if you're interested.

my solution is based on Jerome Paradis' equaled wordy titled post Debugging an ASP.Net FBML Facebook Application using Visual Studio 2005. with a few differences tho. for example, he's using Facebook.Net and for the moment i'm using the Facebook Developer Toolkit. for more on your options as a .Net developer, check out this Facebook wiki. i'm actually eyeing fbasync at the moment as well ... so when i make my mind up, i'll be sure to post.

regardless of what utility api you chose, if any at all, these steps should still apply as long as your going with FBML, which you should :)

also, a word on my setup: i'm using an HP pavilion laptop, running Microsoft Windows Vista Ultimate and Kaspersky Internet Security 6, developing with Visual Studio .Net 2005.

so without further adieu:

1. get your developer and app configured on Facebook. many helpful posts on this, but start here if you need. just make sure you select "Use FBML" under the "Canvas Page URL" settings.
   
   
2. when you configred your app on Facebook you were asked to specify a few different URLs. if you understand the purpose of these URLs then you might also understand that "localhost" can't be used if your using FBML (whereas localhost is perfectly fine for iframe apps). this is because when using FBML, calls to your app will cause Facebook to call your URLs and parse the results "behind the scene" before returning to the results to the user.
   
   so, when using FBML you must specify URLs that can be resolved from Facebook. so your first problem in debugging apps is: how do i give Facebook a URL that resolves back to my development machine that's behind a firewall and is issued dynamic IPs?
   
   the easiest way to do this, IMO, is to start with a dynamic DNS service. I went with DynDNS, it's easy to register and configure, and it's free. so register with them and configure a host, something like: myfacebookapp.dyndns.org and point it at the IP address of your primary interface to the Internet. in my case, a Netgear wireless router. if you're still unsure, use the IP address displayed for you from whatismyip.com.
   
   
3. Assuming you're using a router, first configure your router for dynamic DNS. it'll ask for your username and password from DynDNS (or wherever) and that's a-ok. the point of doing this is that if for some reason you're issued a new IP from your ISP, your router will automatically update your dynamic DNS host to use the new IP.
   
   
4. Configure your router to forward port 80 traffic to your machine within your local area network. That is, configure your router to forward 80 traffic to the subnet IP of your development machine. your subnet IP is the one that comes up when running ipconfig from the Windows command prompt.
   
   
5. if you're using a firewall, now would be a good time to configure it to allow 80 traffic on your local machine. instead of opening your machine up wide for port 80, you might want to use an IP filter. Use the same IP from step 2 and use 204.15.23.0 with the subnet mask 255.255.255.0 which will allow your machine to receive requests from the Facebook servers.
   
   
6. now would also be a good time to setup a new Asp.Net project in Visual Studio. Jerome Paradis recommends using a Web Application Project. You can do this, but I just used the default project type (i forget what it's called, but it's the one that uses the local Cassini virtual server to run your code). Paradis points out that you can't forward traffic to this type of application, and he's correct. however, you can configure your local IIS to host as an Asp.Net web application from your Asp.Net project directory.
   
   to do this, open up your local IIS management UI (if you don't know how to do this, ur in the wrong place). Create a new website (or virtual folder if you prefere) and specify the host name you created in step 2 in your new site's header Host Header settings. This will cause IIS to forward requests for myfacebookapp.dyndns.org to your new site, and thus your Asp.Net code.
   
   
7. relax, you're basically done at this point. the only thing left is to set up a test page, call it from facebook, and see if you can attach your debugger to the request. so you set up your app already in facebook at this point, and you specified a URL for "Callback Url". if this callback URL looked like http://myfacebookapp.dyndns.org, then you want to add a page to your Asp.Net project called default.aspx that sits in the projects root directory (there's likely already one there).
   
   this page will be the one called by facebook. so get rid of all the markup in default.aspx, and just add "hello world". then in the code behind, add some nonsense code to the page_load handler. now browse to your page locally, as you normally would with any other Asp.Net project and make sure everything is working. next try browsing your page from IIS.
   
   once you're convinced everything is working so far, go to facebook and go to your new apps Canvas page URL. this should be something like http://apps.facebook.com/myfacebookapp. if the page comes up, you're good to go on to the next step. if not, you'll have to rely on those keen, extrasensory debugging skills they don't teach you in school :)
   
   
8. with everything else working, all you need to do is set a break point in your default page code-behind's page_load handler, then in Visual Studio, go to Debug -> Attach to Process.. -> find the approriate worker process (for me it was w3wp.exe, for you it may be inetinfo.exe, or may even be an instance of svchost.exe) -> Click Attach.
   
   
   

refreshing your canvas page from Facebook should now hit your breakpoint.

or at least, it works for me ... apologies for the lack of visual aids in this post, but hey it's better than nothin friends :)