-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature : Add the possibility to position the filters just below the column name #85
Comments
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 :) |
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. |
Looks good to me, more readable 😄 |
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 |
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:
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. |
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?
The text was updated successfully, but these errors were encountered: