Eclipse Community Forums: NatTable » Best Practice about uncommon table layout

Home » Eclipse Projects » NatTable » Best Practice about uncommon table layout(How to add an area between header and body)

Show: Today's Messages :: Show Polls :: Message Navigator

Best Practice about uncommon table layout [message #1768464]

Wed, 19 July 2017 06:51

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Hi There!

I need to create a Table where it is possible to apply some input to all data in a given row. (and this shall be possible for all rows in the table).
e.g.

-) the user should be able to define all row values to be reported
-) the user should be able to apply a label to all row entries.

Visually this would be an area between the Column Header and the BODY. This area would contain two rows - one with a checkbox, and one with a combobox (showing the list of available labels).
I call this the "SettingsLayer". Of course the settings layer needs to be editable, and the values provided using setDataValue() would be propagated to the row elements.

Now I have several ideas how I could implement this behavior - but I'd like to know how persons kowing NatTable way better then me would implement it.

1. Use DefaultGridLayout and somehow extend the header area (similar to how the filter row is added)
2. Use DefaultGridLayout create a Composite of the "SettingsLayer" and the BodyLayer.
3. Do not use the DefaultGridLayout but create a "MyOwnGridLayout" being a (2,3) Composite. Then of course I'd have to do all the default stuff (key bindings etc.) on my own.

I'm quite new to Nattable (use it for a month now), but I think I understand the basic concepts. In this area I simply don't want to move into the wrong direction, so any hint would be appreciated.

Regards,
Chris

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768522 is a reply to message #1768464]

Wed, 19 July 2017 16:43

Dirk Fauth

Messages: 2902
Registered: July 2012

Senior Member

1. I never use the DefaultGridLayer, I always use GridLayer when I need a grid
2. I would either choose 1 or 3, probably 1 as it sounds like your settings layer is some sort of extended header and the transformations in the body should be reflected similar as for the column header. Although 3 is also not too complicated

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768568 is a reply to message #1768522]

Thu, 20 July 2017 06:34

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Hello Dirk !

Thanks for the quick reply - helps me a lot!
Basically I tend going towards 1, but I'm not sure about one thing: I need row headings for the "settings rows" - is it possible to put these into the Corner Layer (such that they are aligned nicely with each row of the settings view).
Basically the corner layer would become a row header layer for the column headings this way.

