Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Observing derived features
Observing derived features [message #425369] Sat, 22 November 2008 19:03 Go to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 676
Registered: July 2009
Senior Member
Hey,

I'm trying to create a list based view on a derived feature.

I guess that since it is derived I won't get any notifications for that
feature unless I manually create such notifications somewhere?

In this case I would let the eObjects under consideration somehow adapt
themselves:
- Internally observe all features that the derived feature depends on
- Upon change recompute the derived feature value
- 'Somehow' generate a notification event for the derived feature

Is this the approach to take, and if so, how can I generate the
notification in step 3?

Thanks, Felix
Re: Observing derived features [message #425370 is a reply to message #425369] Sat, 22 November 2008 19:30 Go to previous messageGo to next message
Liviu-Marian Negrila is currently offline Liviu-Marian NegrilaFriend
Messages: 53
Registered: July 2009
Member
Hi

By 'derived feature' you mean simply something that extends
EStructuralFeature somehow?

Or maybe you have entity A that has a List of B's
And C extends B
and you would like to show the list of B that are also C's and belong to A ?

Don't even know if I can help. Should my question seem silly maybe I'm
of no use to you.

Liviu

Felix Dorner wrote:
> Hey,
>
> I'm trying to create a list based view on a derived feature.
>
> I guess that since it is derived I won't get any notifications for that
> feature unless I manually create such notifications somewhere?
>
> In this case I would let the eObjects under consideration somehow adapt
> themselves:
> - Internally observe all features that the derived feature depends on
> - Upon change recompute the derived feature value
> - 'Somehow' generate a notification event for the derived feature
>
> Is this the approach to take, and if so, how can I generate the
> notification in step 3?
>
> Thanks, Felix
Re: Observing derived features [message #425371 is a reply to message #425370] Sat, 22 November 2008 19:34 Go to previous messageGo to next message
Liviu-Marian Negrila is currently offline Liviu-Marian NegrilaFriend
Messages: 53
Registered: July 2009
Member
Or maybe derived feature = computed attribute (at runtime or otherwise
not contained in your entity aka emf class)?



Liviu wrote:
> Hi
>
> By 'derived feature' you mean simply something that extends
> EStructuralFeature somehow?
>
> Or maybe you have entity A that has a List of B's
> And C extends B
> and you would like to show the list of B that are also C's and belong to A ?
>
> Don't even know if I can help. Should my question seem silly maybe I'm
> of no use to you.
>
> Liviu
>
> Felix Dorner wrote:
>> Hey,
>>
>> I'm trying to create a list based view on a derived feature.
>>
>> I guess that since it is derived I won't get any notifications for that
>> feature unless I manually create such notifications somewhere?
>>
>> In this case I would let the eObjects under consideration somehow adapt
>> themselves:
>> - Internally observe all features that the derived feature depends on
>> - Upon change recompute the derived feature value
>> - 'Somehow' generate a notification event for the derived feature
>>
>> Is this the approach to take, and if so, how can I generate the
>> notification in step 3?
>>
>> Thanks, Felix
Re: Observing derived features [message #425372 is a reply to message #425371] Sat, 22 November 2008 20:21 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 676
Registered: July 2009
Senior Member
Hey,

> Or maybe derived feature = computed attribute (at runtime or otherwise
> not contained in your entity aka emf class)?

yeah this one. By derived I mean formally an attribute that
is simply computed from other attributes, something that doesn't add information
to an object. As a stupid example, consider a class 'Library' which has a list
of 'Books', each having an 'Author'. A derived feature for a 'Library' would for
example be 'allAuthors' which would simply be the set of all authors of which
the library has at least one book...
Re: Observing derived features [message #425373 is a reply to message #425369] Sat, 22 November 2008 21:34 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30896
Registered: July 2009
Senior Member
Felix,

Comments below.

Felix Dorner wrote:
> Hey,
>
> I'm trying to create a list based view on a derived feature.
>
> I guess that since it is derived I won't get any notifications for
> that feature unless I manually create such notifications somewhere?
If you use a "normal" list implementation, when you update it, it will
notify as normal.
>
> In this case I would let the eObjects under consideration somehow adapt
> themselves:
If you override eNotificationRequired to return true, eNotify will
always be called, so you could use that to for the object to adapt itself.
> - Internally observe all features that the derived feature depends on
> - Upon change recompute the derived feature value
> - 'Somehow' generate a notification event for the derived feature
You could just modify the list and have it notify as normal.
>
> Is this the approach to take, and if so, how can I generate the
> notification in step 3?
>
> Thanks, Felix
Re: Observing derived features [message #425381 is a reply to message #425372] Sun, 23 November 2008 12:12 Go to previous messageGo to next message
Liviu-Marian Negrila is currently offline Liviu-Marian NegrilaFriend
Messages: 53
Registered: July 2009
Member
This is a multi-part message in MIME format.
--------------090305090402000709030001
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Felix Dorner wrote:
>
> Hey,
>
>> Or maybe derived feature = computed attribute (at runtime or otherwise
>> not contained in your entity aka emf class)?
>
> yeah this one. By derived I mean formally an attribute that
> is simply computed from other attributes, something that doesn't add
> information
> to an object. As a stupid example, consider a class 'Library' which has
> a list of 'Books', each having an 'Author'. A derived feature for a
> 'Library' would for example be 'allAuthors' which would simply be the
> set of all authors of which the library has at least one book...
>
Particulary for this kind of things, when I needed to create a list of
somethings filtered and ordererd and stuff I would relay on HQL for the
query, take the results and create a dinamic EClass (whose name is
variable) that has a single attribute "elements".
We instantiate the class and have the list of objects here.
For the "main" (aka leader, Library like object) we put on it an adapter
that notifies the dinamic object an all changes.

See the attachment for some hints.

Your example looks like a HQL left join with some restrictions.


Dont know if it helps but I guess Ed already answered your question.

Regards
Liviu


--------------090305090402000709030001
Content-Type: text/plain;
name="EmfUtils.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="EmfUtils.java"

package ro.spad.core.utils;

import java.util.HashMap;
import java.util.Map;

import org.eclipse.emf.ecore.EClass;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.ecore.EPackage;
import org.eclipse.emf.ecore.EReference;
import org.eclipse.emf.ecore.EStructuralFeature;
import org.eclipse.emf.ecore.ETypedElement;
import org.eclipse.emf.ecore.EcoreFactory;

public class EmfUtils {

private static Map<String, EClass> map = new HashMap<String, EClass>();
private static final String LISTA_ELEMENTE = "listaElemente";

public static EPackage eDynaSpadPackage = EcoreFactory.eINSTANCE.createEPackage();
{
eDynaSpadPackage.setName("dynaspad");
eDynaSpadPackage.setNsPrefix("dynaspad");
eDynaSpadPackage.setNsURI("http://www.spad.ro/dynaspad");
}


public static EObject createDummyListContainingEmfObject(EClass type)
{
final EcoreFactory efactory = EcoreFactory.eINSTANCE;

String className = getClassName(type);
EClass dummyListContainerClass;
if (!map.containsKey(className)){
dummyListContainerClass = efactory.createEClass();
dummyListContainerClass.setName(className);

EReference listaElementeReference = efactory.createEReference();
listaElementeReference.setName(LISTA_ELEMENTE);
listaElementeReference.setEType(type);
listaElementeReference.setContainment(false);
listaElementeReference.setLowerBound(0);
listaElementeReference.setUpperBound(ETypedElement.UNBOUNDED _MULTIPLICITY);
listaElementeReference.setUnique(false);

dummyListContainerClass.getEStructuralFeatures().add(listaEl ementeReference);

eDynaSpadPackage.getEClassifiers().add(dummyListContainerCla ss);

EPackage.Registry.INSTANCE.put(eDynaSpadPackage.getNsURI(), eDynaSpadPackage);

map.put(className, dummyListContainerClass);
}else{
dummyListContainerClass = map.get(className);
}

return eDynaSpadPackage.getEFactoryInstance().create(dummyListConta inerClass);

}

private static String getClassName(EClass type)
{
return "DummyListContaining"+type.getName();
}

public static EStructuralFeature getFirstStructuralFeature(EObject eObject, String featureName){
return (EStructuralFeature)eObject.eClass().getEStructuralFeature(f eatureName);
}

public static EReference getListaElementeStructuralFeatureFromDynaSPAD(EObject eObject){
return (EReference) getFirstStructuralFeature(eObject, LISTA_ELEMENTE);
}

}

--------------090305090402000709030001--
Re: Observing derived features [message #425382 is a reply to message #425373] Sun, 23 November 2008 14:56 Go to previous messageGo to next message
Felix Dorner is currently offline Felix DornerFriend
Messages: 676
Registered: July 2009
Senior Member
Hey Ed,

>> I'm trying to create a list based view on a derived feature.
>>
>> I guess that since it is derived I won't get any notifications for
>> that feature unless I manually create such notifications somewhere?
> If you use a "normal" list implementation, when you update it, it will
> notify as normal.

Hmm by this you mean something that implements ENotifyingList? I guess I
could set 'volatile' to false and use the generated getter as a starting
point. I guess it might be a good idea to finally return an unmodifiable
list though as it makes no sense for a client to externally change its
contents.

> If you override eNotificationRequired to return true, eNotify will
> always be called, so you could use that to for the object to adapt itself.

So that eNotify would look somehow like this:

eNotify(Notification n){
super.eNotify(n); // first play just normal
if (mustUpdateDerived(n)){ // do i need to update derived feature?
updateDerived(n); // modify the derived feature.
}
}

calling 'updateDerived' would modify the NotifyingList, so eNotify would
be invoked again. Now the observers of the derived feature will get
notified and the mustUpdateDerived() guard would be jumped over,
otherwise I'd provoke an infinite loop. Maybe this could be improved but
I just hope i got the pattern.

Thanks a lot.
Felix
Re: Observing derived features [message #425392 is a reply to message #425382] Mon, 24 November 2008 13:07 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30896
Registered: July 2009
Senior Member
Felix,

Comments below.

Felix Dorner wrote:
> Hey Ed,
>
>>> I'm trying to create a list based view on a derived feature.
>>>
>>> I guess that since it is derived I won't get any notifications for
>>> that feature unless I manually create such notifications somewhere?
>> If you use a "normal" list implementation, when you update it, it
>> will notify as normal.
>
> Hmm by this you mean something that implements ENotifyingList? I guess
> I could set 'volatile' to false and use the generated getter as a
> starting point.
Yes.
> I guess it might be a good idea to finally return an unmodifiable list
> though as it makes no sense for a client to externally change its
> contents.
Yes, using something like EcoreEList.Unmodifiable.
>
>> If you override eNotificationRequired to return true, eNotify will
>> always be called, so you could use that to for the object to adapt
>> itself.
>
> So that eNotify would look somehow like this:
>
> eNotify(Notification n){
> super.eNotify(n); // first play just normal
> if (mustUpdateDerived(n)){ // do i need to update derived feature?
> updateDerived(n); // modify the derived feature.
> }
> }
>
> calling 'updateDerived' would modify the NotifyingList, so eNotify would
> be invoked again.
Yes.
> Now the observers of the derived feature will get notified and the
> mustUpdateDerived() guard would be jumped over, otherwise I'd provoke
> an infinite loop.
You would want to derive from your own value. :-P
> Maybe this could be improved but I just hope i got the pattern.
The XSD model uses this pattern.
>
> Thanks a lot.
> Felix
>
>
>
Previous Topic:[Transactions] Deadlock using WorkspaceSynchronizer.Delegate
Next Topic:Updating Link's label
Goto Forum:
  


Current Time: Sun Feb 23 02:44:33 GMT 2020

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

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

Back to the top