In today’s first episode of Dev Ideas, I delve into the Haxe programming language. Haxe’s main claim to fame is as a free open-source alternative to the Flash development environment, but it is really a multiplatform language and toolkit. In addition to Flash .swf files, Haxe can target JavaScript, NekoVM, PHP, or C++ source code, making it possible to use the same language for all phases of a project. Haxe also gives you access to advanced language features like closures, type inference, and algebraic types. Come join me as I give a quick (23 minute) overview of what makes Haxe interesting and worth learning.

Watch the presentation now

Why not head over there now and check it out?

Chicken Wing Software's Open Source Projects

There were some features that I wanted added and some bugs that needed fixing, but there did not seem to be much activity on the original app's message board (at least the English language version), so I decided to make the changes myself.

I took the "MAXI" version of the player, and added in some more JavaScript support, improved some performance issues, and fixed a couple bugs.

Here is what I changed:

• Fixed some bugs with the slider control.
• Added to the JavaScript interface the following functions:
  • playVideo
  • pauseVideo
  • getVolume - Gets the volume as a percentage.
  • setVolume - Sets the volume as a percentage.
  • getCurrentTime - Gets the current time in seconds.
  • setCurrentTime - Seeks: takes a new time in seconds
  • isSeeking - Returns true or false
  • isPaused - Returns true or false
  • getDuration - Gets the video length in seconds
• In the flashVars, you can set a percentage width or height by appending a percent sign to the value. If you set just width percentage and don't set height, the height will be automatically calculated to keep the aspect ratio. Be sure to escape the percent sign as %25. Something like: width=50%25
• Made seeking more efficient when using phpStream. Now doesn't
  initiate a new connection to the server unless necessary.

Download the player

Download the source code

Here's the original documentation as well as an HTML code generator.

If you have any issues or feature requests, feel free to contact me. Enjoy!

I am excited to announce Chicken Wing Software's online multimedia presentation system. The pilot presentation, created by Christine Perfetti of Perfetti Media, is online now. Facilitating a Usability Test is the first in what will be a series of presentations on usability testing techniques gleaned from her ten-plus years of experience in the field.

The system combines video with PowerPoint slides and text, all tied together with Dynamic HTML and JavaScript for a fully interactive experience. You can click on a slide thumbnail to advance the video to that spot in the presentation, and the displayed slide stays in synch with the video.

Even now, with only the first presentation, the system's potential is inspiring, and we are brimming with ideas for new features to add!

If you would be interested in using this technology for your own presentations, please contact us.

» Watch the presentation.

In my fantasy football and baseball leagues, we wanted to do a live draft, but we have players who live on both coasts, who work varying schedules, and some of whom have kids. Plus one of our rules is we allow keeping two to four players from year to year, to give some continuity.

Because of those two factors, it's impossible for us to use Yahoo!'s live draft or autodraft. So what does your trusty software engineer do? He codes up his own draft application, of course!

It's worked well for us for the last few years, so I thought I'd clean up the interface a bit and open it up to you, the public. It's free and has no ads or anything. Hopefully if you're in a similar situation as us, you will find it useful. It's still undergoing some updates, so if you find anything that doesn't work or you have any ideas on how to improve it, please let me know.

Technical details: This is written in Python using the Django framework running on my own lightweight single-threaded web server I wrote in C++. The front end is dynamic HTML and JavaScript, using the web technologies of AJAX and Comet.

Here is a link: Eddie's Fantasy Draught

Features

• Revolutionary three-tiered queue, to keep the draft moving. If you know you're not going to be around on your turn, you can set it up to draft some players automatically. The three tiers make sure you get only the players you want.
• Draft a large league on your own timeframe.
• Chat while the draft is going on.
• All stats available.
• League manager can enter "keepers" for each team before the draft.

To Get Started

1. Create an account.
2. Create a league.
3. Invite your league members to come draft.

Enjoy!

