Friday, November 30, 2007

Not exactly mainstream ASP.NET

Here are some interesting ASP.NET links I collected in the past two months. They're all really clever - the best alternative I can think of in place of hacky - and, so really cool, I've been dying to put them to use somewhere in a project at work. Thank God my busy schedule has kept me from doing just that. These solutions aren't exactly mainstream...

Monday, November 26, 2007

Behind the scenes with Facebook Beacon's JavaScript

Facebook Beacon allows you to publish user actions from your website in Facebook.

So, for example, Facebook Beacon allows publishers like Amazon to publish a story in your Facebook profile and your friend's news feeds whenever you add an item to your Amazon wishlist. This could e very useful. But, what if, for example, Amazon decides to publish your purchases too? As you may expect, there's now an uproar among privacy advocates, complete with an online petition. Facebook claims the opt-out is easy, but.

A short summary about what happens behind the scenes when you include Facebook Beacon's JavaScript to publish your custom action, from the helpful post, Deconstructing Facebook Beacon JavaScript (read it for more information):

  1. The partner site page includes the beacon.js file, sets a <meta> tag with a name, and then calls Facebook.publish_action.

  2. Facebook.publish_action builds a query_params object and then passes it to Facebook._send_request.

  3. Facebook._send_request dynamically generates an <iframe> which loads the URL http://www.facebook.com/beacon/auth_iframe.php and passes the query_params. At this point, Facebook now knows about the news feed item whether you choose to publish it or not.

  4. The <iframe> loads a facebook_helper.html file, which lives on the partner site, and which contains a call to Facebook.process_message_from_helper.

  5. Facebook.process_message_from_helper parses a call to Facebook._perform_action from its own query_string and calls it.

  6. Facebook._perform_action dynamically creates the [publish permission pop-up] and displays it in the bottom right corner of the window.

  7. The user is given the choice [to opt-out], which will cause the item not to appear in their news feed.

Friday, November 16, 2007

Free Facebook application hosting on Joyent

Earlier this week, Joyent Accelerators for Facebook Developers was announced on Facebook's developer site.

The offer includes one year free hosting of up to 10gb in storage and comes with PHP, Rails, and Python (and perhaps Java too). After the one year, or if your application needs to start scaling sooner for more users, Joyent will help you move to one of its standard hosting packages. Sweet. I'm keeping my fingers crossed for similar partnerships to offer free hosting for ASP.NET applications.

Previously:
My static-hosted FBJS-driven Facebook application
Hosting for your .NET Facebook application

Thursday, November 15, 2007

Using unobtrusive JavaScripts to extend an ASP.NET product

I previously blogged about using JavaScript to extend the functionality of a closed source ASP.NET product. Now, using similar client-side methods, we're also rolling out bugfixes. This post is about how we used unobtrusive JavaScripts to make the process easier.

The story so far: after falling out with our partner, we've stopped receiving support for a module we sold as part of our solution. We've got access to the ASPX files but not the C# code-behind or business classes. So, we went with JavaScript hacking to dynamically generate iframe containers for our new file upload functionality. Sometime last week, we successfully deployed the customization. The customer has since logged several presentation layer bugs that we now needed to fix e.g. figures not adding up correctly etc.

Although we're able to change markup within the ASPX files, we were careful to introduce changes unobtrusively (in the conventional sense, as applied to JavaScript code, and also by principal in regards to the existing module, so we won't in any way risk breaking an application that's running live). I found rules like the seven in Chris Heilmann's recent post (read also the article) provided for very good best practice guidelines towards our goal.

Area of Impact
Firstly, we minimized change to the existing code base by consolidating all changes into a single JavaScript file, customization.js, which is then loaded dynamically by every webpage in the application.

Assumptions
We started development with assumptions based on existing project requirements i.e. Internet Explorer is the only targeted implementation browser, and JavaScript is required etc. So, we didn't need to worry about non-standard input devices and browsers other than a JScript-enabled IE. This really helped.

