Allow #submit and #validate to be specified as methods of the form object

Added test coverage and one conversion in the wild.

+++ b/core/lib/Drupal/Core/Form/FormBuilder.php
@@ -859,6 +859,10 @@ public function doBuildForm($form_id, &$element, &$form_state) {
+        // Support method names of the form object.
+        if (is_string($process) && method_exists($form_state['build_info']['callback_object'], $process)) {
+          $process = array($form_state['build_info']['callback_object'], $process);
+        }

+++ b/core/lib/Drupal/Core/Form/FormSubmitter.php
@@ -129,6 +129,10 @@ public function executeSubmitHandlers(&$form, &$form_state) {
+        // Support method names of the form object.
+        if (is_string($function) && method_exists($form_state['build_info']['callback_object'], $function)) {
+          $function = array($form_state['build_info']['callback_object'], $function);
+        }

+++ b/core/lib/Drupal/Core/Form/FormValidator.php
@@ -69,6 +69,10 @@ public function executeValidateHandlers(&$form, &$form_state) {
+      // Support method names of the form object.
+      if (is_string($function) && method_exists($form_state['build_info']['callback_object'], $function)) {
+        $function = array($form_state['build_info']['callback_object'], $function);
+      }

Did you considered moving this to a helper method?

We could also do an explicit unit test now that we have a public function.

Instead of FormBuider, we *could* move this method now also to FormState, thoughts?

That's a fine idea. Would you keep it static? I guess there's no reason to...

This is great to see that patch.
1) DX++ but there's a lot of of array(get_class($this), 'someMethod') in core, could be fixed in follow-up
2) Not sure the problem of 2 and 3 from subject is fixed, at least there's no tests
3) needs change record and update https://www.drupal.org/node/1734540 at least

1. +++ b/core/lib/Drupal/Core/Entity/EntityForm.php
   @@ -317,11 +312,6 @@ protected function updateFormLangcode(FormStateInterface $form_state) {
      public function buildEntity(array $form, FormStateInterface $form_state) {
        $entity = clone $this->entity;
   -    // If you submit a form, the form state comes from caching, which forces
   -    // the controller to be the one before caching. Ensure to have the
   -    // controller of the current request.
   -    $form_state['controller'] = $this;
   

   is there a test to make sure that $this is not serialized?

2. +++ b/core/modules/system/src/Controller/FormAjaxController.php
   @@ -8,6 +8,7 @@
   +use Drupal\Core\Form\FormBuilder;
   
   index 63a17d1..31b0950 100644
   --- a/core/modules/system/src/Form/CronForm.php
   
   +++ b/core/tests/Drupal/Tests/Core/Form/FormBuilderTest.php
   @@ -11,6 +11,7 @@
   +use Drupal\Core\Form\FormBuilder;
   

   unused

is there a test to make sure that $this is not serialized?

This is definitely out of scope.

Awesome work @Berdir!

Erm. What. #validate => 'foobar' , comes another class extending and adds a foobar method and suddenly THAT runs but the original validate doesn't? That's a good idea how? Of course, this is a very contrived example and very unlikely to be a problem esp because camelcase vs underscores. But I think laying down landmines is not a particularly good idea even in places where we think noone will ever trod. Also, how are we going to document/explain/teach this?? It's simply not how PHP behaves.

I recommend changing 'methodname' to '$this->methodname'. Yes it's a Drupalism still but there is no ambiguity and I believe it's fairly trivial for anyone to see what's up.

Talked to berdir, updating the issue summary with ::methodname as a suggestion.

And yes: thanks for the great patch and great idea of using :: this will be a lot better than the array($this, 'foo') we have currently.

Erm. What. #validate => 'foobar' , comes another class extending and adds a foobar method and suddenly THAT runs but the original validate doesn't?

That's the same problem as in HEAD, and with :: as a prefix. If you override the method, you're overriding it.

The talk of subclassing was a red herring, @Berdir explained the actual problem in IRC. Carry on.

I'll let @chx RTBC, but this is a fine change. Thanks @Berdir!

Missed a spot.

Thanks so much for the work, it does look great.

This looks absolutely fantastic but doesn't seem to apply after the other patches that went in today.

Actually --3way works. (Thanks, Tim!)

Committed and pushed to 8.x. Thanks!

Awesome change, great for native forms.

Would be nice if Field Widgets could leverage somthing like this for their own #fapi_callbacks (i.e methods that don't live in the main Form object)