Update a View with AJAX on status update submission

This is less "won't fix" and more "can't fix." And believe me, I've tried. I've consulted merlinofchaos who wrote Views, Panels, Chaos Tools et al, and he says even he couldn't do it. If merlinofchaos couldn't do it, there's no way I could. :-/

This may eventually be possible if, for instance, a View was embedded within the status update form (so it would be refreshed along with the form). I haven't looked into how that would be done but I hope to eventually look into that approach.

Turns out this got on my mind and I couldn't be satisfied until I found a way to make it work. Try the demo site for proof (also committed to dev).

In order to make this work on your site, you'll need to create something (a block, node, custom pane, whatever) that can hold PHP snippets, and put this inside it:

//Assumes that this only appears on user profiles.
echo theme('facebook_status_form_display', user_load(array('uid' => arg(1))), variable_get('facebook_status_size_long', 40), TRUE);

In that case this is a support request, not a feature request - you should form_alter() the status update form in a site-specific module to unset $form['fbss-submit']['#ahah'].

/**
 * Implementation of hook_form_alter().
 */
function mymodule_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == '_facebook_status_status') {
    unset($form['fbss-submit']['#ahah']);
  }
}

You could also alter it like this to get a JavaScript-updating effect for your Activity view:

/**
 * Implementation of hook_form_alter().
 * Assumes the view takes a UID parameter and that the status update form only appears on user profiles.
 */
function mymodule_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == '_facebook_status_status') {
    if (module_exists('views')) {
      $form['fbss-view'] = array(
        '#value' => views_embed_view('name_of_my_activity_view', 'default', arg(1)),
        '#suffix' => '</span>',
      );
      unset($form['status']['#suffix']);
      drupal_add_css(drupal_get_path('module', 'facebook_status') .'/facebook_status_view.css');
    }
  }
}

Ah, well, what's probably happening is that your form_alter() is adding the View to the form at the end, and the AHAH on form submit replaces everything within a <span> that's closed by the View if it's present. In the module, the view is higher up on the form. Probably what I'll do is just change the module so that the theme function can specify which view is displayed. You'll end up with something like this:

//Assumes that this only appears on user profiles.
echo theme('facebook_status_form_display', user_load(array('uid' => arg(1))), variable_get('facebook_status_size_long', 40), 'facebook_status_recent');

Put the code in #6 wherever you want your status/view combo. No need to change any module/theme files. The code that will make this work is currently incubating in CVS - grab the next dev to try it. You can go ahead and put the code from #6 where you want it while you're waiting--it won't break anything, it will just show the facebook_status view instead of the one you specify.

For help, see the new documentation on this.

The CSS to do that is already in the module, and it works unless the viewing area is too small. I really can't help you beyond there--there's no other way to do it, although I suppose it might be marginally possible to improve upon the CSS. Take a look at facebook_status_view.css if you're interested.

I know. That's how it works and it can't be changed. The CSS is slightly improved in the latest dev (replace your whole facebook_status folder) so can try that if you'd like; otherwise I can't help you and you'll have to mess around with your theme. It works in Garland...

As you'll notice from the docs, the 'facebook_status_form_display' theme function takes three variables: a user account object, an integer denoting the horizontal size the status update textfield/textarea should be, and the "view" parameter:

$view = 'machine_name_of_the_view_to_display';

The $view parameter should be the string of the machine name of the view you wish to display. In your case I think it's called "activity" or "activity_history," I can't remember which. I don't know how you came up with $block in your code, but not only should you not invoke Drupal hooks like hook_block() that way, but it wouldn't give you anything that would be remotely useful for you to work with, and you also mysteriously pass "user" to that module_invoke() without declaring it as a variable or assigning any value to it.

This probably should have been a separate support request, although I understand that this all stems from the same original issue in your head/site. ;-)

I managed to turn off AHAH in the form, but Panels won't update content (Author pane, activity etc.) before manually pressing F5 to update the page. Then browser complains about resending form data. After pressing "resend" everything is right.

Don't hijack unrelated issues for your personal support requests. This issue isn't even for a version of the module that's supported any more, not to mention that it's closed, and it's very rare that there's a valid reason to reopen a closed issue.

Per your question, Panels has nothing to do with it. Read the docs and this thread--you can't have a view auto-update if it's in another panel. Not to mention there's no way you're going to get AHAH-driven updates if you hacked the module to remove the AHAH.

I was replying to your comment no 4 and was trying to point out that disabling AHAH in the form with unset($form['fbss-submit']['#ahah']); didn't do me any good (cannot be considered "hacking" the module). This flat view of comments makes it look like I'm commenting on the main issue.

So should I open a new issue? Disabling AHAH doesn't make the form reload the whole page, and pressing F5 makes the browser to ask for confirmation on resending the form values -> confusing for user.

Yes, you should have opened a new issue. However, I can't give support if you're not using the module the way it's built. I will say that your problem after unsetting the AHAH in the form is probably that your Drupal system cache needs to be cleared, but that's as much as I can do for you.