This presented a couple of problems because, similar to an issue touched on in my last clog, the widgets needed to be inserted dynamically and that’s usually easier said than done. After a little bit of digging into how the widgets function, I was able to make them seemingly load normally on-the-fly.

Dynamic Facebook Share Button

Facebook share buttons are created in a couple of pieces. I started with the default widget code supplied by Facebook:

<a type="button_count" name="fb_share"
  href="http://www.facebook.com/sharer.php">Share</a>
<script src="http://static.ak.fbcdn.net/connect.php/js/FB.Share" type="text/javascript"></script>

Understanding how to make this work dynamically first means understanding what exactly this code does. The <a> tag is clearly a link to Facebook’s share service where users can submit our page. The <script> tag loads a JavaScript object named FB.Share.

Failed Insertion

If you were to try inserting these bits of code dynamically, you’d discover in no time flat that it just won’t work. For example, this might look like a good idea, but it’s useless:

$("#somediv").append('<a type="button_count" name="fb_share" '+
  'href="http://www.facebook.com/sharer.php">Share</a>');
$("#somediv").append('<script src="http://static.ak.fbcdn.net/connect.php/js/FB.Share" '+
  'type="text/javascript"></script>');

And you may even try it a little more manually by directly modifying the DOM:

a = document.createElement('a');
a.type='button_count';
a.name='fb_share';
a.href='http://www.facebook.com/sharer.php';
a.innerHTML = 'Share';
document.getElementById('somediv').appendChild(a);

s = document.createElement('script');
s.type='text/javascript';
s.src='http://static.ak.fbcdn.net/connect.php/js/FB.Share';
document.getElementById('somediv').appendChild(s);

But you’ll be disappointed by the results. A working solution required a little more digging.

Successful Buttonization

I opened Facebook’s JavaScript file and started sniffing around. Their code is designed to initialize all buttons on the page just once, which makes perfect sense. So the solution is to add the <a> tag as per the above but then manually force FB.Share to re-execute, thus turning our dynamically added link into a button. The required function call is rather simple:

if (typeof(FB.Share) != 'undefined') {// make sure it exists
  // FB.Share.onFirst();
  // *** UPDATE: 17 Aug 2011 - Thanks to zr0ck who informed
  // FB has modified their Share script ***
  // FB.Share.onFirst() no longer exists; you must now instead call:
  FB.Share.renderPass();
}

Just execute that after you’ve inserted your <a> link and it’ll become a pretty Facebook button.

Multiple Buttons Per Page

