First off, thank you very much for going to the effort of releasing this code; I have been trying very hard to find some up-to-date django/facebook code that works, and think I’ve finally settled on your code.

I am completely new to django and completely new to any Facebook API, and although there seems to be dozens of django+facebook projects, they all either don’t work with django 1.2.1 or are generally broken/undocumented… Most also seem to use older Facebook API’s, although I’d be happy using an older API if it meant I could get some code working :-/

I am wanting very limited functionality from Facebook – just the user’s details for the purposes of authenticating them, and later on the ability to post on their wall. Ideally I want this to run “inside” facebook like a regular facebook app rather than on a separate web site like Fashiolista does, but I assume that won’t be a problem (?).

I have been working through getting your code up and running, and due to some missing pieces of the puzzle (and a lot of missing knowledge on my part) it’s been *really* slow going.. I’m now running into a couple of bits that I can’t guess at and would greatly appreciate your help. I’ll go through what I’ve done so far:

- Downloaded Django-facebook from pypi – noticed there were a couple of files missing from the package meaning that installing it wouldn’t work – downloaded the package from github which only had a couple of missing text files stopping instillation I think (I’m also not that familiar with python package intricacies) – I added a couple of empty text files to the github package and it seemed to install okay.

- Started with an almost complete version of the django poll tutorial as a basis for implementing your code.

- Implementation step 1 (from your list on github): I have no idea what FACEBOOK_FAKE_PASSWORD and FACEBOOK_JINJA should be, so left these undefined, (I think they both default to True).

- Implementation step 2: done

- Implementation step 3: I assume this is all taken care of if I use your connect.html template as a basis? – I didn’t do anything else here.

- Implementation step 4: Eventually figured out that I had to call my UserProfiles class “Profiles”, and it had to be in a module called “user” (I changed my Model name and changed “from user ….” to “from gec ….” in auth_backends.py (as “gec” is the name of my app). I also found there needed to be “user = models.OneToOneField(User)” in my Profile class (although I’m assuming this name is standard anyway).

- Implementation step 5: Copied your connect.html file into my gec/templates folder (and hard-coded my own appId in it), added (r’^facebook/$’, ‘geconquest.gec.views.connect’) to urls.py, and set my Canvas URL in facebook to “http://localhost/facebook/” so it goes straight here.

To get over some CSRF errors I added “{% csrf_token %}” inside the in your connect.html…I think this is all I did there.

Now it’s looking for a form called RegistrationFormUniqueEmail in a module called “registration” (referenced from django_facebook/views.py:_register_user). I added a form here and put in:
> ip = forms.CharField()
> email = forms.EmailField()
just at a guess, and am now getting an import error “No module named coffin” from django_facebook/view_decorators.py:_process_response, which is something to do with this JINJA thing… I’m just about to try setting FACEBOOK_JINJA=False and see what happens.

Would you be able to brief me on the purpose of FACEBOOK_FAKE_PASSWORD and FACEBOOK_JINJA, and add in some skeleton files for any required files, with the required parts in (for example the contents of the RegistrationFormUniqueEmail class, as I have no idea what fields should be set here..)

Lastly, if you’re reading this thinking “this guy’s on completely the wrong track – he should be using the django-blah-blah-facebook project instead…” please let me know!

Thanks again,

and any comments/help from anyone else are most welcome!

This will only make your code more complex as you need to access everything through this instead of through the scope chain.

A proper ’singleton’ should either be formed by using a regular literal object, or through the module pattern combined with an immediately invoked function.
var foo = (function(){

return {
bar: funciton(){..}
};
}());

All scripts created dynamically are by default asynchronous.

Most of this code is actually more than 6 months old, I just didn’t get to writing an article before.

It would be trivial to add template caching to the tag though, but I don’t think it matters that much. Especially not for my use case where I need small specific Jinja functions in Django admin templates and otherwise I’ll simply use a full Jinja template.

…

I’m lucky in that I use Django 1.2 and creating your own Jinja2 Template loader is trivial: http://www.rosslawley.co.uk/2010/07/django-12-and-jinja2-integration.html. The downside is you have to write your own filters and / or wrap django filters, but I even got the template debugging working with the debug toolbar!

Should we call this metatemplates? :)

It’s good to hear you serve the script from Akamai. That builds a strong confidence on the javascript’s uptime. Still recommend the async approach, because of speed and reliability. The speed advantage is increasing with the advent of modern browsers. Your recommendation to add the script at the bottom of the page is solid.
Congrats on the release of the button. The usage of data attributes on the a element is very elegant.

I’m one of the developers of the Tweet Button. I’ve responded to a similar post on The Next Web if you’d like to take a look. In short though, this is a reasonable tip in general but your worries are a little unfounded. We serve the tweet button from Akamai (an edge caching service) twitter being down or slow has no effect at all on the load time of the script. For more detail check my comment here:

http://thenextweb.com/socialmedia/2010/08/13/the-twitter-button-is-it-making-your-site-join-the-fail-whale-shuffle/#comment-13751

Thanks,

Dan