Hooks and Relationships
One of the bugfixes required me to retrieve numbers from Label controls in each row of a databound GridView, total them, and display the result in a TextBox control. Upon inspection of the ASP.NET generated HTML, I noticed that the resulting Label control ClientIDs looked like grdMain__ctl3_lblAmount, grdMain__ctl4_lblAmount etc. The TextBox was simpler to access, straight up by its ID. I wrote the DoSum() method to hook onto the HTML elements by searching for spans ids that matched the pattern.


var Customization = {
...
DoSum: function() {
var total = 0;
if(document.getElementById &&
document.getElementsByTagName) {

var labels =
document.getElementsByTagName("span");

var totalTextField =
document.getElementById("txtTotal");

if(labels && totalArea) {
for(var i in labels) {

// Check if the span has an id
// Check if the span's id matches
// Check if the span's text is a number
if(labels[i].id &&
labels[i].id.indexOf("lblAmount")>0 &&
!isNaN(labels[i].innerText)) {

total += parseFloat(labels[i].innerText);
}
}

// write to the text field
totalTextField.value = total;
}
}
}
...
}
...
(function(){
...
Customization.DoSum();
})();


One other enhancement required us to change a form TextField into a DropDownList. I used methods similar to the above to find the TextFields and then, appended a select element to the innerHTML property of the TextField's parent node, and changed the display style property of the TextField to "none". The drop-down list's onchange event handler then updates the invisible TextField accordingly. The possibilities for what you can do are endless, and with unobtrusive JavaScripts patterns, they're a lot more manageable.

Future Development and Maintenance
Concerning further development, we made sure our code is readable, unambiguous and complete with concise comments so we could work with it easily in the future. We encapsulated our code into objects, namespaces and anonymous functions to avoid naming conflicts with both existing and future code.

This also hid the details of our implementation code from the outside world, though in reality, being the sole vendors in this case we didn't have to worry about third party developers.

More reading on unobtrusive JavaScript:
Behavioural Separation, and
The Behavioural Layer: Using JavaScript for Good, not Evil (both by Jeremy Keith)

Wednesday, November 14, 2007

OpenSocial application container for Facebook

Today, I stumbled onto a rather interesting project called OpenSocket, which is a Facebook application that provides a hosting container for OpenSocial apps. It's described as "a bit like running a DOS command prompt within Windows". I suppose this means we can now write OpenSocial applications that (pending approval from the OpenSocket guys) will be accessible from inside Facebook.

More on OpenSocket:
OpenSocket (official website)
Open Socket Facebook application about page

Sunday, November 4, 2007

Challenges with Google's OpenSocial API

With the first OpenSocial exploits already being published, I thought I better dived in. I read through Dare's helpful technical overview and critique of the API, which saved me the trouble of going through the documentation just to find out what you get (and don't get) with OpenSocial. He's even followed it up with a 5 -sentence summary, go to the link.

From the main article, he points out what most people seem to miss out, that Google's JavaScript API is not as open as its name suggests.

Google has announced a technology platform that is every bit as proprietary as Facebook's. The only difference is that they've cut deals with some companies to utilize their proprietary platform while Facebook's platform is only for use on the Facebook site.

Despite the ability to use OpenSocial on many social sites, which is as open as this version of the API gets, it doesn't take us any closer to a truly portable friends list. To be fair, maybe this was never a goal, though this would probably be the one thing that everyone expects from OpenSocial.

Besides this, Dare offers 3 reasons why he prefers Facebook's platform over OpenSocial:

  • There is no alternative to the deep integration into the Web site's user experience that is facilitated with FBML.

  • I prefer idiomatic XML to tunnelling data through Atom feeds in ways that [in my opinion] add unnecessary cruft.

  • The Facebook APIs encourage developers to build social and item relationship graphs within their application while the OpenSocial seems only concerned with developers stuffing data in key/value pairs.

More reactions to OpenSocial in Facebook's dev forums. With all the noise on the web, I wonder where Google will take the API next.

Friday, November 2, 2007

Nikhil talks about Facebook.NET on .NET Rocks!

I'm currently listening to the latest .NET Rocks! show which has Nikhil Kotari talking about Facebook.NET amongst other things.