As of version 0.6, click here for the new home of PayPal on Python.

Thanks!

It's still in its early stages, but gameplay is working. You can log in with a Yahoo, MySpace, or Hotmail account, or your email address (Facebook support coming soon).

Since it's brand new, there may not be anybody to play against right away, so you may have to check back, or better yet invite a friend, if there is nobody there. Soon enough there will be artificial intelligence support to fill in when necessary.

For the technically interested, the site is programmed in the Python programming language using the Django web framework, and hosted on a Slicehost server. The front end is pure JavaScript with no downloads or plugins required.

Give it a try if you get a chance, and please let me know if you find any
problems.
Thanks!

Since I'm using Django, I can piggyback on its useful authentication module. That's a nice start, but users still need to choose a username and password before they can use the site, not to mention filling out their name, email address, and date of birth. My goal is to lower the barriers to potential users - both psychologically and in terms of effort. Folks are hesitant to sign up for yet another login and password, and to go through a lengthy registration process

Enter OpenID. OpenID sounds like a very promising standard. Unfortunately, the standard promises more than the implementations deliver. Or rather, the standard doesn't quite promise what it seems to.

The idea is that our buddy "Frank the User," instead of having to create a new account on our site, can log in securely using his Google account, or his Yahoo! account, or any of a number of OpenID Providers. At our site, he enters a URL, gets redirected to the provider's site for authentication, then redirected back to our site, all nicely logged in.

Fine. The problem is we need more than just "logged in." After that whole dance of typing in yahoo.com, signing in to Yahoo!, then coming back, all we at the cient site have available to us is a randomly generated token and assurance from the provider site that the user is indeed logged in -- somewhere. We don't know that his name is Frank, we don't know he was born in 1962, we don't know his email address. In other words, we know nothing more than we did before the dance. On my Texas Hold'em site, as is the case on most sites, I need more. I need a way to identify the user to other users. Something like, oh, I don't know, a NAME? I'm shocked that not even the user's name is available from most OpenID providers.

The OpenID specification includes provisions for exchanging profile information. There is a long list of possible attributes. Unfortunately, none of these things are required, so each Provider can choose to share as much or as little as it wants. Google shares an email address, and nothing more. Yahoo! shares absolutely nothing. AOL has the potential to share a good set of information, but the user needs to individually enable each piece of data through a series of checkboxes.

What would be useful is if there were a defined minimum set of information, or even a way for the Client Site to request a certain set of information. And if that info is not available or the user does not want to share it, the login should fail.

Until that happens, OpenID is going to stay a nice idea with no real use in the real world.]]> http://www.chickenwingsw.com/scratches/programming/openid-is-useless/feed 0 http://www.chickenwingsw.com/scratches/python/django-facebook-3 http://www.chickenwingsw.com/scratches/python/django-facebook-3#comments Mon, 29 Sep 2008 21:17:57 +0000 Eddie Sullivan http://www.chickenwingsoftware.com/?p=61 Welcome to the third part in my series of posts about creating a Facebook application. I am using Django as my web development framework, and this post will focus on some of the backend techniques I have worked out to make this work easier. This is not a tutorial, but a set of tools that I have developed. This is a long post, with a lot of source code; I hope you find at least some of it useful.

Keep in mind as you read this that the Facebook platform is still very new, and likely to change. In fact, if you're a FB user, you are probably aware they recently completed a major transition to a new profile design. This included many changes behind the scenes for developers, some of which are still playing out. I recommend keeping up with the Facebook Platform Developer Forum and the Facebook Developer Blog.

Also, I will assume you have already read the API Documentation and the documentation for PyFacebook, and that you know how to create a web app using Django. If not, you will want to start there.

PyFacebook is very useful and includes some documentation on getting up and running with Django. You do still need an understanding of how Django works and how URLs are mapped.

My goal

