Pivot
  1. Pivot
  2. PIVOT-763

Add tri-state checkbox renderer for TableView row editors

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0.1
    • Component/s: wtk
    • Labels:
      None
    • Environment:
      Windows XP SP3, JDK 1.6_16

      Description

      Adds a trivial extension to the possible cell editors for a TableView to support tri-state checkboxes.

      1. tristate.patch
        4 kB
        Roger Whitcomb
      2. tristate2.patch
        8 kB
        Roger Whitcomb

        Activity

        Hide
        Roger Whitcomb added a comment -

        This patch implements the feature. Tested in our application where we have a TriState column in several of our TableViews.

        Show
        Roger Whitcomb added a comment - This patch implements the feature. Tested in our application where we have a TriState column in several of our TableViews.
        Hide
        Greg Brown added a comment -

        I like the concept, but I wonder if TableViewBooleanCellRenderer and TableViewTriStateCellRenderer should be separate (booleans technically don't support three values).

        Show
        Greg Brown added a comment - I like the concept, but I wonder if TableViewBooleanCellRenderer and TableViewTriStateCellRenderer should be separate (booleans technically don't support three values).
        Hide
        Roger Whitcomb added a comment -

        That was the way I originally implemented it, but there was so much code overlap that I tried essentially combining them. But, it is easy enough to go back the other way. What do you think of using the "load" method on the Checkbox to set the value in the "render()" method? It seems like it does everything that is needed....

        Show
        Roger Whitcomb added a comment - That was the way I originally implemented it, but there was so much code overlap that I tried essentially combining them. But, it is easy enough to go back the other way. What do you think of using the "load" method on the Checkbox to set the value in the "render()" method? It seems like it does everything that is needed....
        Hide
        Roger Whitcomb added a comment -

        The other thing I thought about was only changing the BooleanRenderer to make the checkbox protected, and then only override the constructor and "render" methods in the TriState case. That way there would be no tri-state code in the boolean one, and there would still be less code duplication....

        Show
        Roger Whitcomb added a comment - The other thing I thought about was only changing the BooleanRenderer to make the checkbox protected, and then only override the constructor and "render" methods in the TriState case. That way there would be no tri-state code in the boolean one, and there would still be less code duplication....
        Hide
        Greg Brown added a comment -

        Using load() seems reasonable. It is also used by the row editor.

        I don't see a problem sharing code between the boolean and the tri-state versions (or consolidating them), but maybe it would be better to call it TableViewCheckboxCellRenderer if that is the case.

        Show
        Greg Brown added a comment - Using load() seems reasonable. It is also used by the row editor. I don't see a problem sharing code between the boolean and the tri-state versions (or consolidating them), but maybe it would be better to call it TableViewCheckboxCellRenderer if that is the case.
        Hide
        Roger Whitcomb added a comment -

        Do you mean making a base class TableViewCheckboxCellRenderer (that is just a rename of what I have for the Boolean one) and two subclasses: TableViewBooleanCellRenderer which just has a constructor that calls "super()", and another subclass TableViewTriStateCellRenderer that just has a constructor with the "super()" and the "setTriState()" call?

        That way it wouldn't break any existing code, and make maximum reuse....

        Show
        Roger Whitcomb added a comment - Do you mean making a base class TableViewCheckboxCellRenderer (that is just a rename of what I have for the Boolean one) and two subclasses: TableViewBooleanCellRenderer which just has a constructor that calls "super()", and another subclass TableViewTriStateCellRenderer that just has a constructor with the "super()" and the "setTriState()" call? That way it wouldn't break any existing code, and make maximum reuse....
        Hide
        Greg Brown added a comment -

        I think ideally we could just get away with the one TableViewCheckboxCellRenderer class, but in order to maintain backward compatibility doing what you describe makes sense.

        Show
        Greg Brown added a comment - I think ideally we could just get away with the one TableViewCheckboxCellRenderer class, but in order to maintain backward compatibility doing what you describe makes sense.
        Hide
        Roger Whitcomb added a comment -

        Okay, this implements this hierarchy: base class with two subclasses.

        Tested with my application and all is well.

        Show
        Roger Whitcomb added a comment - Okay, this implements this hierarchy: base class with two subclasses. Tested with my application and all is well.
        Hide
        Greg Brown added a comment -

        Looks good to me. You have commit rights now, right? Feel free to check it in.

        Show
        Greg Brown added a comment - Looks good to me. You have commit rights now, right? Feel free to check it in.
        Hide
        Roger Whitcomb added a comment -

        Thanks. I will tonight.

        Show
        Roger Whitcomb added a comment - Thanks. I will tonight.
        Hide
        Sandro Martini added a comment -

        Hi Roger,
        if you commit (of course in the trunk, currently), remember to assign to yourself, and change the fix version as 2.0.1, and not 2.1 ...

        Bye

        Show
        Sandro Martini added a comment - Hi Roger, if you commit (of course in the trunk, currently), remember to assign to yourself, and change the fix version as 2.0.1, and not 2.1 ... Bye
        Hide
        Roger Whitcomb added a comment -

        Committed revision 1138493.

        Show
        Roger Whitcomb added a comment - Committed revision 1138493.

          People

          • Assignee:
            Roger Whitcomb
            Reporter:
            Roger Whitcomb
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 2h
              2h
              Remaining:
              Remaining Estimate - 2h
              2h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development