If I need an own region to achieve this, then I have to go for 3 anyways, as GridLayer hardcoded defaults to Composite(2,2). (wouldn't it be nice if the users had a constructor where they could define the composite size on their own? - just an idea, but likely an uncommon usecase).

Btw. out of curiosity I got 3. working in the meantime. I have just one strange effect: if I click the checkboxes, the corresponding setDataValue methods gets invoked, but they dont change their state. if I force a redraw (e.g. by resizing the window) they get drawn correctly.

any idea why this happens ?

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768569 is a reply to message #1768522]

Thu, 20 July 2017 06:34

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Sorry - unfortunate double post.

[Updated on: Thu, 20 July 2017 07:12]

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768572 is a reply to message #1768569]

Thu, 20 July 2017 07:10

Dirk Fauth

Messages: 2902
Registered: July 2012

Senior Member

well if you need row headings for your settings layer you should go with option 3. That gives you the most possible flexibility for such a composition.

Your idea with setting the composite size on your own, well that is available via CompositeLayer. The GridLayer is just a simplification for a CompositeLayer(2,2), and a grid is defined by corner, column header, row header and body. Making the GridLayer composition configurable doesn't make sense.

If the redraw is not performed I suppose some event is either not fired or retrieved in the stack to trigger the redraw.

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768575 is a reply to message #1768572]

Thu, 20 July 2017 07:43

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Well - if I understand correctly the benefit of the GridLayer is not just the simplification for a 2,2 composite, but also lots of default event handling seems to be done there - exactly the area where I seem to have problems with the checkboxes not being drawn.

Further we have already quite some code (NatTableBuilder classes etc) which internally use GridLayer, and I have to change all these in order to apply our new feature (possibly introducing problems this way, as I forget some event handlers or such).

About events not being fired: in my sample I use the following two classes as configuration on the SETTINGS area. Do you see something which I am obviously missing?

static class EditAreaEditBindings extends AbstractUiBindingConfiguration {
    public static final String SETTINGS_REGION = "SETTINGS_REGION";

    @Override
    public void configureUiBindings(UiBindingRegistry uiBindingRegistry) {
        uiBindingRegistry.registerSingleClickBinding(
            new CellEditorMouseEventMatcher(SETTINGS_REGION),
            new MouseEditAction());
        uiBindingRegistry.registerMouseDragMode(
            new CellEditorMouseEventMatcher(SETTINGS_REGION),
            new CellEditDragMode());
        uiBindingRegistry.registerFirstSingleClickBinding(
            new CellPainterMouseEventMatcher(SETTINGS_REGION, MouseEventMatcher.LEFT_BUTTON, CheckBoxPainter.class),
            new MouseEditAction());
        uiBindingRegistry.registerFirstMouseDragMode(
            new CellPainterMouseEventMatcher(SETTINGS_REGION, MouseEventMatcher.LEFT_BUTTON, CheckBoxPainter.class),
            new CellEditDragMode());
    }
}

static class EditingConfig extends AbstractRegistryConfiguration {
    @Override
    public void configureRegistry(IConfigRegistry configRegistry) {
        configRegistry.registerConfigAttribute(EditConfigAttributes.CELL_EDITABLE_RULE,
                                               IEditableRule.ALWAYS_EDITABLE, DisplayMode.EDIT,
                                               ViewSPRPartV1.EDIT_ACTIVE_LABEL);
        configRegistry.registerConfigAttribute(EditConfigAttributes.CELL_EDITABLE_RULE,
                                               IEditableRule.ALWAYS_EDITABLE, DisplayMode.EDIT,
                                               ViewSPRPartV1.EDIT_POSITIVE_CONTROL_LABEL);

        List<String> controlValues = Arrays.asList("PosCtrl 1", "PosCtrl 2", "PosCtrl 3");
        configRegistry.registerConfigAttribute(EditConfigAttributes.CELL_EDITOR,
                                               new ComboBoxCellEditor(controlValues), DisplayMode.EDIT,
                                               ViewSPRPartV1.EDIT_POSITIVE_CONTROL_LABEL);
        configRegistry.registerConfigAttribute(CellConfigAttributes.CELL_PAINTER, new ComboBoxPainter(),
                                               DisplayMode.NORMAL, ViewSPRPartV1.EDIT_POSITIVE_CONTROL_LABEL);
        configRegistry.registerConfigAttribute(EditConfigAttributes.CELL_EDITOR, new CheckBoxCellEditor(),
                                               DisplayMode.EDIT, ViewSPRPartV1.EDIT_ACTIVE_LABEL);
        configRegistry.registerConfigAttribute(CellConfigAttributes.CELL_PAINTER, new CheckBoxPainter(),
                                               DisplayMode.NORMAL, ViewSPRPartV1.EDIT_ACTIVE_LABEL);
        configRegistry.registerConfigAttribute(CellConfigAttributes.DISPLAY_CONVERTER,
                                               new DefaultBooleanDisplayConverter(), DisplayMode.NORMAL,
                                               ViewSPRPartV1.EDIT_ACTIVE_LABEL);
    }
}

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768597 is a reply to message #1768575]

Thu, 20 July 2017 11:53

Dirk Fauth

Messages: 2902
Registered: July 2012

Senior Member

In theory not. I guess you need to debug to see who is calling setDataValue on your settings data provider and if an UpdateDataCommand is fired and handled. Might be that it is caught or not transported to the NatTable where the repaint is triggered.

Quote:

if I understand correctly the benefit of the GridLayer is not just the simplification for a 2,2 composite, but also lots of default event handling seems to be done there

Yes and no. it registers some default configurations and command handlers. Dependent on the features you want to support it should be easy to adapt that. It also specifies the order in which the commands are processed in the composition, so the body is the first to react, then the column header and so on. The default is to go from top left to bottom right. And the third addition is the handling of percentage sizing, that is performed only for the body region and therefore the ClientAreaResizeCommand is modified. Shouldn't bother you if you don't use percentage sizing.

The main thing is that you now said that you also want to have some sort of row header for your settings layer. And that makes it a (2,3) composition. Everything else would be very hard to implement and to maintain. And believe me, I have created much more complicated compositions than that.

Quote:

Further we have already quite some code (NatTableBuilder classes etc) which internally use GridLayer

Well, yes you will need to change that. And I hope you are not referring to the NatTableBuilder in our repository. As this is code that is unmaintained for several years.

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1768680 is a reply to message #1768597]

Fri, 21 July 2017 12:18

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Hello Dirk !

Things are getting more clear now - thanks a lot for your time! I guess I will implement an own Composite being quite similar to GridLayer, just supporting a separate "SETTINGS_REGION".
I will simply create a new NatTableBuilder from our existing ones (they are one of our classes - not the one from your repository) - this way I can be sure not to break existing functionality.

[Updated on: Fri, 21 July 2017 12:19]

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1770285 is a reply to message #1768680]

Wed, 09 August 2017 15:57

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Hello Dirk !

Thanks for your last tips - I basically got it running, buuut .... ;-)

