Proposal to make GridFieldConfig decoratable

[Uncle Cheese]

Right now, GridFieldConfig objects are sort of second-class citizens in the sense that they live in isolation from the primary inheritance chain. I'm sure this is by design, but I think there would be value in making them descendants of Object in order to support decoration.

If the GridFieldConfig_Base object were decoratable, for instance, then thirdparty modules could automatically inject their features into all GridFields. Right now, customizing GridFields is a bit too "opt in." Electing to use a new component means touching several files and repetitively adding the same line of code. 

Is there a reason beyond tidiness that GridFieldConfig objects are detached from the Object class?

[ad...@zauberfisch.at]

I remember arguing with chillu or Hamish about that,

and from what I remember the main reason was performance/tidiness and the opinion that no features that object has could be useful on GridFieldConfig.

 

You have a good point that default components would be nice.

 

I am currently doing some refactor work on GridField (moving slowly though)

I will take this problem into consideration.

 

An alternative to extending object would be to do like GridFieldConfig::add_default_component($c) to allow setting default components that are added to all GridFieldConfigs 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Uncle Cheese]

True. It doesn't necessarily have to descend from Object. It could just have an API for setting defaults, like you're saying, except maybe using the Config layer.

GridFieldConfig:

  extra_components:

    - MyComponent

That way modules could stuff a gridfield.yml in their _config directory and if the user wanted to opt out, he could declare that in his on gridfield.yml.

[Uncle Cheese]

... and actually, for consistency, the API should support the removal of default components, as well.

GridFieldConfig_Base:

  include_components:

    - MySpecialComponent

  exclude_components:

    - GridFieldSortableHeader

[Ingo Schommer]

Given we only instantiate a handful of instances of GridFieldConfig,

and these will be used sparingly in terms of method calls (low __call() penalty),

I don't see any performance reasons for blocking this change.

Architecturally, it would introduce more coupling, but Object.php

is our current preferred way of making objects extensible, so I'm all for this change

to further the GridField ecosystem.

[Uncle Cheese]

I've created a pull request for this. https://github.com/silverstripe/silverstripe-framework/pull/2311