Harness facebook

Component ID

1324022

Component name

Harness facebook

Component type

module

Maintenance status

Development status

Component security advisory coverage

not-covered

Component created

Component changed

Component body

Currently there are a myriad of Facebook modules that all work to achieve some aspect of Facebook functionality. The problem is that all of the methods are being developed independently and cause conflicts between modules.

The big three facebook modules

The problem

The problem with getting these facebook modules to work together is due to the facebook SDKs, specifically the JavaScript SDK. The JavaScript SDK is intended to be loaded one single time per page load and has multiple configuration settings. To further compound the issue the SDK improves over time, making it easy for developers to forget to constantly monitor the SDK for changes and implement them in to their modules.

Currently each of the big three facebook modules invokes their own instance of the JavaScript SDK immediately creating a non-resolvable conflict.

A solution

By providing a simple and configurable singleton API, all Facebook modules can invoke the SDK without conflicting with other concurrent implementations on a site.

Harness facebook architecture

This section gets a bit technical so if you're more interested in how to implement than knowing the inner workings skip down to implementation.

Singleton design pattern

While there are not many instances where a true singleton is desirable the facebook SDK is a perfect candidate. Harness facebook is written as a singleton design pattern because we only ever want one instance of the JavaScript SDK built for a single page load. This will eliminate the current non-resolvable conflict between any implementing modules. If you'd like more information about singletons the PHP manual has a good example of the design pattern.

Sub-modules

To prevent providing more facebook integration than a site may require, and to make maintenance of the API simple, the module is broken out into sub-modules based on the facebook integration needed.

Implementation

To implement Harness facebook, set whichever piece of functionality you require as your module's dependency. Currently only hfb_js (Harness facebook JavaScript SDK) has been written.

JavaScript SDK

Add JavaScript sub-module as a dependency in your .info file.
dependencies[] = hfb_js

Outputting an HTML5 or iframe'd social plugin:

HarnessFacebookJs::singleton();
// Your HTML5 or iframe code here

Outputting an XFBML social plugin:

$hfb_js = HarnessFacebookJs::singleton();
$hfb_js->xfbml = TRUE;
// Your XFBML code here

That's it, no hooking into the page output, no RDF namespaces, no template modifications.

You can also directly set and read the FB.init properties on the HarnessFacebookJs instance to meet your implementations needs. Simply call the instance then set the value:

$hfb_js = HarnessFacebookJs::singleton();
$hfb_js->asynchronous = FALSE;
$hfb_js->cookie = TRUE;
// Any other FB.init properties you want to modify.

If you are developing JavaScript integration that extends beyond the Social Plugins you can attach additional JavaScript initialization code as the facebook documentation shows immediately after FB.init:

// Set $my_js up here
$hfb_js = HarnessFacebookJs::singleton();
$hfb_js->attachJs('my_module_my_hook', $my_js);

As an added bonus whenever you make a call to the attachJs() method the first argument you provide (my_module_my_hook in the example above) will be called in an alter invocation. So if another module wants to override/modify your specific JS ($my_js in the example) they only need to add a hook implementation to their module of hook_my_module_my_hook_alter(&$js).

PHP SDK

Work is being done to build the PHP SDK, this SDK will provide the full functionality of FQL, graph API, and will not require a third party dependency.

Open collaboration

An essential part of this project will be to receive feedback/collaboration with anyone whom provides a facebook module to ensure all needed functionality is provided in a non-restrictive or burdensome manner so that site builders can finally make use of all the great facebook modules in a single Drupal install.

In closing

I've created this as a project as I have developed readily utilizable code that will allow multiple facebook modules to resolve their core implementation issues. I know not all module developers will want to add a dependency to their module and I'm being a bit optimistic about the possible reception and implementation of this method. However, my response to any module contributor not wanting to use a unified method would be: How well does your module work with the other facebook modules right now and how long has it been broken without a fix?