[REVIEW REQUEST] Disabling TableView column reordering

[Jonathan Giles]

Interesting idea. I'll give it some more thought tomorrow, but I thought 
I'd throw out one more wrinkle / thought quickly. I'm sure you're 
familiar with TableColumn (and TreeTableColumn is essentially exactly 
the same). One concept many people are unfamiliar with when talking 
about TableColumn is the fact that it can itself contain children 
TableColumn via the getColumns() method. This allows for nesting of 
TableColumns.

For example, given a TableColumn for 'name' with two children 
TableColumns for 'first' and 'last', the 'first' and 'last' name columns 
are constrained within the 'name' column, and the 'name' column can be 
moved to any place at the same point in the hierarchy.

So, we're already building up a tree of columns, but this tree is more 
like the visual model, whereas we now also want to be able to define 
another model to specify the constraints. I'd love to somehow reuse this 
concept, but I haven't quite cracked how to do it yet. Perhaps it 
doesn't make sense to do this, but perhaps it does.

-- Jonathan

On 3/01/2013 3:54 p.m., Scott Palmer wrote:
> My first instinct is to use a tree of column groups.  Each parent node in the tree indicates if the children are reorderable or not. Children of a column group must always remain children of that column group. The leaf nodes in the tree are columns, parents are column groups that each have the boolean reorderable flag.
>
> The trivial case #1 of either allowing or disabling all column reordering uses a single column group with all columns in it.  Just set the boolean property on that column group.
>
> Case #2 of column 1 always coming before column 2 (do you mean that they are adjacent as well? I'm assuming so for this example.) the "root" group contains: group_B, c3, c4, c5, c6...
> Group_B contains: c1, c2 and its boolean property is set to not allow reordering.
> The root group is set to allow reordering.
>
> The case #3 of columns 2 and 3 being adjacent means that they are in their own column group. The "root" group contains: c1, group_B, c4, c5, c6...
> Group_B contains: c2, c3
> Both groups are set to allow reordering.
>
> Case #4 is trickier, unless I further constrain it such that columns 1-4 must come before column 5 and columns 6,7,8... must come after column 5.  But if those constraints are acceptable it fits as well.  The root group contains group_B, c5, group_C.  Group_B contains: c1, c2, c3, c4. Group_C contains: c6, c7, c8...  Only group_B and group_C are set to allow reordering.
>
>
> Scott
>
> On 2013-01-02, at 9:12 PM, Jonathan Giles <jonathan.giles at oracle.com> wrote:
>
>> This is an interesting point, and it actually reminds me of another issue I discussed with people at Devoxx, which is what to do when we eventually support cell spanning (despite being implemented in the 8.0 repos I plan to disable this before we ship 8.0 - unless I can find time to sort all of this out).
>>
>> In the case of column spanning, you want the columns with spanned cells to be locked together, so that they form one unit when moved and can also be reordered within themselves as well (if that makes sense!). What I mean to say is that if cells are spanning columns 2-3 it should be possible to move column 3 before column 2, but you can't put column 4 between columns 2 and 3 as that would separate the spanned cells.
>>
>> So, in short, we have the following use cases that need to be supported:
>>
>> 1) Disabling all column reordering (easy with a boolean property on TableView / TreeTableView)
>> 2) Specifying a column ordering, e.g. that column 1 must always come before column 2.
>> 3) Specifying a column grouping, e.g. that columns 2 and 3 must always be adjacent.
>> 4) Specifying a fixed column, e.g. that column 5 must always be in the fifth position (and therefore can never be moved). This could possibly be done simply by having a boolean property on TableColumn / TreeTableColumn that states whether the column allows for reordering, but I have a feeling we may run into issues with this so it will need some more thought. It is also possible that this use case is a degenerate case of the second use case, but I'd need to think through the API further before that becomes clear.
>>
>> Of course, having written this all out I should end by saying that the only way to properly implement this API would be to not use column indices at all (instead we should be using references to the TableColumn / TreeTableColumn instances). I will need to give this API some thought. It's not immediately clear to me how best to represent these constraints, so if anyone has some suggestions for a lightweight API that captures these requirements, let me know :-)
>>
>> -- Jonathan
>>
>> On 3/01/2013 2:55 p.m., Scott Palmer wrote:
>>> What if I want one column fixed, e.g. column 1, but the remaining columns reorder-able?
>>> Could there be a way to specify ordering constraints on the columns?
>>> E.g. columns 1-3 can be in any order but must be before columns 4-6, which can also be in any order.
>>>
>>> Scott
>>>
>>> On 2013-01-02, at 6:31 PM, Jonathan Giles <jonathan.giles at oracle.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Just a quick post to discuss RT-24669 [1], which is a request to disable all column reordering functionality in TableView. I would like to support this use case in both TableView and TreeTableView by way of a 'columnReorderingEnabled' property (so, columnReorderingEnabledProperty(), setColumnReorderingEnabled(boolean) and isColumnReorderingEnabled()).
>>>>
>>>> Are there any comments or API naming suggestions? I would love to have the naming be shorter, but I can't think of a better name that retains the clarity as to what the API does.
>>>>
>>>> [1] http://javafx-jira.kenai.com/browse/RT-24669
>>>>
>>>> Thanks,
>>>> -- Jonathan