Allow callable for block config options

[damsfx]

Allow options for block config to be AJAX-derived options.

config:
    bg_color:
        label: Background color
        type: dropdown
        span: auto
        options: \Acme\Plugin\Classes\Helpers\ThemeHelper::staticMethodOptions

Supplying the dropdown options in the helper class :

public static function staticMethodOptions($fieldName): array
{
    return [
        'bg-red-500' => 'Red',
        'bg-blue-500' => 'Blue',
        // ...
    ];
}

or returns different options depending on the field name

public static function staticMethodOptions($fieldName): array
{
    if ($fieldName == 'bg_color') {
        return [
            'bg-red-500' => 'Red',
            'bg-blue-500' => 'Blue',
            // ...
        ];
    }
    elseif ($fieldName == 'size') {
        return [
            'w-full' => 'Full width',
            'w-2/3' => '2/3',
            'w-1/2' => '1/2',
            // ...
        ];
    }
    else {
        return ['' => '-- none --'];
    }
}

[LukeTowers]

@damsfx would you be interested in looking into refactoring the options processing in backend forms in the Winter core so that we can have a helper of some sort that can be used from anywhere in order to support all of the different ways that options can be defined (I think we're up to 6 or 7 now)?

[damsfx]

@LukeTowers Yes, I'd like to ... but I need to know where to start and if it's within my reach.

[LukeTowers]

@jaxwilko any pointers for @damsfx?

[jaxwilko]

@LukeTowers @damsfx it's like 4am but from memory I think it happens here: https://github.com/wintercms/storm/blob/6855ef4280d2587367f6127a2bd56a89e727e490/src/Parse/Syntax/FieldParser.php#L416

Although that might just be for values defined in cms pages and not in yaml configs. @damsfx let me know how you get on and if you need help feel free to @ me :)

[bennothommo]

Ideally, I think a trait that can process them would be beneficial, then we can use it wherever it is required :)

[damsfx]

I've tried to dive back into this request ... but I'm a bit lost!

FieldParser.php - processOptionsToArray() :
Only takes a string and returns an array.

     * Splits an option string to an array.
     *
     * one|two                -> [one, two]
     * one:One|two:Two        -> [one => 'One', two => 'Two']
     * \Path\To\Class::method -> \Path\To\Class::method(): array
     *
     * @param  string $optionsString
     * @throws ApplicationException if an invalid array is returned when using the callback method.
     * @return array

FormField.php - options():

    /**
     * @var string Field options.
     */
    public $options;

but in options() method, the possible values are array, callable and even an array from a lang file.

And in this plugin's Blocks.php - processInspectorConfig(): We're looking for an array and translate the values.

Mayday .. mayday

Before going any further ... I wonder if it wouldn't be better to merge this PR and make a survey of the various places where a trait could be generalized.

[LukeTowers]

@damsfx what do you think about supporting calling a method inside of the PHP code of the block file as a way to get the options; similar to the model derived options in Forms?

something like:

config:
    bg_color:
        label: Background color
        type: dropdown
        span: auto
        options: myMethod

==
<?php
function myMethod(): array
{
    return ['key' => 'value'];
}
?>
==

As well as the other two ways:

function getBgColorOptions(?string $value = null, array $data = []): array
{
    return ['key' => 'value'];
}

and

function getDropdownOptions(string $name, ?string $value = null, array $data = []): array
{
    return ['key' => 'value'];
}

[damsfx]

@LukeTowers that's would be nice too!

Are you also thinking of keeping the option of calling a static method?
It has the benefit of being able to define the method once and then reuse it in different blocks, for example for a background color.

[LukeTowers]

@damsfx yes, I'm proposing that we could merge this to support the callable if we also add support for the derived options, then later on we can look at making a helper to standardize it across all of the places that make use of options in Winter.