Standardize the return of status messages in AJAX callbacks

I know we can do better than this patch, something more along the lines of full separation of messages all the way to the browser, like quicksketch proposes in http://drupal.org/node/399982#comment-1807684. But I'm not yet sufficiently up to speed on the new AJAX framework to create that patch, so here's a less ambitious solution. If we can't get the better one in on time, let's at least get this one in.

The thinking behind this patch is to make the simple use-case of a AJAX callback returning a string of html result in status messages automatically handled without the AJAX callback doing anything. However, to allow special AJAX callbacks the flexibility of NOT returning status messages, nothing is done if the AJAX callback returns an array of commands instead of an html string. For, example, if poll.module did not want status messages included with its result, it could change

function poll_choice_js($form, $form_state) {
  ...
  return drupal_render($choice_form);
}

to

function poll_choice_js($form, $form_state) {
  ...
  return array(ajax_command_replace(NULL,  drupal_render($choice_form)));
}

A little complicated perhaps, but it moves the more complicated code needed to the exception (not wanting status messages) rather than having extra complication for the default situation (wanting status messages).

Something else that should be included with this issue is a fix to a bug introduced into HEAD from patch 72 of #367567: Use AJAX framework for "Add more" / load include file containing form / introduce $form_state['build_info']. When you click "add another item", if there's a validation error, that gets shown as a status message at the top of the new content. If you click "add another item" again, and if the same validation error occurs again, it gets duplicated. Or, if no validation error occurs the second time, the old one is still there. This is because the returned AJAX content (including the status messages) replace a previously defined "wrapper" div, but the status messages are outside of the *new* wrapper div, so a subsequent "add another item" doesn't replace the prior status messages. This can be easily tested by setting the "body" field of the "page" content type to "unlimited" number of values and having a maximum length of 1.

Really? I thought that issue was just to make sure that *some* validation get bypassed (for example, validation of the node title field when you're adding another item of the body field). Are we saying that we plan on not validating *anything* when using the "add another item" button?

If that's the case, then what about other status messages (not validation errors)? Should those persist across multiple uses of "add another item", or get replaced each time?

I'm having a hard time getting CVS to work for me right now. It's EXTREMELY slow (like taking 10 minutes per file to do a cvs update and not managing to do a cvs diff). I'm not sure if it's something funky with my room at Paris (here for DrupalCon), or if the server is crawling due to final stretch of code-freeze. @sun or @rfay, if you're having more luck with cvs right now, would you be willing to re-roll patch from comment #3? Do either/both of you agree that in the absence of some other solution being developed within the next few hours (what time and time zone is code-freeze?), this small patch is better than nothing?

This one solves the issue from comment #5. See comment #7 for why I believe this is important even if #370537: Allow suppress of form errors (hack to make "more" buttons work properly) lands. Note also that if a ajax callback wants to handle status messages differently, it can do so by returning an array of ajax commands instead of a string of html.

Thanks, @rfay, but I didn't follow closely all the work merlinofchaos and others were putting into the D7 ajax library, and I don't feel sufficiently empowered to override the decision on that variable name. I agree that it's an unclear name, and if someone wants to submit a separate patch for that, I'll be happy to +1 it.

For this patch, I reverted field.form.inc to return an array of commands instead of just the content, because I talked with yched, and he indicated a concern about not leaving an example of returning an array anywhere in core. Ajax.inc supports returning an array so that contrib modules, like views, can do fancier AJAX stuff than simply returning content.