{"id":4297,"date":"2016-08-09T15:43:00","date_gmt":"2016-08-09T20:43:00","guid":{"rendered":"http:\/\/www.carnaghan.com\/?p=4297"},"modified":"2019-09-27T09:49:12","modified_gmt":"2019-09-27T13:49:12","slug":"building-configuration-forms","status":"publish","type":"post","link":"https:\/\/www.carnaghan.com\/building-configuration-forms\/","title":{"rendered":"Building Configuration Forms"},"content":{"rendered":"\n

In Day 3<\/a> we are starting to accelerate in terms of skills developed by the cards. This card has us create our first Drupal<\/span> 8 module<\/span>, learn about Drupal<\/span> 8 Form<\/span> API<\/span> and learn about the Configuration API<\/span>. The card starts off with directing you to several Drupal.org documentation pages including Creating a Custom Page<\/a>,  Defining and using your own configuration in Drupal 8<\/a>, Providing Default configuration<\/a>, and Simple Configuration API<\/a>. Except for the Creating a Custom Page document, everything else here is focused on giving you a solid overview of the configuration system within Drupal<\/span> 8.<\/p>\n\n\n\n

Building our First Drupal<\/span> 8 Module<\/h2>\n\n\n\n

Creating a Custom Page walks through the process of setting up a custom module<\/span> with Drupal<\/span> 8 that outputs simple ‘Hello World’ output. It introduces you to the basic structure of a Drupal<\/span> 8 module<\/span> as well as the use of .yml<\/span> files, which become an integral part of module<\/span> development. Each module<\/span> has at a minimum an info.yml file<\/span> defining the module<\/span> name, type, description, package and core version. This is excluded in the ‘Creating a Custom Page’ doc as it is assumed you already know this. The routing.yml file<\/span> essentially defines routes (url paths) linked to controller actions. For me this was quite a familiar concept as I come from an ASP.NET MVC background. For Drupal<\/span> 7 developers, the routing.yml is a replacement for hook_menu. Finally, the controller file<\/span> is the heart of the logic that happens within the module<\/span> and controls responses to user inputs either via a Twig view page or Drupal<\/span> form.<\/p>\n\n\n\n

Drupal<\/span> 8 Controllers (ControllerBase vs FormBase)<\/h2>\n\n\n\n

Another important resource<\/span> posted in Day 3<\/a> was a blog post called Creating a custom Form<\/a>. This post helped solidify some of the knowledge I already had gleaned from the cards as well as my own personal experience. It walks you through creating a basic Form<\/span> that extends the FormBase controller class<\/span>. Now this is where I got a little confused. In the earlier ‘Creating a Custom Page’ documentation, the controller code inherits from ControllerBase and ControllerBase is what I have been using currently on some custom modules<\/span> at work. After doing a little research it appears that there are several base controller classes<\/span> and they can be used for different things. If you are just outputting data<\/span> from Drupal<\/span>, you can use the ControllerBase. If, however you need to tap into the new Drupal<\/span> 8 Form<\/span> API<\/span>, you must inherit from FormBase. I found this a little confusing as I have been used to having the same base controller class<\/span> in C#<\/span> regardless of using a form or not, however I guess this is just something I’ll get used to. One other major difference between using the standard ControllerBase vs FormBase is the location of src files<\/span> which typically reside in \/src\/Form<\/span> for form API<\/span> code and \/src\/Controllers for regular ControllerBase controllers.<\/p>\n\n\n\n

ConfigFormBase<\/h2>\n\n\n\n

Now that I had got my head around ControllerBase vs FormBase, I quickly realized I needed to understand a third controller base class<\/span> called ConfigFormBase if I wanted to generate a form that would allow me to write configuration<\/span> settings<\/span>. Luckily enough I came across a very helpful post on Drupal.org titled Working with configuration forms<\/a>. In order to create a form that also allows you to write configuration<\/span> settings<\/span>, you must inherit from ConfigFormBase instead of FormBase and then you must add a method<\/span> called getEditableConfigNames, which grabs a editable object we can store our new settings<\/span> to.<\/p>\n\n\n\n

protected function getEditableConfigNames() {\n    return [\n        'example.settings',\n    ];\n}<\/code><\/pre>\n\n\n\n
This would loosly equate to $config = Drupal<\/span>::service(‘config.factory’)->getEditable(‘system.performance’);<\/strong> outlined in the Simple Configuration<\/span> API<\/span> document (however in this case we are grabbing settings<\/span> to write to Drupal<\/span> core, not our individual module<\/span> settings<\/span>.<\/p>\n\n\n\n
Putting it all together<\/h2>\n\n\n\n
After spending quite a bit of time with all the resources<\/span> outlined above, I was able to finally come up with a working example form built inside a module called ‘day3’ that allows the user<\/span> to update local configuration<\/span> settings<\/span> defined within the module. This can be confirmed by visiting \/admin\/config\/development\/configuration<\/span>\/ and looking for changes applied to day3.settings:<\/p>\n\n\n\n
\"config\"<\/a><\/figure>\n\n\n\n
The file<\/span> structure of my day3 module includes:<\/p>\n\n\n\n