My goal with these code snippets and techniques is to make developing a Facebook app as close as possible to developing a regular web app. The application I am using to develop and test these features is The Limerick Book. Compare that page to The Limerick Book Facebook App. In fact, they are the same application, sharing the same code. I also have developed a multiplayer card game based on the traditional Italian game Scopa. This is a Facebook-only application, but I wanted to be able to test it outside of Facebook.

Ideally, we would be able to write code and templates that can work equally well both inside Facebook and outside. This is important even if you want users to only see your application within Facebook, because it makes testing infinitely easier. You want to be able to test on your local machine before publishing content, and you want to be able to test things out free from the limitations and frequent bugginess of the Facebook platform.

First steps

Here are some simple helper functions to make life as a Facebook Python developer easier.

I am making a conscious decision here not to package all these helper functions into a downloadable library. My point here to explain code, rather than just hand it out. Many of these things are specific to my needs, and may not fit exactly what you want, so some tweaking may be required. I have most of these functions in a file called fbUtil.py that I import from most of my Django view code (except for the template tags, which need to be in a specific place, per Django). Feel free to do the same, or to copy and paste the code for your own use, but I recommend reading through the code, as your needs may not be the same as mine.

inFb is a simple function that takes a Request object and returns a boolean telling whether the request is taking place within the context of a Facebook canvas page.

def inFb(request):
    return (request.facebook and
            (request.facebook.check_session(request) or
             request.facebook.in_canvas))

Once we have this, we can create some more useful functions.

facebookUrl = settings.FACEBOOK_URL
def fbReverse(view, args=None, kwargs=None):
    '''
    Much like django.core.urlresolvers.reverse, except works
    in Facebook. Returns an absolute URL to a Facebook canvas
    page.
    '''
    ret = reverse(view, args=args, kwargs=kwargs)
    return facebookUrl + ret[1:] # Remove leading slash

def makeReverse(request, view, args = None):
    '''
    Returns the URL of a the specified view, either in or out of Facebook.
    '''
    if inFb(request):
        return fbReverse(view, args)
    return reverse(view, args=args)

def makeRedirect(request, view, args = None, extra = ''):
    '''
    Returns a Response object for a HTTP redirect, either in or out of
    Facebook.
    '''
    if inFb(request):
        return request.facebook.redirect(fbReverse(view, args) + extra)
    return HttpResponseRedirect(reverse(view, args=args) + extra)

These are designed to simplify URL calculations. See the comments in the code for explanations of what they do.

def makeResponse(request, template, context, common=False):
    context['pageName'] = template
    if (not common) and inFb(request):
        tmpl = 'fb/%s.fbml' % template
    else:
        tmpl = template + '.tmpl'
    return render_to_response(tmpl,
                              context,
                              context_instance=RequestContext(request))

This one is a little different, and may need updating depending on how your code is organized. I keep my templates in the directory 'mySite/myApp/templates' and give them names like 'myTemplate.tmpl'. I put my Facebook-specific templates in the subdirectory called 'fb' and give them names like 'myTemplate.fbml'. This function allows me to create two templates for a view: one for inside Facebook and one for outside. The function will detect which one to use and render it into a Response object. request is the Request object that is passed to the view function. template is a string holding the base-name of the template file, for example 'myTemplate'. context is a dictionary with the template context variables. And if common is True, the function will use the main non-Facebook version of the template no matter what (because ideally we would be able to share even these as much as possible).

One extra little bit that the function does is add an extra template variable called pageName with the base-name of the template. I find this useful for code re-use within templates, though it's not actually a Facebook-related feature.

Authentication

The next thing I wanted to do was to tie in Facebook's user information with Django's authentication mechanism. Depending on your application, you may or may not want to do this. If you want to remember information about user-contributed content, it is useful. The way I did it was to create a UserProfile model, tied in to the User model by a ForeignKey one-to-one relationship, and with a facebookId field (among other, app-specific fields). Then I created a Django authentication backend to allow authenticating by facebook ID. Here is my code for the authentication back end. If a user does not exist with the given facebook ID, a new one is created. (That, of course, may not be what you want, so you may have to modify that code.)

