|
|
|
|
| Re: Observing derived features [message #425373 is a reply to message #425369] |
Sat, 22 November 2008 21:34   |
 Ed Merks
Messages: 33137
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Observing derived features [message #425381 is a reply to message #425372] |
Sun, 23 November 2008 12:12 |
Liviu-Marian Negrila
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 #425392 is a reply to message #425382] |
Mon, 24 November 2008 13:07 |
Ed Merks
Messages: 33137
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
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03320 seconds
] 
Search
Help
Register
Login
Home
