| Bad interaction between EditingSupport, column widgets, and ViewerColumn [message #901725] |
Tue, 14 August 2012 10:53 |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
After having worked with the recommended Viewer-API based on
EditingSupport and CellLabelProviders for quite a long time I have often
stumbled several limitations that make the practical day work
unnecessarily hard:
1) ViewerColumn - albeit allowing to set CellLabelProvider and
EditingSupport - has no public access to either of these members,
because the corresponding functions have package visiblity.
The result is that people either use reflection or they open a new
package of org.eclipse.jface.viewers and add some convenience access
function to realize the same need.
2) There exists no public way to retrieve the ViewerColumn from the
corresponding column widget (which is TableColumn or TreeColumn).
What people do is to rely on duplicating current jface code based on
querying the data() object of the widget for key Policy.JFACE +
".columnViewer" instead.
I consider these limitations as a real defect, the above mentioned
workarounds are often found in the wild because these kind of use-cases
are very useful for generic tools. They will all break of-course, when
jface would consider to change any of these mechanisms (which they can
based on there API guidelines).
One example where I fight hard against the "API barriers" is when I try
to define a ColumnViewerEditorActivationListener that allows me to have
different activation strategies for different EditingSupport types
[When working with ColumnViewerEditorActivationEvent there is a similar
unfortunate underspecification, because there is no clear indication
that the ViewerCell can be safely retrieved from the source of the event
object. Nonetheless code in the wild bases on this assumption as well].
I need to break at least one of above mentioned API barriers to
implement such a generally useful functionality, because there is no
documented way to realize that [Note: Assigning an individual
ColumnViewerEditorActivationStrategy is no acceptable option in this
case, because what I intend to fine-tune an existing strategy of code
out of my control].
I consider strict API contract rules as very important and we don't
break such rules (unless they are officially accepted as defects), but
in this case it seems to me that jface is over-encapsulating something
that is near to common agreement. I would like to hear whether there are
any directions of change planned for these column-based EditingSupport
API that would either provide a better public access to these or would
finally make these undocumented APIs public (In the first case by making
the functions public, in the second case by making the data key public).
If not, are any changes planned to make above assumptions invalid and in
this case: How is the mental model of interaction for the revised API?
Thanks and Greetings from Bremen,
Daniel Krügler
|
|
|
Powered by
FUDForum. Page generated in 0.03309 seconds
] 
Search
Help
Register
Login
Home