This code assumes that Python's logging facilities have been set up, for error reporting.

class FacebookBackend:
    '''
    Authenticate against Facebook.
    '''

    def authenticate(self, facebookId=None):
        if not facebookId: return None
        try:
            profile = UserProfile.objects.get(facebookId=facebookId)
            UpdateFbUserDetails(profile.user, facebookId)
            return profile.user
        except UserProfile.DoesNotExist:
            # No user. Create one.
            pass
        username = 'fb_%s' % facebookId
        try:
            user = User.objects.get(username=username)
            # This shouldn't really happen. Log an error.
            logging.error('Strange: user %s already exists.' % username)
        except User.DoesNotExist:
            user = User.objects.create_user('fb_%s' % facebookId, '')
        if not UpdateFbUserDetails(user, facebookId):
            return None
        user.save()
        profile, created = UserProfile.objects.get_or_create(user=user)
        profile.facebookId = facebookId
        profile.save()
        return user

    def get_user(self, user_id):
        try:
            return User.objects.get(pk=user_id)
        except User.DoesNotExist:
            return None

def UpdateFbUserDetails(user, fbId):
    """
    Fill in a user's first and last name, from Facebook.
    """
    if (not user.first_name) or (not user.last_name) :
        try:
            fb = get_facebook_client()
            userDetails = fb.users.getInfo(fbId, ['last_name', 'first_name'])
            user.first_name = userDetails[0]['first_name'][:30]
            user.last_name = userDetails[0]['last_name'][:30]
            user.save()
            return True
        except Exception, ex:
            logging.error('Error updating user: %s' % ex)
            return False
    return True

Now here is a function decorator you can use on your view functions. It will perform Facebook authentication if possible. It can also be used to require a login - either via Facebook or through a login page. With a parameter of True, it is equivalent to Django's built-in login_required decorator or to PyFacebook's facebook.require_login decorator, depending on whether the view is accessed inside or outside of Facebook.

def facebookView(requireLogin=False):
    def decorator(func):
        def wrapper(request, *listArgs, **kwArgs):
            facebookLogin(request)
            fb = request.facebook
            if requireLogin and (not request.user.is_authenticated()):
                if inFb(request):
                    return fb.redirect(fb.get_login_url(next=request.path))
                else:
                    return HttpResponseRedirect(settings.LOGIN_URL + '?next=%s' % request.path)
            else:
                return func(request, *listArgs, **kwArgs)
        wrapper.__name__ = func.__name__
        wrapper.__doc__ = func.__doc__
        wrapper.__dict__ = func.__dict__
        wrapper.__module__ = func.__module__
        return wrapper
    return decorator

def facebookLogin(request):
    '''
    Attempt to login the user based on their Facebook credentials.
    Does nothing outside of Facebook.
    '''
    facebook = get_facebook_client()
    if (not request.user.is_authenticated()) or UserProfile.Get(request.user).facebookId != facebook.uid:
        if request.facebook and request.facebook.check_session(request):
            user = authenticate(facebookId=facebook.uid)
            login(request, user)

And here is a very simple example of how to use it:

@facebookView(True) # Require login, in and out of Facebook
def myView(request):
    # Put important view processing here.
    return makeResponse(request, 'myTemplate', {'templateVar':'important data'})

Templates

We are getting closer to the holy grail of being able to write one set of code that can run both in and out of Facebook. It would also be useful to be able to share templates, so I have worked out several mechanisms to facilitate this.

The Context Processor

Django has the useful concept of a "Context Processor," which allows pre-processing of a RequestContext object before the rendering of any template. I take advantage of this quite a bit. I already discussed the cacheBreaker variable in my post about Facebook and JavaScript. Here are a couple more variables I've found useful:

