omines / datatables-bundle

DataTables bundle for Symfony
https://omines.github.io/datatables-bundle/
MIT License
252 stars 113 forks source link

(WIP - Discussion) Render columns like in form_row #180

Closed Clorr closed 1 year ago

Clorr commented 3 years ago

Hi !

NOTE : This PR is just a Work In Progress and a request for feedback. It is not intended for merging.

First thank you for this project, it is AWESOME! I love the way it has a clear syntax that is quite like the original Symfony Forms.

The only thing that bothers me a little is the rendering that leads to html in php which I don't like so much. Of course, there is the TwigColumn, but, as said in the doc, it adds a lot of overhead. I was then thinking of finding a way to do this, in a way more like the Forms.

As you know, Forms use form themes with blocks like form_widget, so I was thinking, maybe it could be possible to have the same approach for columns, by having one twig template with many blocks like mycolumn_column (where mycolumn is the name of the column declared in the datatable) where we can do the formatting in the block. This has the main advantage of loading only one twig where all the blocks are declared, and using it for each row and column.

If you think it is a good way for improvment let me know ;-)

Example of a table theme:

{% block id_column %}{{value}}{% endblock %} {# blocks can be declared optionally, this one is just for demonstration #}

{% block name_column %}{{value|capitalize}}{% endblock %}

{% block text_column %}{{value|raw}}{% endblock %}

{% block html_column %}{{context.text|nl2br}}{% endblock %}

{% block link_column %}<a href={{ path('my_route', {id : context.id})}}>{{context.name}}</a>{% endblock %}
Clorr commented 3 years ago

On the implementation side, I was thinking of modifying the Bundle so that instead of doing $table->getResponse(), we could do $table->render("path/to/my/theme.html.twig")

I tried to modify the code base, but the transform of columns is done in adapter and this is not so convenient. I thought I would be able modify it but, there are 2 adapters that call the transform : the AbstractAdapter and the ArrayAdapter. I first tried to make the code of both adapter look more similar because they are doing the same thing, and then I realised the ArrayAdapter does the search on the transformed values which blocks me.

So I was wondering if it is normal that the search in ArrayAdapter is made on the transformed values while it is not the case elsewhere?

Also I was thinking of exploring another approach. Maybe it is possible to do differently, and setup the theme in the table setup with something like ->setColumnsTemplate("path/to/my/theme.html.twig")). Maybe it will help me overriding the $column->transform. I'll let you know ;-)

Clorr commented 3 years ago

My last commit implements a new approach with a setColumnTheme function to be called at init (ex: $table->setColumnTheme("_template.html.twig")).

It's not perfect, it could be better to inject directly the renderer at the call of $column->initialize() but there is no way to guarantee that the theme will already be instantiated at that time.

Let me know what you think of these tests, maybe this can be a cool new feature ;-)

curry684 commented 1 year ago

This has become too old to merge now, if you want to resume work please open a new PR.