Providing default implementations - a design problem with protocols

@katafrakt there are a couple of suggestions in this thread you might want to check out: Overridable functions in protocol implementations? - #6 by Ajwah

That said, when I created LiveAdmin I did consider integrating directly with the Ecto schema modules themselves to handle config, but I ultimately decided against it because I wanted something as flexible and light-weight as possible. Personally I preferred to keep that noise out of the application business logic, but other users might prefer to have it in the contexts, or separate per-schema modules, or whatever. It’s certainly true that eventually this can lead to unwieldy configs. However, since the config is just a list, there is nothing to stop the user from leveraging whatever language features they want to specify their config implementations consistently for all the schemas, and furthermore, to pass the result via app level config, rather than per-schema configs in the router. If you wanted to use protocols to contain your config logic, you could do something like this:

config :live_admin, 
  label_with: {Admin.Resource, :label, []}, title_with: {Admin.Resource, :title, []}, ...

and then the router would only need the list of schemas, which is also something you could generate dynamically.

Admittedly, not all config is currently so conducive to that approach and would need additional effort to generate, but I think it should be doable if desired. Maybe that is something I should take a look at formalizing a bit more.

2 Likes