Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » An interesting master-detail-scenario
An interesting master-detail-scenario [message #1245329] Thu, 13 February 2014 16:51 Go to next message
Emre T is currently offline Emre TFriend
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. Smile) 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 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
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
>
Re: An interesting master-detail-scenario [message #1247783 is a reply to message #1245848] Sun, 16 February 2014 16:04 Go to previous message
Emre T is currently offline Emre TFriend
Messages: 119
Registered: April 2013
Senior Member
Hello again,

Christophe Bouhier wrote on Fri, 14 February 2014 05:52

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



thanks for this tip. I was also trying a similar approach, but without a ComputedList, in which I was building a List of IObservabeValues that I later give to my TableViewer as an Input. Eventually it worked.

So now the next step, the inputs have to be able to be edited and the data binding needs to be supported by the EditingDomain.

Best regards,
Emre
Previous Topic:No exceptions when importing an XMI with abstract classes
Next Topic:howto: "The chosen operation is not currently available"
Goto Forum:
  


Current Time: Sat Dec 14 08:04:00 GMT 2019

Powered by FUDForum. Page generated in 0.01470 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top