The above solution works splendidly, assuming that you use it on a URL specific to the content you’re sharing because FB.Share will by default use the address of the current page when adding to the user’s wall. However, if you are on a listing page where there are multiple content posts and the URL is not specific to any one of them (e.g., http://videosift.com), then every dynamic button you add will reference the same address.

Facebook provides a straightforward method for you to specify an alternate URL than the current one, which is to add a u variable to the query string of the link:

<a type="button_count" name="fb_share"
  href="http://www.facebook.com/sharer.php?u=SOMEURL">

However that method doesn’t work with our dynamic buttonizing for whatever reason. A little more sniffing through the FB.Share code reveals exactly how it determines what URL to use:

FB.Share {
//...
getUrl:function(a){return a.getAttribute('share_url')||window.location.href;}
//...
}

Aha- it checks for an attribute named share_url. So all we have to do is add that attribute to our link et voila, we’re in business!

<a type="button_count" name="fb_share"
  href="http://www.facebook.com/sharer.php" share_url="SOMEURL">

Dynamic Tweetmeme Retweet Button

Fortunately, the retweet button was much less involved than the FB share button, but also require just a little bit of digging. As described on tweetmeme’s widget page, the following is the code you’d typically want to use on a web page:

<script type="text/javascript">
tweetmeme_url = 'http://yoururl.com';
</script>
<script type="text/javascript" src="http://tweetmeme.com/i/scripts/button.js"></script>

As with the FB widget, attempting to insert this code into the DOM on-the-fly just results in failure. (I’ll spare you the sample broken code.) So I cracked open the button’s js code and investigated how it worked.

It turns out tweetmeme doesn’t use a lot of JS tomfoolery to make their widgets work. Instead, they insert a simple <iframe> and allow that to do all work, which makes it easy for us because all we have to do is insert the same type of iframe and we’re in business. So we did something like the following and it worked like a charm:

$("#somediv").append('<iframe frameborder="0" scrolling="no" height="61" width="50"
  src="http://api.tweetmeme.com/button.js?url='+SOMEURL+'"></iframe>');

Enjoy!

Overview

At VideoSift we have always made available the embed code for every video on the site. Until now, the provided code has just been the raw <object> and <embed> tags as you would acquire directly from the video host, but we wanted to provide a much more attractive embed.

We opted to achieve such a thing by providing users with a <script> tag that builds the fancy new widget into the DOM of the host page. Initially, the plan was to just generate a pretty simple DOM structure wrapped around a video, but it evolved from there to include:

• the ability to optionally start out as a thumbnail image that when clicked will expand into the full widget
• a functional vote button that would remotely cast an up-vote for logged in members
• a brief, scrollable listing of comments on the video

There were a few interesting issues that needed to be resolved along the way:

• Where on the host page should the widget be inserted?
• What happens if the host page contains multiple widget <script> tags?
• How should we dynamically load the widget in comments on VideoSift?
• How should we cast votes on remote host pages that need to be posted to VideoSift?

Inserting the Widget

When it came to inserting the widget into the DOM of the host page, the desired location was obvious: immediately adjacent to the <script> tag itself. Really the only issue was to locate the appropriate <script> tag.

We start by searching for the target node in the DOM tree for all nodes with tagName ‘script’ and examine their “src” attribute:

function createWidgetDiv() {
  scripts = document.getElementsByTagName('script');
  for (i=0; i < scripts.length; ++i) {
    if (/videosift\.com\/widget\.js\?.*video=123456(&|$)/.test(scripts[i].src)) {
      widgetdiv = document.createElement('div');
      scripts[i].parentNode.insertBefore(widgetdiv, scripts[i].nextSibling);
      break;
    }
  }

// now we can start inserting our widget contents into widgetdiv
}

Name Collision

At this point we discover another issue. How are we sure this <script> tag belongs to the widget that’s currently executing? The user could have inserted onto the host page two <script> embeds. We handle the issue of there being two different embeds on the same page by checking if the <script> src URL contains the video ID that we’re currently executing with. We do not, however, handle the situation where a user inserts two embeds for the exact same video ID. In that case, both the first and the second widget will insert themselves after the first <script> tag because it’s the first one encountered in the DOM tree.

This brings us to the related issue of variable and function name collisions shared by multiple embedded scripts. With just a single widget on the page, we wouldn’t have to worry about naming convention, but let’s say we have two widgets with video IDs 111 and 222 both on the same host page. When the widget for 111 executes, everything will be fine, but when 222 executes, it will define a new createWidgetDiv(). If after that happens 111 calls createWidgetDiv() again, it will then be calling that defined by 222.

One way to fix this is to define the functions with a video ID specific suffix, e.g., createWidgetDiv_111() and createWidgetDiv_222(). This is not ideal, however, because considering again the situation where the host page contains two widgets with the same video ID, there will again be overlap. So, I opted to append a random number to every important function and variable name like createWidgetDiv_3948717().

Dynamic <script> Loading

So far, so good. At this point a page can load with any number of widgets already embedded in the HTML, but uh oh- what happens if we try to insert a <script> tag into a page that’s already been loaded? When we decided to modify VideoSift comment listings to allow just our special <script> tag, we needed to adjust how we loaded it. Here’s a very simple example trying to insert a <script> tag with jQuery:

$("#some_div").html('<script type="text/javascript"
  src="http://videosift.com/widget.js?video=111"></script>');

This won’t work because the <script> tags won’t be parsed. (This is not just jQuery-specific.) The fix, unfortunately, is not an issue that can be dealt with in the widget itself, but by the host page that is loading the script. Rather than attempting to insert a script tag, you’ll have to manually manipulate the DOM to insert a node with tagName ‘script’. You could use a function along these lines:

function dynScript(src) {
  script = document.createElement('script');
  script.type = 'text/javascript';
  script.src = src;
  return script;
}

// insert it somewhere
$("#some_div").append(dynScript('http://videosift.com/widget.js?video=111'));

Cross-Domain Scripting and XMLHttpRequest

The final piece of the puzzle was getting the vote button to function when the widget is hosted on a remote domain. For security, XMLHttpRequest/Ajax requests are disallowed from communicating with scripts on foreign websites.

We clearly want to allow VideoSift users to cast votes for videos embedded on external sites, so we used a common workaround for the cross-domain restriction and inserted a dynamic script tag into the DOM specifying the vote URL as the <script> src attribute.

If that sounds familiar, yep, you guessed it. We reuse the dynScript() function for this purpose and it works splendidly. For example, we can do something like this:

$("#vote_btn").click(function(){
  // normally we'd make an Ajax request here, but not this time
  $(body).append(dynScript('http://videosift.com/widget_vote.js?video=111'));
  return false;
});

And the loaded script can take care of the post-processing for the host page that would normally happen in the Ajax callback. For example:

if (voting_failed)
  alert('Could not cast your vote!');
else
  updateVoteButton();

In Conclusion

Well, that’s it for my very first clog post. I hope most of what I wrote up there isn’t too vague to be appreciated by anyone who might be looking for some guidance or answers. My intent was to provide in broad strokes a breakdown of the wrinkles encountered on this project and how they were ironed out.

Here is an example of the widget in action.

The embed code for this widget follows:

<script type="text/javascript"
  src="http://videosift.com/widget.js?video=170447&width=540&comments=15&minimized=1"></script>