• fb - The facebook object, for accessing the Facebook API, or None outside of Facebook.
• profile - The UserProfile object, if the user is logged in, or None otherwise.
• baseTemplate - The template to extend - either "base.tmpl" outside of Facebook or "fb/base.fbml" inside of Facebook.
• loginRequired - A useful string for including in hyperlinks. Within Facebook, it contains 'loginrequired=true'. Outside of Facebook, it contains something like 'onclick="return checkLogin()"', which is some custom JavaScript to require the user to login before following the link. Of course, if the link already has an "onclick" event, this cannot be used.

I'll leave it to you to write your custom template processor, as they can be very site-specific, but the above should get you started. Here is Django's context processor documentation.

Template tags

To allow more sharing, I've defined a couple of useful template tags. These must be defined in a file in a "templatetags" directory under your application directory, as described in the Django custom tag and filter documentation.

The first is fbUrl. It is the equivalent of the built-in Django url tag, except that when used inside Facebook it produces an absolute link to the requested page within the context of the Facebook canvas. In fact, the code is copied directly from the Django implementation of url. fbUrl relies on the fb context variable, and the fbReverse function, as described above.

from django.template import Node
class FBURLNode(Node):
    def __init__(self, view_name, args, kwargs):
        self.view_name = view_name
        self.args = args
        self.kwargs = kwargs

    def render(self, context):
        fb = template.Variable('fb').resolve(context)
        if fb:
            reverseFunc = fbReverse
        else:
            reverseFunc = django.core.urlresolvers.reverse

        from django.core.urlresolvers import reverse, NoReverseMatch
        args = [arg.resolve(context) for arg in self.args]
        kwargs = dict([(smart_str(k,'ascii'), v.resolve(context))
                       for k, v in self.kwargs.items()])
        try:
            return reverseFunc(self.view_name, args=args, kwargs=kwargs)
        except NoReverseMatch:
            try:
                project_name = settings.SETTINGS_MODULE.split('.')[0]
                return reverseFunc(project_name + '.' + self.view_name,
                                   args=args, kwargs=kwargs)
            except NoReverseMatch:
                return ''

def fbUrl(parser, token):
    """
    Just like Django's url tag, except also works inside Facebook.
    """
    bits = token.contents.split(' ', 2)
    if len(bits) < 2:
        raise TemplateSyntaxError("'%s' takes at least one argument"
                                  " (path to a view)" % bits[0])
    args = []
    kwargs = {}
    if len(bits) > 2:
        for arg in bits[2].split(','):
            if '=' in arg:
                k, v = arg.split('=', 1)
                k = k.strip()
                kwargs[k] = parser.compile_filter(v)
            else:
                args.append(parser.compile_filter(arg))
    return FBURLNode(bits[1], args, kwargs)
fbUrl = register.tag(fbUrl)
                        

Next is fbName. This is to provide the same functionality as Facebook's fb:name FBML tag, except also useable outside of Facebook.

The basic use of it looks like {% fbName user %}, where "user" is a template variable containing the user whose name to display. Then you can add options like linked=false, or useyou=false, as described in the Facebook documentation.

Some differences from the FBML version are:

• shownetwork, ifcantsee, and subjectid are ignored outside of Facebook.
• linked behaves slightly differently. Outside of Facebook, or if its value is set to internal, the user's name will be linked to an app-specific profile page. The view for this page is specified in the variable userProfileView. The view is expected to take one parameter: the user ID.

Here is the code:

