Silverstripe-framework: GridFieldFilterHeader legacy option

Created on 25 Oct 2018  路  9Comments  路  Source: silverstripe/silverstripe-framework

Affected Version

"silverstripe/recipe-cms": "4.3.x-dev" / 1577d6386b27922b825928811ce9bc0fa108f227

Description

useLegacyFilterHeader option is very appreciated, but unfortunately, a lot of SilverStripe modules do not use Injector so using this option doesn't seem very viable. A global legacy mode option is needed.

I recommend adding a simple static configuration for useLegacyFilterHeader default value. This default value would be used in the constructor.

public function __construct(
    $useLegacy = null,
    callable $updateSearchContext = null,
    callable $updateSearchForm = null
) {
    if ($useLegacy === null) {
        // fetch global default for this value
    }

    $this->useLegacyFilterHeader = $useLegacy;
    $this->updateSearchContextCallback = $updateSearchContext;
    $this->updateSearchFormCallback = $updateSearchForm;
}

Note that this option is very much needed because the new rendering mode of this component renders different scaffolded fields.

affectv4 changpatch efforeasy impachigh typbug

Most helpful comment

@chillu @mfendeksilverstripe adding an example.

This is the QueuedJobs ModelAdmin - as far as I'm aware, it's just a standard implementation of a GridField.

This is using the legacy header (there are lots of filter options available):
screen shot 2018-10-26 at 7 14 34 am

This is with the new header (only one filter option is now available):
screen shot 2018-10-26 at 7 17 46 am

Where we control the implementation of the GridField, we have opted out, but there are a lot of areas where we can't currently do that.

All 9 comments

In general, we should aim to update the components under our control which use this legacy mode. Which ones are causing this request?

@chillu I'm not sure where the problem is, however 4.3 introduced a breaking change which should have been an opt-in, not opt-out on the instance level. As of right now, all gridfields with filter header components are practically unusable when it comes to the filter component.

The top priority should be to provide an opt-out of this breaking change and investigate the issue afterward.

@chillu @mfendeksilverstripe adding an example.

This is the QueuedJobs ModelAdmin - as far as I'm aware, it's just a standard implementation of a GridField.

This is using the legacy header (there are lots of filter options available):
screen shot 2018-10-26 at 7 14 34 am

This is with the new header (only one filter option is now available):
screen shot 2018-10-26 at 7 17 46 am

Where we control the implementation of the GridField, we have opted out, but there are a lot of areas where we can't currently do that.

@lukereative @maxime-rainville This is concerning. The intention of this change was to provide a smooth transition to the new search UI, without feature degradation, and ideally without code changes. How did we end up with a solution where the old GridField implementation had all columns filterable, and the new solution doesn't?

@chillu I think the new filter component changes the way how fields are scaffolded. I also raised a separate issue related to the scaffolding itself:

https://github.com/silverstripe/silverstripe-framework/issues/8517

In this instance it's because QueuedJobDescriptor has

    private static $searchable_fields = [
        'JobTitle',
    ];

Take that away and you get:
image

Thanks for the update. I don't think we can afford to go through each gridfield and figure out why the display is different now. We need global opt-out of this feature as soon as possible.

indeed the fix in 8827 is a workaround but it works.

Was this page helpful?
0 / 5 - 0 ratings