Databinding of a matrix model with a TableViewer [message #849092] |
Wed, 18 April 2012 22:02 |
|
Hello!
I have a model that represents a matrix. Instances will contain a list of columns which in turn contain lists of values.
I would like to view and edit this model with a JFace TableViewer using EMF-databinding but there is a problem: I can't find a property that does what I need.
I managed to use the EMFEditProperties with a TableViewer for the special case of a matrix with a single column (you may call it a list):
The IListProperty I get from
o.e.emf.databinding.edit.EMFEditProperties.list(EditingDomain, EStructuralFeature) gives me a property I can use to observe such a list-model. The resulting IObservableList can be used as an input for a TableViewer with a single TableViewerColumn that uses the ColumnLabelProvider and ColumnEditingSupport.
In that case I can simply use the ObservableListContentProvider for the TableViewer.
But what do I do with lists of lists?
I tried FeaturePaths and custom LabelProviders/ContentProviders but couldn't get it to work. Maybe I need my own SimpleListProperty? Or a different widget?
I was surprised that I couldn't find anything useful about matrices and EMF-databinding. Is this completely unfeasible or just so simple that nobody bothers writing a tutorial?
Thanks in advance!
Max
PS: I could imagine this would be easier with rows instead of columns in the model, as the IStructuredContentProvider works on rows, but unfortunately I will need columns.
|
|
|
|
Re: Databinding of a matrix model with a TableViewer [message #868773 is a reply to message #849517] |
Wed, 02 May 2012 14:15 |
|
Thanks for your reply Tom, the problem is fixed now.
For future reference:
I wanted to show and edit a column-based matrix model in a TableViewer using standard EMF databinding.
So I created a row-based proxy-model that would work with the databinding, but wraps the column-based model. Whenever I access the values, e.g. in LabelProvider or EditingSupport, I would use the column-based model. This works because every row knows its index within the matrix and can then access the according entry within each column.
The resulting code looks rather messy, which is why I would recommend everyone to use a row-based model if you have a choice. On the bright side it scales well up to at least a 100x100 matrix.
|
|
|
|
Powered by
FUDForum. Page generated in 0.04293 seconds