Facebook.showFeedDialog
From Facebook Developer Wiki
Contents |
Description
Facebook will deprecate this method December 20, 2009.
Please start using Facebook.streamPublish instead.
This FBJS call pops up a Feed dialog, allowing FBML applications to let users publish Feed stories to their Walls or one of their friends' Walls.
If you specify a target_id, an alternate dialog appears, allowing the user to post to that target friend's Wall. A one-line story will also appear on the user's Wall.
The Feed dialog doesn't ping your server. You pass all your data through JavaScript, so it's faster.
Alternately, if you're not using FBJS and have an IFrame application using the JavaScript Client Library (or are a Facebook Connect site), you can make this call with FB.Connect.showFeedDialog.
Note: All of the parameters this call takes, except for continuation and target_id (as opposed to target_ids), are the same as those used in the Platform API call feed.publishUserAction.
Parameters
| Required | Name | Type | Description | |
| required | template_bundle_id | int | The ID for a previously registered template bundle. You can register a template bundle at Feed Template Console or by using feed.registerTemplateBundle. | |
|---|---|---|---|---|
| optional | template_data | object | This is the data for the template. For information on forming the template_data array, see Template Data. | |
| body_general | string | This contains additional markup for a short story. | ||
| target_id | int | This is the user ID of the friend of the Feed story actor. If this parameter is used, the Feed story template must include the {*target*} token. The story will be published to the friend's Feed, and a one-line story will be published to the user's Feed. | ||
| continuation | function | This is a JavaScript function to be called after the dialog has been accepted or rejected by the user. Note that due to concerns of abuse (rewarding users for publishing to their Feed, for example) it is not possible to determine whether the user clicked "Publish" or canceled the dialog. This function is passed three arguments: postId, exception, and data. postId is the ID of the post created by the Feed form. exception is currently not used (but is used by FB.Connect.streamPublish). data currently has one defined key: user_message, which contains the message entered by the user after the Feed form is accepted. | ||
| user_message_prompt | string | The label (which could be in the form of a question) that appears above the text box on the Feed form next to the Facebook-provided question, "What's on your mind?". | ||
| user_message | object/string | Either a simple JavaScript object containing single property, value, which is set to the content that the user enters into the Feed form, or a simple string containing the same data. This message should have been entered by the user (for example, in a comment field on your site). The user can then edit this text. When the user publishes the Feed form, Facebook sets the value property to whatever text the user typed (if an object was passed in), and passes it to the callback. |
Example Requests
Notes
.NET Usage
The JavaScript on the client page is standard, but what is interesting is the client-server interplay when using showFeedDialog. If you invoke the client script BEFORE the server postback, the dialog is never seen by the user as the postback re-draws the screen.
I found it necessary to process the server side code first, and then execute the client JavaScript to display the feed dialog. There are a few ways to do this but here is an example of script imbedding.
In the client page, after the javascript function that calls showFeedDialog, add a hidden label:
Then, in your server side method:
Now the user will see the dialog after the server-side code has completed. This at first seemed to pose a problem for my application: didn't want to "give the user credit" for completing the action until they had posted the story to the feed. However this is explicitly against Facebook policy - to reward users for posting to the Feed. This is also why it is impossible to detect the user's choice of "Publish" or "Skip". So we process the server-side transaction and if the user skips publishing to the feed then so be it.
