Feature : Add the possibility to position the filters just below the column name

[alexandre-castelain]

Hello,

Thank you for this bundle; it looks promising.

For better UI, I believe it would be beneficial to have the filters positioned just below the column names. Additionally, having the option to select the comparison operator directly from there would be even more advantageous.

This is a feature I often use in my projects, and I would greatly appreciate having it included in this bundle.

What do you think about this?

[Kreyu]

Hey! Cool idea. I think we could make this feature optional, by setting some option of the data table type itself (whether to display filtration form above, or below the columns):

class ProductDataTableType extends AbstractDataTableType
{
    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver->setDefault('filters_below_columns', true); // name of the option could be better
    }
}

Currently, filters are completely independent of columns, meaning you can create a filter that doesn't associate with any visible column. Maybe we could associate filters with columns with additional option, e.g.:

$builder
    ->addColumn('foo')
    ->addFilter('foo') // same name - displayed below "foo" column
;

$builder
    ->addColumn('bar')
    ->addFilter('baz', ..., [
        'column' => 'foo', // different name - associated by an option
    ])
;

No idea how to handle filters that are not associated with any column then - maybe we should not render it at all, or throw an exception. Twig themes should render differently based on the data table and filter options described above.

I'll keep this in mind. At the moment, I'm not adding new features and I'm only fixing bugs due to very limited free time lately (though I hope that will change soon). Of course, pull requests and discussions are more than welcome :)

[alexandre-castelain]

Proposal:

Why not keep the current method of adding "global" filters and also add the ability to apply specific filters to individual columns?

I'm not sure about the complexity of implementing this, but I was thinking of something along these lines:

$builder
    ->addColumn('foo', TextColumnType::class, [
        'filter' => [StringFilterType::class, [...filterOptions]]
    ])
;

or maybe, even better :

$builder
    ->addColumn('foo', TextColumnType::class, [
        'filter' => StringFilterType::class,
        'filter_options' => []
    ])

This way, it would be impossible to add a "column-specific" filter globally, and it would even be possible to combine both methods, which could be useful in certain cases.

[Kreyu]

Looks good to me, more readable 😄

[alexandre-castelain]

Hey @Kreyu,

How can I help you with this bundle ? I see a lot of "enhancement" issues, but no bug in the Issues pannel.

What's the plan to deliver a V1 of this bundle ? What's blocking you right now ? Is this documentation ? Some missing feature ?

Have a good day,

Alexandre

[Kreyu]

Hey @alexandre-castelain,

What's blocking the stable release of the bundle in my opinion is the lack of tests - only about 20-30% of the codebase is tested, and most crucial parts are still not covered. The whole library was created in haste, because company I am working with really needed something like this, and had to prototype something as soon as possible. Now, asking other people to write tests for existing code feels wrong to me 😞

Also, there's two things I'm really not happy with:

• twig themes are a bit chaotic in some parts, with unnecessary blocks, weird inheritance, etc. which I was planning to refactor before release to prevent additional work with previously created custom themes;
• every integration with form seems unnecessarily complicated, and really buggy. For example, we cannot display validation errors on the filtration form, because form submitted in the HttpFoundationRequestHandler is different than the form displayed to the user;

Not sure on how to delegate work described above to others, as I don't have any clear idea on how to handle those things. I'll create issues with more details to make it more clear. Hope to come back to this project soon with more time available.

Thanks for your willingness to help, it means a lot.

[2mx]

What's blocking the stable release of the bundle in my opinion is the lack of tests - only about 20-30% of the codebase is tested, and most crucial parts are still not covered.

@Kreyu

Have you ever tried generating unit tests with the help of an AI ?

• GitHub copilot
  • https://github.blog/ai-and-ml/how-to-generate-unit-tests-with-github-copilot-tips-and-examples/
  • https://youtu.be/Psm86eIvmdc?si=6DS63aTIf1flaxE4
• phpStorm AI pluging https://www.jetbrains.com/help/phpstorm/generate-tests.html

[2mx]

@alexandre-castelain @Kreyu

Yes, I also like the idea of having filters displayed in the columns. However, I prefer the approach proposed by Sebastian because I think adding a filter in the AddColumn method brings confusion, more code to maintain and if at some point we want to add more filters, there’s only one line to change for the filters to appear outside the table.