scala-swing icon indicating copy to clipboard operation
scala-swing copied to clipboard

Common CellRenderer API Design - backwards compat

Open kenbot opened this issue 14 years ago • 1 comments

My common Renderer[-A] trait has the following method signature:

def componentFor(owner: Owner, value: A, cellInfo: companion.CellInfo)

Where Owner is say, a ListView[], Tree[] or Table, and CellInfo contains the extra component-specific stuff like row, isSelected, isFocused and so on. (Assuming ListView and Table are retrofitted with CellView/RenderableCellsCompanion and so forth)

The advantages of this abstraction are compelling; for instance, this mixin will provide an identical renderer for Tree, ListView and Table:

trait RenderFiles {
  this: RenderableCells[File] =>
  import companion._
  renderer = Renderer(_.getName)
}

Also, the LabelRenderer implementation in Table can be entirely pushed up to the CellRendererCompanion level of abstraction.

However this causes backwards compatibility issues with the existing componentFor methods in Table and ListView. I have made some attempt at accomodating user code that overrides either, but it may still break existing code. I'm not sure how to handle this case.

kenbot avatar Nov 14 '10 01:11 kenbot

The backwards incompatibility has been reduced to just requiring the "override" on old implementations of componentFor() on ListView.Renderer. (Same goes for Table.Renderer in principle).

kenbot avatar Jan 02 '12 08:01 kenbot