Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 351310 - IColumnFormatter refactor proposal
Summary: IColumnFormatter refactor proposal
Status: NEW
Alias: None
Product: Riena
Classification: RT
Component: Look And Feel (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-06 07:32 EDT by Christian Campo CLA
Modified: 2011-07-06 07:34 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Campo CLA 2011-07-06 07:32:56 EDT
IColumnFormatter was recently extended. It had previously 7 callback methods for formating individual cells in a table. Now 9 additional methods where added for cell-specific tooltip support.

Not so good (code smell)
- why is still called IColumnFormatter, if its more about tooltips
- why do people who only want to format cells need to implement tooltip methods (and not just one, but many) (even though there is the base class ColumnFormatter

There are two ways I believe to do this better:
- Separate the two in the previous IColumnFormatter and have the new tool methods in a derived interface IColumnFormatterwithTooltip...the Table Ridget could figure out at runtime, whether the columnformatter also supports tooltip information based on the typ information from the interface
- have 2 independant interfaces (probably better) one for formatting, one for tooltip. and have 2 separate methods in the Table ridget to set them

I am in favor for the last solution but open this up for discussion.