What I did was to create a CompositeLayer(1,3) with a ColumnHeaderLayer, a DimensionallyDependentLayer (Settings Area) and a BodyLayerStack containing the "typical layers".

I built a DataProvider for the settings area, providing the getDataValue and setDataValue methods. I use CheckboxCellEditor and ComboboxCellEditor to manipulate the values.
This works quite well beside of two problems

1) I need the ability to hide columns. In case a column "before (or left)" of the edited column is hidden
-) The getDataValue methods get invoked with the correct column index of the underlying column.
-) The setDataVaule method invoked because of the edit event get the wrong column index.
e.g. if I hide the first column, then the DP getDataValues get invoked with the proper indizes (1 for the 2nd column, etc.) - but if I edit the 2nd column the setDataValue method gets invoked with column index 0.

2) Sometimes when I drop down the combobox of the ComboboxCellEditor, it does not close when it looses the focus, and the "drop down arrow" remains active.
If I make the window smaller the list still stays active - even outside the windows boundary.
Sorry it's hard to describe - but possibly you saw this effect already and have an idea what could trigger it. I attached a screenshot - possibly it helps ;-)
The Screenshot shows 2 of the "erratic comboboxes" (2nd and 4th column) and the list remaining active outside of the window.

In the "standard case" (when clicking carefully) the Combobox works totally as expected.

index.php/fa/30335/0/

Attachment: NatTableComboNotClosing2.PNG
(Size: 20.46KB, Downloaded 417 times)

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1771024 is a reply to message #1770285]

Mon, 21 August 2017 08:52

Dirk Fauth

Messages: 2902
Registered: July 2012

Senior Member

Not sure if you are aware of the index-position-transformation done in the layer concept of NatTable. Sounds like you are missing some transformation somewhere which is causing all the trouble.

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1771349 is a reply to message #1771024]

Thu, 24 August 2017 10:09

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Hello Dirk !

I implemented a stripped down Sample showing my problem. It's small, and very similar to most of your samples anyways - so I guess it will be very fast for you to take a look.
It just needs the typical dependencies, and can be immediately started as java application (like all your samples). All you would need to do is to import it into a "problem" package of any existing sample project.

A more detailed description is contained in the header ..... maybe the code is even valueable as a new sample, I tried my best to implement it "readable".

Regards,
Chris

Attachment: IndexTransformInHeader.java
(Size: 12.39KB, Downloaded 175 times)

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1771424 is a reply to message #1771349]

Fri, 25 August 2017 05:02

Dirk Fauth

Messages: 2902
Registered: July 2012

Senior Member

Sorry, but reviewing and fixing your issues with uncommon table layouts is beyond the scope of what I can do for free in my rare spare time.

If you need professional support with NatTable, feel free to write me an email and ask for it. I will be happily sending you an offer to help you with your issues.

Report message to a moderator

Re: Best Practice about uncommon table layout [message #1771439 is a reply to message #1771424]

Fri, 25 August 2017 06:05

Chris Lewold

Messages: 13
Registered: July 2017

Junior Member

Well - I fully understand your point, thanks a lot anyways for the time you invest here on the forums. Going to ask my boss whether we can get some funding.

Btw - just in case you are curious - as the same data provider gets invoked with different indices in getDataValue and setDataValue I expected a possible bug in NatTable - that's why i tried to help with this sample.
I have a workaround for that (doing the index transformation on my own in the setter).

So again - sorry if I was using your time too much, it for sure wasn't my intention.

Report message to a moderator

Previous Topic:	Is it possible to use RowSelectionModel in combination with GroupByLayer ?
Next Topic:	Potential bug in SelectionModel.java

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 05:09:46 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter