Community
Participate
Working Groups
The method setColumnFormatter(int, ColumnFormatter) on a TableRidget sets a formatter for a column. But every callback in ColumnFormatter is called with the model object of the *row*. This makes it almost impossible to write reusable column formatters, because the parameter needs to be casted to the model instance and the getter must be known to retrieve any values. Things like a simple "global" date formatter are therefore not possible. It is important to be able to format columns depending on the model, so this behavior should not be removed. But another API is required where the callbacks are called with just the cell value to be able to write reusable formatters. The opposite problem exists with Comparators for TableRidgets. There, the cell value is passed to the callback which makes it very hard to sort columns, if the whole model of the row is required to decide the order. Again, both APIs would be good. This could be considered when working on bug351310.
I dont think what you explain is correct. We have what you require a DateColumnFormatter which is a reusable column formatter. So I am pretty sure that the getText method in the column formatter is called with the cell value and not with the row value. I am also not sure what the difference between this bug is and the forementioned 351310 ? Should I (or you) copy the comments over to this other bug ? What are the things that you want us to ADD to the ColumnFormatter API. The title says ColumnFormatter are not reusable which does not seem to be true. The comment about sorting justifies a separate bug, which either you or I can create. Which would be that we copy the description over, add a new bug and close this one as (nothing left to do :-) ) ? Or what do you think ?
(In reply to comment #1) > I dont think what you explain is correct. We have what you require a > DateColumnFormatter which is a reusable column formatter. So I am pretty sure > that the getText method in the column formatter is called with the cell value > and not with the row value. Please check again. The DateColumnFormatter you speak of is abstract, because it delegates the retrieval of the actual date to an abstract method that needs to be implemented for every model object specifically. This still requires you to implement classes that handle this aspect. > I am also not sure what the difference between this bug is and the forementioned > 351310 ? Bug351310 is about the tooltip API. I don't see the relevance of tooltips to this rather conceptual problem. I merely suggested that it could be done together, if there is a refactoring of the ColumnFormatter. > The title says ColumnFormatter are not reusable which does not seem to be true. It is hard to reuse and it is impossible without implementing at least anonymous classes. Please change the title to something more fitting for you.
(In reply to comment #1) > What are the things > that you want us to ADD to the ColumnFormatter API. I don't want to necessarily add something to the ColumnFormatter API since this API already is pretty big. Maybe CellFormatters could be added that have the same API but get called with cell values as parameters.
(In reply to comment #1) > The comment about sorting justifies a separate bug, which either you or I can > create. Done. See bug351437.
(In reply to comment #2) > (In reply to comment #1) > > I dont think what you explain is correct. We have what you require a > > DateColumnFormatter which is a reusable column formatter. So I am pretty sure > > that the getText method in the column formatter is called with the cell value > > and not with the row value. > > Please check again. The DateColumnFormatter you speak of is abstract, because > it delegates the retrieval of the actual date to an abstract method that needs > to be implemented for every model object specifically. This still requires you > to implement classes that handle this aspect. OK I missed that part. Still you can create a fairly small inner class to implement this last method for DateColumnFormatter table.setColumnFormatter(2,new DateColumnFormatter("dd.MM.yyyy") { protected Date getDate(Object element) { return ((Customer)element).getBirthdate(); } } Ok so we are talking about 2 lines of code, but ok. That is a possible extension to the ColumnFormtter API with benefits. (less possibilities to make errors and so on) > > > I am also not sure what the difference between this bug is and the forementioned > > 351310 ? > > Bug351310 is about the tooltip API. I don't see the relevance of tooltips to > this rather conceptual problem. I merely suggested that it could be done > together, if there is a refactoring of the ColumnFormatter. Ok so I dont do the two bugs together (not necessarily) and I was just a little confused that you referenced it. Now its all clear. > > > The title says ColumnFormatter are not reusable which does not seem to be true. > > It is hard to reuse and it is impossible without implementing at least > anonymous classes. Please change the title to something more fitting for you. Now that I understand the problem, we leave the title as is…..
