12 Jun 2008 6:02 AM #1
ModelData and displayProperty
Models (ModelData <- Model <- etc...) support a form of "instrospection" as property names (String) and values can be retrieved at runtime. I guess this is great at least for internal use.
But when it comes to write some models for ComboBox, Tree, etc, I don't see how it is useful.
I mean : to tell the component which text it must displays, the model must set a property (name/value) and the model user must tell the component what is the name of the property (by default it is "text" for ComboBox, for example). IMHO it is not a good constraint because :
- it is not type-safe
- it can easily cause typo errors
- it introduces coupling (the model user must know the internal behaviour of the model : what is the name of the display property)
I think it would be nice to have something like
public String getDisplayText();Code:
public Object getSortValue();
Other possibility would be that model-based components rely on a ModelDisplayProvider class with aCode:
public String getDisplayText(M model);
12 Jun 2008 12:14 PM #2
20 Jun 2008 3:22 AM #3
23 Jun 2008 9:45 PM #4
Actually, it is the same idea (ModelDisplayProvider)
24 Jun 2008 12:29 AM #5
24 Jun 2008 2:01 AM #6
3 Jul 2008 4:12 AM #7
22 Jul 2008 12:06 AM #8
Darell, JavaBean support is really really really nice !! But we still have to manage string properties (displayProperty for ComboBox, column ids for tables) to tell the widget how to display the text.
I think it would be a nice enhancement on the API to have objects (ModelDisplayProvider for ComboBox and for TableColumns ?) telling how to display text instead of setting the name of a property (not type-safe).
22 Jul 2008 2:05 AM #9
By the way, it was possible with the old Viewer API at least for trees. There was a LabelProvider class, which was equivalent to the ModelDisplayProvider we are talking about.
24 Jul 2008 5:11 AM #10
If i remember correctly that's how the API used to look. It was based off the JFace API from SWT. Now it's based of the store/binder/loader/proxy/model API of EXT. I believe it was a licensing issue involving the EPL.
I prefer the JFace API, the EXT one takes far too much work for even the simplest cases. It's also a little too 'clever' for me.