Community
Participate
Working Groups
I've noticed that StructuredViewer.getRawChildren() calls assertElementsNotNull() after getting the values from its content provider. assertElementsNotNull() throws a runtime exception if it encounters any nulls in the array of values. I think this is unnecessarily restrictive - when dealing with a ComboViewer (which extends StructuredViewer) it is a common requirement to include null as one of the choices (for example, to allow the user to "unselect" a combo box's value).
I'm not 100% sure when you want to unselect a value you set the selection to null and the array doesn't has to contain a null
(In reply to comment #1) > I'm not 100% sure when you want to unselect a value you set the selection to > null and the array doesn't has to contain a null > I'm not sure I understand that statement correctly. Are you saying that I can call setSelection(null) to accomplish what I want? If that is what you're saying, it doesn't help because the user needs a way to select null from the GUI (typically a blank choice at the top or bottom of the combo list). The bottom line is that null is a valid value and the fact that StructuredViewer prohibits it (which is both undocumented and very inconvenient for apps that need this).
ok now I got you :-)
In cases like this, I would recommend using a "null object" (http://en.wikipedia.org/wiki/Null_Object_pattern). I understand that allowing null in ComboViewer would be useful. I am not sure if we can allow null elements without breaking API contract compatibility - for example, the API contract for label providers disallow null for the element. Other APIs to consider are ViewerComparator, IElementComparer, ViewerSorter, ViewerFilter... I'd say it is too much work for little value, but feel free to contribute a proof-of-concept patch to convince me otherwise.
(In reply to comment #4) > In cases like this, I would recommend using a "null object" > (http://en.wikipedia.org/wiki/Null_Object_pattern). > > I understand that allowing null in ComboViewer would be useful. I am not sure > if we can allow null elements without breaking API contract compatibility - for > example, the API contract for label providers disallow null for the element. > Other APIs to consider are ViewerComparator, IElementComparer, ViewerSorter, > ViewerFilter... I don't know about the other APIs, but I looked at all the interfaces that extend IBaseLabelProvider and could find no such contractual obligations. In fact, the base LabelProvider class has a null check in the code of getText(Object) and ITableLabelProvider's method comments explicitly allow null to be passed as the element. (I'm looking at the 3.3 code base) > I'd say it is too much work for little value, but feel free to contribute a > proof-of-concept patch to convince me otherwise. Using the Null Object pattern is what I've already done to work around this, but that is not always a simple proposition in light of the multiple levels of indirection and loose coupling that exist nowadays: ContentProviders, Data Binding, EditSupport, etc. In other words, the components involved in translating a Null Object into a real null in the model are ever-increasing and confusing. I'd be interested in trying to patch this myself, but I do acknowledge your point that there are a lot of potential collateral changes. I'll see if I have some time for experimentation over the holiday break. Even in light of the potentially far reach of the change, I still think it is dangerous for the StructuredViewer to be so restrictive (and even worse, not even document that restriction).
I looked at ILabelProvider: /** * Returns the text for the label of the given element. * * @param element the element for which to provide the label text * @return the text string used to label the element, or <code>null</code> * if there is no text label for the given object */ public String getText(Object element); If we don't say that null is allowed for 'element', it is not allowed. IStructuredContentProvider does not explicitly allow null elements. We could make that more obvious in the Javadoc though.
When we talk about databinding the situation and the Null-Object-Pattern. A simple converter could be used to keep the model free from these JFace pecularity, not? Maybe it would be a better fit to provide a standard way at this level? Or we could provide to implement the Null-Object pattern somehow at JFace-level?
Hitesh is now responsible for watching bugs in the [Viewers] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
