Details
-
Enhancement
-
Resolution: Unresolved
-
P4
-
8u5
Description
In 8u5 there is no way to get the table header control. For certain operations you might need it.
For some of these things one can also consider the header a feature of the TableColumn and that's fine if that is the the way into the header API. But since there is the composite part that might not work in all cases.
Some initial thoughts:
1) You want to install a custom cell node on the header. This is probably possible in some other way but that API should be on the header.
2) The header is the natural way to get to the filler.
3) Height of the header is now (AFAIK) only settable though CSS which might be limiting.
4) You want to get or set the min/pref/max and current width of the header cells. Now there's no way to for instance get the preferred width of the header cell.
If all cases above (which is in no way complete) can be logically handled through other API:s then maybe we don't need the header. CSS though is no magic fallback IMO. There are things that needs to exist as API, for instance those that are inherently reactive/dynamic and can't be expressed in a declarative way.
One problem if having some of the API not exposed is that it will be hard to write a new columnResizePolicy for TableView since that needs info from the header.
Again, maybe it's enough to expose all desired header properties through the TableColumn and TableView APIs . Only further investigations into this issue will give that answer. Not having another moving part, which the TableHeader will be, is always desirable, mind we get enough flexibility.
For some of these things one can also consider the header a feature of the TableColumn and that's fine if that is the the way into the header API. But since there is the composite part that might not work in all cases.
Some initial thoughts:
1) You want to install a custom cell node on the header. This is probably possible in some other way but that API should be on the header.
2) The header is the natural way to get to the filler.
3) Height of the header is now (AFAIK) only settable though CSS which might be limiting.
4) You want to get or set the min/pref/max and current width of the header cells. Now there's no way to for instance get the preferred width of the header cell.
If all cases above (which is in no way complete) can be logically handled through other API:s then maybe we don't need the header. CSS though is no magic fallback IMO. There are things that needs to exist as API, for instance those that are inherently reactive/dynamic and can't be expressed in a declarative way.
One problem if having some of the API not exposed is that it will be hard to write a new columnResizePolicy for TableView since that needs info from the header.
Again, maybe it's enough to expose all desired header properties through the TableColumn and TableView APIs . Only further investigations into this issue will give that answer. Not having another moving part, which the TableHeader will be, is always desirable, mind we get enough flexibility.