Create a UI for editing #options

@scott_euser Help is always going to appreciated.

I think the best approach is to do this in small steps, which could include...

• Setting up new YamlFormOptions element
• Setup tabledrag with optgroup support
• Add AJAX add more and add opgroup.
• Integrate YamlFormOptions element in YamlFormOptionsForm.
• Write tests

Below is the only immediate reference I found for creating render elements. There definitely needs to be more documentation on how to create custom form elements for Drupal and the YAML form module.

• https://docs.acquia.com/articles/drupal-8-creating-elements-theming-elem...

Some more notes

• I usually create a test YAML form and use it to build out new form elements.
• Once the element is close to done I add a basic and advanced example to yamlform.yamlform.test_element_extras

I am on vacation this week but next week I can do a Google Hangout.

Adding AJAX example to above references.

You are not far off.

There needs to be new YamlFormOptions element which can used by the YamlFormElementOptions element and the YamlFormOptionsForm (/admin/structure/yamlform/settings/options/manage/add)

Also creating a new dedicated YamlFormOptions element will be easier to test.

@scott_euser I am back from vacation. If you want to do a Google Hangout, just email me.

@scott_euser

1. Yes, we are going to most likely have to replace the whole table. We need to look at the WidgetBase class' ajax implementation and copy some of it code/patterns. For example, every options element must have a unique ID.
2. You have to use \Drupal\yamlform\Element\YamlFormOptions::valueCallback to parse and set the #default_value.
3. You probably don't need any custom templates or additional css for this widget. You just need to use core's .container-inline class.

The below code

    $element['actions'] = [
      '#prefix' => '<div class="container-inline">',
      '#suffix' => '</div>',
    ];
    $element['actions']['add_options'] = [
      '#type' => 'submit',
      '#value' => t('Add'),
      '#ajax' => [
        'callback' => '\Drupal\yamlform\Element\YamlFormOptions::addOptionsCallback',
        'wrapper' => 'edit-properties-options-custom-options-container-options-table',
        'event' => 'click',
        'method' => 'append',
        'effect' => 'slide',
      ],
    ];
    $element['actions']['add_options_quantity'] = [
      '#type' => 'number',
      '#min' => 1,
      '#max' => 1000,
      '#default_value' => 10,
      '#field_suffix' => t('more options'),
    ];

Generates the needed widget which would need an 'Add Option Group' Button added below it.

Also, you don't need to the fieldset container

The below code can be changed from

$element['options_container'] = [
  '#type' => 'fieldset',
  '#title' => t('Options'),
];

to

$element = [
  '#prefix' => '<div id="{Unique ID}">',
  '#suffix' => '</div>',
];

Some more notes

• Only focus on getting the options to work and then we can add in optgroup support.
• There might need to be two different tabledrags for the element, one for optgroup support and the other without optgroups but I am really not sure.
• If the element has no default values it should start with 5 empty options
• Each options #titles should be hidden and the table headers should be 'Option value' and 'Option title'. Each option row can have placeholder text that say 'Enter value' and 'Enter label'. This will help compress the element's overall height.

@scott_euser We should be returning (and storing) an associative array of options. We are going to have to convert the existing YamlFormOptions from storing YAML to an associative array. This can be done after the widget is setup and working.

@scott_euser Thanks, I will look at the code and see what I can do to help.

@scott_user I can now see how difficult and frustrating this is going to be to implement. I think the only way we are going to be able to do this is to completely reverse engineer https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Field!WidgetBase.... and start with just getting basic options with no optgroups working with no AJAX.

By removing all the AJAX and table drag code I was able to get the population and validation of options working in a '2759527-ui-options' branch. I still need to figure out how to get the add button work.

I think once we get the non AJAX working we could gradually layer in the AJAX.

I need a few more hours to get the non AJAX version working.

@scott_euser

Wow, this is insanely difficult to sort out. I really appreciate you starting this and feel bad that I had to reapproach the code from a different angle. The good news is if we can get this working correctly it should be very possible to add a UI to the #states API.

I had to go back to looking at Port ajax example add more and remove example from drupal 7 to drupal 8 to figure out how to properly setup the add more button.

Then, I still had to look at the WidgetBase class to figure out that the form state for the number of options needs to be stored via a unique key.

Then, I got completely burned by #1342066: Document that buttons with the same #value need a unique #name for the form API to distinguish them, or change the form API to assign unique #names automatically

Finally, I was able to get the add more working correctly. You can test the add more behavior using /yamlform/test_element_options in the test branch.

Now, I am a little stuck on how to remove an existing option. I can't find any examples of an Element that supports removing values in core or contrib.

A few take aways....

• Getting the behaviors to work without AJAX is key.
• AJAX is literally just returning (and replacing) the entire updated element.
• There is a not chance in hell that we can initial support Optgroups. If a developer wants Optgroups, they will have to write some YAML.
• more to come...

@scott_euser I managed to get a buggy but correctly coded 'Remove' button working by looking at \file_managed_file_submit() and using the below example

$form_state->setValueForElement($element['fids'], implode(' ', $fids));
NestedArray::setValue($form_state->getUserInput(), $element['fids']['#parents'], implode(' ', $fids));

There is still a bug where it is adding the incorrect number of rows after removing an option but this should be easy to fix.

As of right now, I am not seeing any bugs.

I am using /form/test-element-options for testing.

Here is a screenshot of the form.

I am also attaching a patch with no new tests but I just want to confirm that nothing is broken.

Next I have to write a dedicated test for just the YamlFormOptions element.

@scott_euser This might done or at least committable. I am expecting that the element and code will need some more tweaks/improvements in the near future.

Here is the actual patch and not a screenshot of some random error from my local machine.

@scott_euser I am going merge what is done here.

You should create a new ticket for adding optgroup support to YamlFormOptions element.

Right now, optgroups can only be created via editing the YAML source code, which I am okay with.

In the next week or two, I am going to start working on the UI for #states.