Easyadminbundle: Make own ConfigPasses configurable and more reusable

[a-r-m-i-n]

Hello!
I've spend some time to understand the way how you process the YAML configuration. I've put my results to this gist (maybe also useful as addition for your documentation)

Because you've used private methods for the config magic, I can't inherit from, when e.g. I want to introduce an own action, with own processed configuration (entities, fields, templates, actions, ...).

Also you use in some ConfigPasses, hardcoded lists of actions/views.

I've got several ideas of how to make it more accessible

1. Make all methods protected, also the properties with default values
2. Pass the default actions/views used in helper methods as optional parameter (so extending ConfigPasses may overwrite it)
3. and/or use Symfony's config parameters to define the actions/views. Then you probably need to group the actions/views, because sometimes one helper method in ConfigPass handles several actions in different blocks. Possible action/view groups:
   
   
   
   • iterationActions (list, search)
   
   
   • singleItemActions (new, edit, show, delete)
   
   
   • formActions (new, edit)
   
   

When you are interessted in, I could prepare a pull request :)

I'm using EAB a lot in a not that small project, and I love it! 👍
So I hope I can help to improve it 😃

[javiereguiluz]

Hi! I'm afraid I don't know what to do about this proposal 🤔

@xabbuh @yceruto what's your opinion about this? Thanks!

[xabbuh]

Can you describe some real use cases that you have and that are currently not possible?

[yceruto]

I don't like the idea of ​​turning everything to protected, because what it will imply about BC. Instead I'd suggest to pass the hardcoded config as argument of the __constructor() method. All ConfigPasses are services, so we can decorate them to change some config if needed.

[a-r-m-i-n]

What if you would outsource the magic which makes

fields:
  - id

to

  "fields" => array:4 [
      "id" => array:21 [
        "css_class" => ""
        "format" => null
        "help" => null
        "label" => "ID"
        "type" => "integer"
        "fieldType" => "integer"
        "dataType" => "integer"
        "virtual" => false
        "sortable" => true
        "template" => "@EasyAdmin/default/field_id.html.twig"
        "type_options" => array:1 [...]
        "form_group" => null
        "fieldName" => "id"
        "scale" => 0
        "length" => null
        "unique" => false
        "nullable" => false
        "precision" => 0
        "id" => true
        "columnName" => "id"
        "property" => "id"
      ]
]

to an own helper class, which is accessible. Then own provided ConfigPasses could reuse this functionality, in case they want to provide an own list of fields.

A valid use case is the embeded list (see related issue). To provide different config for embeded list you need to provide a "fake" entity to be used.

And I did a Hybrid view (for a project), which mixes new/edit and show view of large entities at one page. To be able to reuse easy admin bundle stuff, I need to provide proper configuration arrays, which I am currently not really able to build.

[a-r-m-i-n]

Nevermind.

[Pictor13]

@a-r-m-i-n if you are still curious about how to solve this I managed to make it work, overriding the ConfigPasses and providing my own implementation, plus doing some adjustment in my custom controller.
Check the referenced issue 😉

And thanks for your gist! Not a game changer but was helping me to see what I wanted/needed to overwrite and what not (without having to dig in the code and in all those foreach-s 😁).

EDIT:
oh, by the way, this is the fixed link to your gist, with the correct username: https://gist.github.com/a-r-m-i-n/d5cfd73f4f0ca9b20353747cdabeba0e

[nescim]

Too bad this got closed! I need to change the default translation labels and got stuck with copying and pasting half the files in the Configuration folder because I couldn't override the individual methods I needed to change.

I humbly put forward the idea that using private in library code is a code smell (a violation of the O in SOLID) unless it is really needed.