Home » Modeling » EMF » An interesting master-detail-scenario
| An interesting master-detail-scenario [message #1245329] |
Thu, 13 February 2014 16:51  |
 Emre T
Messages: 119
Registered: April 2013 |
Senior Member |
|
|
Hello,
I hope, that I could get some help here regarding the following situation.
I have partially implemented a master-detail-scenario in a special kind of EMF data binding. The EMF data binding is because of two reasons different from the ones with fix models and fixed features that can be binded between model and UI directly over their package Literal names, such as XYZPackage.Literals.MODELA__FEATUREB
First of all, I need to bind certain EStructuralFeatures/EAttributes that are not known to the time of model definition. The case is very similar to UML Stereotype mechanism, as implemented in Papyrus.
The second hook is, that the master and detail parts are not based on the same model element. It is kind of an inheritance/containment, though how this is realized in the background I don't know. I will try to explain it further.
Lets say, that the master is set to a model element called TestApplication. I listen to these elements from a TreeViewer. On the other hand the detail should be set to another model element called Test, from which the EAttributes should accessed and shown in a TableVieser.
When eClass() on the TestApplication is called the Test is returned. (This is the part where I actually do not understand the mechanism, but it is so.  ) And finally, TestApplication has a method called getTest() which returns the corresponding Test element, in which the features exist, I want to get into my table viewer.
Formerly, when I had the master directly set as the Test model element, I was using the following IObservarbleList as the Input into the TableViewer:
private static WritableValue master = new WritableValue();
IObservableList masters = EMFEditObservables.observeDetailList(Realm.getDefault(), editingDomain, master, Literals.ECLASS__EALL_ATTRIBUTES);
tableViewer.setInput(masters);
And with the various LabelProviderfor TableColumns I was getting the desired EAttributes shown in the TableViewer.
But this was problematic, since the master should have been set to TestApplication, to allow the differentiating the elements in the TreeViewer, where the selection of the master happens.
So after setting the master as TestApplication, the right selections occur in the TreeViewer, but somehow I couldn't build the missing link between TestApplication and Test into the databinding scenario, so that the detail could be set as Test, while master is still the TestApplication.
I hope I was clear enough and you could point me to the right direction.
Thank you vevry much!
Emre
|
|
|
| Re: An interesting master-detail-scenario [message #1245848 is a reply to message #1245329] |
Fri, 14 February 2014 10:52  |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 13-02-14 17:51, Emre T wrote:
> Hello,
>
> I hope, that I could get some help here regarding the following situation.
Hi Emre,
I am sorry, I don't understand your question very well. I really don't
want to understand the complexities of your model. But what I read it
sounds like observing a selection in one viewer and binding this
observer to another viewer, with potentially some conversion in between.
What i can say, is that you can observe selections with:
1. private IViewerObservableValue observeSelection;
2. observeSelection = ViewersObservables.observeMultiSelection(Viewer
v); // Your super cool treeviewer here.
3. // here you have a few options, which is not very clear from your case.
3.1 // bind your table viewer directly with the selection observer.
.... // tableviewer binding stuff for content and label provider.
tableviewer.setInput(observeSingelSelection);
3.2 // You can do an intermediate step here, by producing a computed //
list from the selection observer which could look like this:
computedList = new ComputedList() {
@SuppressWarnings("unchecked")
@Override
protected List<Object> calculate() {
List<Object> result ....
for (Object value : observeSelection) {
result.add(...stuff derived from value)
}
return result;
}
};
... // tableviewer binding stuff for content and label provider.
tableViewer.setInput(computedList);
IRHTH.
Cheers Christophe
>
> I have partially implemented a master-detail-scenario in a special kind
> of EMF data binding. The EMF data binding is because of two reasons
> different from the ones with fix models and fixed features that can be
> binded between model and UI directly over their package Literal names,
> such as XYZPackage.Literals.MODELA__FEATUREB
>
> First of all, I need to bind certain EStructuralFeatures/EAttributes
> that are not known to the time of model definition. The case is very
> similar to UML Stereotype mechanism, as implemented in Papyrus.
> The second hook is, that the master and detail parts are not based on
> the same model element. It is kind of an inheritance/containment, though
> how this is realized in the background I don't know. I will try to
> explain it further.
>
> Lets say, that the master is set to a model element called
> TestApplication. I listen to these elements from a TreeViewer. On the
> other hand the detail should be set to another model element called
> Test, from which the EAttributes should accessed and shown in a
> TableVieser.
> When eClass() on the TestApplication is called the Test is returned.
> (This is the part where I actually do not understand the mechanism, but
> it is so. :)) And finally, TestApplication has a method called getTest()
> which returns the corresponding Test element, in which the features
> exist, I want to get into my table viewer.
>
> Formerly, when I had the master directly set as the Test model element,
> I was using the following IObservarbleList as the Input into the
> TableViewer:
>
>
> private static WritableValue master = new WritableValue();
>
> IObservableList masters =
> EMFEditObservables.observeDetailList(Realm.getDefault(), editingDomain,
> master, Literals.ECLASS__EALL_ATTRIBUTES);
>
> tableViewer.setInput(masters);
>
> And with the various LabelProviderfor TableColumns I was getting the
> desired EAttributes shown in the TableViewer.
>
> But this was problematic, since the master should have been set to
> TestApplication, to allow the differentiating the elements in the
> TreeViewer, where the selection of the master happens.
>
> So after setting the master as TestApplication, the right selections
> occur in the TreeViewer, but somehow I couldn't build the missing link
> between TestApplication and Test into the databinding scenario, so that
> the detail could be set as Test, while master is still the TestApplication.
>
> I hope I was clear enough and you could point me to the right direction.
>
> Thank you vevry much!
>
> Emre
>
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 15:47:19 GMT 2024
Powered by FUDForum. Page generated in 0.03506 seconds |
] 
Search
Help
Register
Login
Home
