Open Kreyu opened 2 weeks ago
One thing to consider on this feature is sorting, In your example you show 2 headers (Employee & Quarter) and Quarter has I & II sub headers, will those be allowed to be sorted as well?
Depending on the data this may become very tricky, same goes for filters and search, so usually it's easier to flatten the table instead.
Also, it might be better to bisect the data per Quarter and show a table per Quarter instead?
Just thinking out loud here, could be a nice addition for some edge cases for sure, but goes more towards a static table, since this kind of nesting can get extremly complex :)
One thing to consider on this feature is sorting, In your example you show 2 headers (Employee & Quarter) and Quarter has I & II sub headers, will those be allowed to be sorted as well?
Yeah, I think so. I don't see any risks with that, if you can provide sorting path for such column (e.g. DQL path when working with Doctrine), then there should be no problem with that.
Also, it might be better to bisect the data per Quarter and show a table per Quarter instead?
In some cases, probably. That's just a first example that came to my mind 😄
Currently, the
DataTableBuilderInterface::addColumn
method currently acceptsColumnBuilderInterface
as an argument, but nesting columns is not yet supported.I'm thinking of some simple, yet friendly API, similar to forms. Let's assume, that we have to render a table like that:
To achieve such hierarchy, I'm thinking on something like this:
This way, we've created a data table that consists of two columns - employee and quarter, but the latter contains two children columns - respectively first and second.
If you create a view of such data table, you should notice two header rows, with appropriate HTML attributes automatically assigned to the first one:
This corresponds to the following HTML structure:
This would require following changes:
createColumn()
toDataTableBuilderInterface
, that returnsColumnBuilderInterface
, similar toFormBuilderInterface::create()
.Adding column-related methods methods to the
ColumnBuilderInterface
(addColumn()
,removeColumn()
, etc.), so API remains consistent. Naming those methodsadd
andremove
may seem more intuitive, but I think it would be confusing if used in this case:rowspan
andcolspan
HTML attributes - preferably in theColumnHeaderView->attr
array.DataTableView
to accept array ofHeaderRowView
, instead of just one.sortablejs
, and it already supports nesting! Although, we have to prevent moving nested column outside of their parent.Some breaking changes, but nothing too extreme. Probably needs more changes, but that's how I see it as today.