userProfileView = 'userProfile'
class FbNameNode(Node):
    def __init__(self, user, args, kwArgs):
        self.user = template.Variable(user)
        self.args = args
        self.kwArgs = kwArgs

    def getBoolArg(self, name, default=False):
        val = self.kwArgs.get(name, default)
        if type(val) is not bool:
            return (val.lower() == 'true')
        return val

    def render(self, context):
        user = self.user.resolve(context)
        fb = template.Variable('fb').resolve(context)
        loggedInUser = template.Variable('user').resolve(context)
        request = template.Variable('request').resolve(context)
        if fb:
            fbUserId = UserFbId(user)
            if fbUserId:
                # In Facebook
                internalLink = False
                ret = '<fb:name uid="%s" ' % fbUserId
                for item, val in self.kwArgs.items():
                    if item == 'linked' and val == 'internal':
                        internalLink = True
                        ret += 'linked="false" '
                    else:
                        if type(val) is bool:
                            if val:
                                val = 'true'
                            else:
                                val = 'false'
                        ret += '%s="%s" ' % (item, val)
                ret += '/>'
                if internalLink:
                    ret = '<a href="%s">%s</a>' % (fbReverse(userProfileView, [user.id]), ret)
                return mark_safe(ret)
        # Not in Facebook
        if self.getBoolArg('useyou', True) and user == loggedInUser:
            if self.getBoolArg('capitalize'):
                ret = 'You'
            else:
                ret = 'you'
            if self.getBoolArg('possessive'):
                ret += 'r'
            elif self.getBoolArg('reflexive'):
                ret += 'rself'
            # ES: How to handle subjectid?
        else:
            ret = UserDisplayName(user)
            if self.getBoolArg('firstnameonly'):
                ret = user.first_name or user.username
            if self.getBoolArg('lastnameonly'):
                ret = user.last_name or user.username
            if self.getBoolArg('possessive'):
                ret += "'s"
        if self.getBoolArg('linked', True) or self.kwArgs.get('linked', None) == 'internal':
            ret = '<a href="%s">%s</a>' % \
                (makeReverse(request, userProfileView, args=[user.id]),
                 ret)
        return mark_safe(ret)
            

@register.tag
def fbName(parser, token):
    '''
    Returns the name for the given user, based on the parameters.

    Acts much like the fb:name FBML tag, except can work in or out of
    Facebook.
    '''
    try:
        bits = token.split_contents()[1:]
    except ValueError:
        raise template.TemplateSyntaxError, "%r tag requires at least 1 argument: the user (%s)" %\
            (token.contents.split()[0], token.split_contents())
    args = []
    kwArgs = {}
    for b in bits:
        if '=' in b:
            name,val = b.split('=', 1)
            kwArgs[name.strip()] = val.strip()
        else:
            args.append(b.strip())
    if len(args) < 1:
        raise template.TemplateSyntaxError, "%r tag requires at least one argument: the user" %\
            token.contents.split()[0]

    return FbNameNode(args[0], args[1:], kwArgs)

def UserFbId(user):
    try:
        return UserProfile.objects.get(user=user).facebookId
    except UserProfile.DoesNotExist:
        return None

Moving on

I think that should be enough to work with for now. Next time, I'll discuss publishing stories to news feeds and all that social good stuff. Until then, please feel free to post any comments, questions, or improvements below.

As I mentioned last time, Facebook lets developers use a subset of JavaScript, which they call FBJS. The FBJS is transformed on the fly into JavaScript as the page is loaded. All variables and functions you define or reference are prepended with a string like "a123456789_", including calls to document.getElementById and setTimer and the like. This is done in order to restrict what you can do with DOM elements, to avoid cross-site-scripting attacks and unwanted user-hostile behavior. FBJS is fairly well documented, so if you plan to do some Facebook JavaScript development, you should start there.

The biggest restriction that FBJS imposes is that you can no longer access the attributes of DOM elements directly, but must go through an abstraction API consisting of a series of setters and getters. For example, instead of saying something like imageEl.src = myImageUrl, you instead need to call imageEl.setSrc(myImageUrl).

This is not too big of an adjustment, if you are accustomed to writing raw JavaScript. It actually has some advantages, because FBJS abstracts away some of browser-dependent aspects into a standard API.

The challenge, however, becomes apparent when you try debugging your JavaScript. With Internet Explorer and its horrendously useless error messages and debugging facilities, it's pretty much hopeless, since the line numbers don't correspond to line numbers in your source code. However, even with Firefox and the wonderful Firebug debugger, all the name mangling and rewriting makes tracking down problems more difficult. Ideally you would want to debug as much as possible outside of Facebook, before then testing on the real site.

To make this easier, I developed some useful code to simulate as much as possible the FBJS environment when running locally or outside of Facebook. The idea was to re-create all the accessor functions on all DOM objects. You can download the file here. You're free to use it, but please don't link directly to the file on my site - copy it to your site and use it there. And read the description below first.

I considered several different approaches before settling on the final version. I considered trade-offs of performance and possible side-effects. Rejected approach number one was to modify Object.prototype to contain the new getters and setters. This would have been the fastest, but can cause problems with code like the following:

for (var param in obj) {
  // Do something with obj[param]
}

This would end up enumerating all of the added functions as well as the properties of the object in question. This is why it is generally considered a bad idea to modify Object.prototype.

The second rejected approach was to create a wrapper class with all the accessor functions, that performs the requisite getting and setting on a member variable containing the actual DOM object. This one could have worked well, but it would have been a lot of code to implement, and would have made debugging with Firebug more difficult because of the added layer of indirection.

The approach I settled on was to simply provide wrapper functions for document.getElementById and document.createElement, and for each element that is "getted" or created, to copy in the required member functions. This has a perfomance penalty during the getting or creation of elements, but the calls themselves are speedy. There is likely to be a lot more manipulation than getting, I would think.

How to use this code

To use this code, just reference this file from your web page before any of your own JavaScript, but only when you are outside of Facebook. Make sure to call fbGetEl and fbCreateEl instead of document.getElementById and document.createElement. In the version of your page that is intended to be run inside of Facebook, include this code:

function fbGetEl(elId) {
  return document.getElementById(elId);
}
function fbCreateEl(elType) {
  return document.createElement(elType);
}

Alternatively, if you are feeling a little tricky, you can add in some code like this to the end of fbHelper.js

document.getElementById = fbGetEl;
document.createElement = fbGetEl;

Then you can continue to use document.getElementById and document.createElement. (Note that I have not tested this approach.)

I hope this comes in handy for some people.

More FBJS tips

Beware of the cache!

If you make a change to your .js file and don't notice any difference in your app's behavior, chances are you are getting bitten by the cache bug. To get around this, Facebook recommends adding "cache-breaker" code to the URL. For example, instead of linking to "myFile.js", link to "myFile.js?v=2". The extra text from the question mark on is usually ignored by web servers for static files. In my Django context processor, I have code like the following:

from svnVersion import svnVersion

# Add this function to your TEMPLATE_CONTEXT_PROCESSORS
# list in settings.py
def fbContextProcessor(request):
    return { # Add any other template vars you want here.
        'cacheBreaker':'?v=%s' % svnVersion }

Then in my template, whenever a have a link, I do something like:

<a href="http://example.com/myFile.js{{ cacheBreaker }}">Click here!</a>
    

      #!/bin/sh
      echo "svnVersion = '`svnversion -n .`'" > svnVersion.py
    

That way, every time I update my code, I make sure to break the Facebook cache. Alternatively, you could call svnversion straight from Python.

console.log is your friend!

This is true in general when JavaScript programming, but especially so with Facebook. Take the time to put in some extra logging messages while you're developing, and testing and debugging will be much easier. And read up on Firebug as much as possible.

Check out the Animation library.

It's pretty cool, and it works outside of Facebook, too.

Beware the limitations.

Facebook only allows up to five external script files, so keep that in mind. You may unfortunately have to combine two or more .js files into one to work around this restriction. Also, FBJS doesn't run on profile pages until the user has interacted with the app.