|Re: Possible Bug in CompositeFreezeLayer [message #1786568 is a reply to message #1786448]
||Mon, 07 May 2018 12:41
| Dirk Fauth
Registered: July 2012
Well, I am not sure what to say about that. Actually the methods you refer to are not used anywhere in NatTable. They just exist. And they are not even documented, so I really don't know about the intended semantics. They were added before I stepped into the project.|
That said I wonder why anybody is testing things that are not used anywhere, but well, that is what testers do right? I can only assume that the idea was to return the unmodified number of rows and columns, regardless the transformation added by a layer. For example if the ViewportLayer only shows 5 of 10 columns, then getColumnCount() will return 5 while getPreferredColumnCount() still returns 10.
We could now have a lot of discussion on the solution. Actually I think your solution is wrong and the CompositeLayer implementation is correct. If there is an issue I would search in the ViewportLayer. It truncates the view on the underlying layer but it still says the preferred column count is the same as the underlying one. But the semantic of that method is to return the column count without transformations. So who is right? If we would connect the FreezeLayer and the ViewportLayer without any additional transformation side to side, than we would have 12 columns in your example. The FreezeLayer has 3 columns as that is his purpose, the ViewportLayer without any transformation would show 9 columns, as the would neither truncate the columns nor would he return only a viewport but everything.
From my point of view, without a definition of the purpose of this API and no usage of that API, I wonder if such a discussion really makes sense.
If you think it is worth the effort, well create a ticket and provide a patch I can check and integrate.
Powered by FUDForum
. Page generated in 0.01757 seconds