Add a config() method to FormBase

SystemConfigFormBase is also using $configFactory

#1: form-base-config.patch queued for re-testing.

We'd need this hunk for SystemConfigFormBase, and eventually phase out the constructor

+1 to RTBC, Each form needs config, and next one is state()?

I don't want to be the badguy but I prefer the way how ControllerBase does it, as you specify the name of the config file and return a Config object instead of getting the full config factory.

Just hit into an issue with ControllerBase: #2089195: ControllerBase::config does not work as expected

.

There we go.

this fixes the test failures.

Oh damn I remembered when I worked on that last night but I seem to have missed to upload the patch.

Somehow this lost the hunk from #9.

adding #9. No interdiff attached since #9 was directly applied and committed.

More like this.

+++ b/core/modules/user/lib/Drupal/user/Form/UserLoginForm.php
@@ -138,7 +126,7 @@ public function validateName(array &$form, array &$form_state) {
-    $flood_config = $this->configFactory->get('user.flood');
+    $flood_config = $this->config('user.flood');

Code like this makes my heart sing.

Patch looks good it removes a lot off boilerplate code so RTBC.

+++ b/core/lib/Drupal/Core/Form/FormBase.php
@@ -104,6 +135,20 @@ public function setTranslationManager(TranslationInterface $translation_manager)
+   * @return self
+   *   The form.
...
+    return $this;

Usually setter don't return anything. @see FormBase::setRequest or FormBase::setUrlGenerator. But then we have FormBase::setTranslationManager returning $this. We should make a rule and follow it. We can do it in followup issue.

Awesome, thank you! :D

Committed and pushed to 8.x. Thanks!

Jibran said he would take care of creating the follow-up in IRC.

.

Tagging retroactively for configuration context because this is one of the few places where its used "properly" in the admin area.