ModelData and displayProperty

[zaccret]

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();
in a Model interface, a
public Object getSortValue(); in a SortableModel sub-interface, etc...
Other possibility would be that model-based components rely on a ModelDisplayProvider class with a
public String getDisplayText(M model); Would it be possible to slightly reconsider/enhance the Model API ? Thoughts ?

[gslender]

+1

[sdc]

About the displayProperty, other idea here : http://extjs.com/forum/showthread.php?p=184202#post184202

[sdc]

Actually, it is the same idea (ModelDisplayProvider)

[flow]

+1

[assassin]

+1

[zaccret]

Darell, what is your opinion on that point ?

[sdc]

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).

[zaccret]

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.

[abickford]

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.

[sdc]

Hi guys,

I've post a feature request (http://extjs.com/forum/showthread.php?p=22579) for that point. There is already a solution for ComboBox.

[zaccret]

I think the right link is : http://extjs.com/forum/showthread.php?t=46670