Easyadminbundle: [RFC] introduce template events for customization

Created on 5 Aug 2017  路  10Comments  路  Source: EasyCorp/EasyAdminBundle

This idea came to me when I was trying to customize a small part of the template and I wasn't keen to override everything.

Also, I find it very helpful when you want to customize something in template based on some conditions.

I've seen it in production at Sylius and it works great.

Documentation reference here: https://sonata-project.org/bundles/block/master/doc/reference/events.html

I'd be willing to submit a POC for this. What do you think about it?

feature wontfix

All 10 comments

Thanks for proposing improvements for EasyAdmin 馃槂

I've check very quickly the Sonata article ... but it looks like you can dispatch EventDispatcher events from Twig templates. Maybe I'm missing something, but this looks as bad as executing SQL queries in a PHP template. Is this really considered a good practice?

In any case, please tell me what do you want to do in a template that you can't today to see if we can improve it without introducing this. Thanks!

Hi Javier,

I'll be thinking about some use cases and come back with some examples. But top of mind is creating a bundle that uses EasyAdmin without extending it per-se.

For example, a bundle that allows you to read state machines for entities and render the transitions as buttons. And each time you want to render the buttons, you hook into one of the predefined events and render the content you need in there.

I find it very easy to use, especially when you don't want to mess with the predefined structure of EasyAdmin. When you need to add, rather than remove.

I'd use it for creating multiple checkboxes for bulk actions in EasyAdmin too. Or even better, conditional checkboxes.

I also find it future proof: no matter how the design of EasyAdmin goes, the customization is tied only to that event, which should be pretty consistent: e.g: easyadmin.logo.before / easyadmin.entity.list.buttons.add

And issuing events from the templates doesn't seem a bad idea, as long as you use them for design / view purposes, not business logic or something like that.

Which I totally agree, it's like doing SQL in a twig file

For templating & understanding purposes, I'd prefer to rename these "events" into "template hooks", this is much more convenient.

If this becomes implemented, dealing with logic events (controller & entities) and template events can be a mess if the class is named "Event", IMO.

Template hooks are common in some other projects (Drupal, Prestashop, Wordpress) and are dealing only with views.

I agree this could be a nice feature, it has the advantage of not bringing any BC break for the end-user, like events would do 馃憤

@javiereguiluz should I provide a POC for this feature?

If you have time for a POC, then I think it's a good opportunity to bombard this idea with lots of issues 馃槃

I have created a POC application: https://github.com/gabiudrescu/EasyAdminWithStateMachine

relevant files:

My plan is to craft a bundle called something like "EasyStateMachine" that couples EasyAdmin with WinzouStateMachine for a super-awesome RAD toolkit you can use to build awesome apps.

Hence the need to have hooks into EasyAdmin where I can hook to display certain stuff based on certain criterias without extending EasyAdmin per-se.

WDYT?

@gabiudrescu I'd rather like this EasyAdminWithStateMachine to use Symfony's Workflow component instead of a third-party bundle. The big advantage is that it's built-in symfony/symfony automatically, and if using splitted components, we can just disable the feature with a compiler pass (like what the FrameworkBundle does when some packages are not available, like forms, validator or workflow).

Something more:

The state machine concept, even really interesting, doesn't really correspond to the "event" system, which is a bit different (we were first talking about "hooks" to add logic in templates, not state machines).
In your POC, I don't see where we could add different kinds of hooks in the templates we currently have, and how to "hook on them" via service.

The POC for this issue would have resembled to this kind of configuration to me:

easy_admin:
    entities:
        Post:
            class: App\Entity\Post

services:
    App\Admin\Hooks\PostListHook:
        tags:
            - name: easy_admin.hook
              hook: list.top
              entity: Post

I'm really sorry but I must close this as "won't fix". The truth is that the complexity of this bundle is too much for me. I want to remove things, instead of adding more things. I've seen the code you linked above and it looks like you can solve this need using Sonata features and linking them with this bundle and other third-party apps.

If there is a super small change that we can do in this bundle to make applications like this easier (e.g. changing a private method to protected, etc.) then please ask us and we'll look into it. But adding a whole integration with state machines is out of the current scope of the bundle. I'm sorry but I hope you understand it. Thanks!

@javiereguiluz no worry, I totally understand your position.

unfortunately, I haven't had much time lately for this idea and the business case I was trying to use it for got sidelined.

I still believe adding state machine integration with EasyAdminBundle is a good idea, maybe in the future it will become again interesting and we'll give it a shot then.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nickicool picture nickicool  路  4Comments

liarco picture liarco  路  3Comments

haithem-rihane picture haithem-rihane  路  4Comments

Ealenn picture Ealenn  路  3Comments

BigMichi1 picture BigMichi1  路  3Comments