Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Create own PropertyDescriptor
Create own PropertyDescriptor [message #1237435] Wed, 29 January 2014 18:17 Go to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Hi,

I want to create my own dialog instead the standard property descriptor. This dialog should include two buttons for adding and deleting elements. The elements are the following:

class FM{
  unsettable attr EString name = "FM";
  
  ref Constraint[*] internalConstraints;
}

class Constraint{
  unsettable attr ConstraintType constraintType;
	
  ref Feat[1] source;
  ref Feat[1] target; 
}


I want to be able, to assign/delete objects of Constraints to FM during the dialog is open.

I've already created this dialog, but I've no clue how to add or delete objects to each other without breaking the emf rules.

My strategy so far was to create the according objects and then use the AddCommand/RemoveCommand to save them (fm and constraint are objects in this case):

EditingDomain editingDomain = org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.getEditingDomainFor(fm);										
Command cmdRequiredConstraint = AddCommand.create(editingDomain, fm, PldPackage.Literals.F_M__INTERNAL_CONSTRAINTS, constraint);
editingDomain.getCommandStack().execute(cmdRequiredConstraint);


As you can see in the following images, the constraints are assigned to FM, but it doesn't seems to be persisted in the file..Can anyone help me with this?

index.php/fa/17358/0/
  • Attachment: Unbenannt.JPG
    (Size: 15.75KB, Downloaded 241 times)
Re: Create own PropertyDescriptor [message #1237689 is a reply to message #1237435] Thu, 30 January 2014 10:30 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 29-01-14 19:17, Phil H wrote:
> Hi,
>
> I want to create my own dialog instead the standard property descriptor. This dialog should include two buttons for adding and deleting elements. The elements are the following:
>
>
> class FM{
> unsettable attr EString name = "FM";
>
> ref Constraint[*] internalConstraints;
> }
>
> class Constraint{
> unsettable attr ConstraintType constraintType;
>
> ref Feat[1] source;
> ref Feat[1] target;
> }
>
>
> I want to be able, to assign/delete objects of Constraints to FM during the dialog is open.
>
> I've already created this dialog, but I've no clue how to add or delete objects to each other without breaking the emf rules.
>
> My strategy so far was to create the according objects and then use the AddCommand/RemoveCommand to save them (fm and constraint are objects in this case):
>
>
> EditingDomain editingDomain = org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.getEditingDomainFor(fm);
> Command cmdRequiredConstraint = AddCommand.create(editingDomain, fm, PldPackage.Literals.F_M__INTERNAL_CONSTRAINTS, constraint);
> editingDomain.getCommandStack().execute(cmdRequiredConstraint);
>
This looks OK.

>
> As you can see in the following images, the constraints are assigned to FM, but it doesn't seems to be persisted in the file..Can anyone help me with this?
>
You are almost there. the final step is to save the 'container' holding
the fm object. I would expect the fm object to stored in an EMF
Resource. If so, calling the resource.save([options...]) will persist
your change. I would really recommend to study a generator Editor for
your model. It contains *all* the concepts dealing with persistence of
EMF. ( save/saveAs methods).

>
Re: Create own PropertyDescriptor [message #1237719 is a reply to message #1237689] Thu, 30 January 2014 12:11 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Thx for your help so far, but I still have some questions

Quote:

I would really recommend to study a generator Editor for your model. It contains *all* the concepts dealing with persistence of EMF. ( save/saveAs methods).


What do you mean by generator Editor? Are there any articles/links describing this? Or do you mean I should take a look at a generated class inside my EMF/GMF project?

Quote:

You are almost there. the final step is to save the 'container' holding the fm object. I would expect the fm object to stored in an EMF Resource. If so, calling the resource.save([options...]) will persist your change.


So I added the following lines of code after my AddCommand:

....
editingDomain.getCommandStack().execute(cmdRequiredConstraint);
										
Resource res = editingDomain.getResourceSet().getResources().get(0);
try {
  res.save(null);
} 
catch (IOException e) {
  e.printStackTrace();
}


But then I get the following warning, which I don't really understand:

index.php/fa/17371/0/

When I'm adding another constraint, I get this error, which wasn't there before:

java.lang.NullPointerException
	at org.eclipse.emf.edit.command.AddCommand.create(AddCommand.java:93)
	at org.eclipse.emf.edit.command.AddCommand.create(AddCommand.java:66)
	at property.sheet.internalConstraint.ConstraintDialog$1.widgetSelected(ConstraintDialog.java:165)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:826)
	at org.eclipse.jface.window.Window.open(Window.java:802)


Am I persisting the resource wrong?
  • Attachment: Unbenannt.JPG
    (Size: 33.56KB, Downloaded 237 times)
Re: Create own PropertyDescriptor [message #1237740 is a reply to message #1237719] Thu, 30 January 2014 13:19 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 30-01-14 13:11, Phil H wrote:
> Thx for your help so far, but I still have some questions
>
> Quote:
>> I would really recommend to study a generator Editor for your model. It contains *all* the concepts dealing with persistence of EMF. ( save/saveAs methods).
>
>
> What do you mean by generator Editor? Are there any articles/links describing this? Or do you mean I should take a look at a generated class inside my EMF/GMF project?
>
I mean the generated editor, which you seem to be using judging from the
warning you get. I think I understand your use case slightly better.
What happens is that the resource is already in use and loaded in your
..xyz editor. Then if you load the resource explicitly and save it, the
editor will detect this and show the warning.

So I think you should obtain your editing domain from the editor which
implements: IEditingDomainProvider and execute the AddCommand on the
stack of that Editingdomain. I am not very familiar with the
getEditingDomain() code in AdapterFactory, but you could debug this and
see what happens. (Is it the same editingdomain as the one used by the
editor).



> Quote:
>> You are almost there. the final step is to save the 'container' holding the fm object. I would expect the fm object to stored in an EMF Resource. If so, calling the resource.save([options...]) will persist your change.
>
>
> So I added the following lines of code after my AddCommand:
>
>
> ...
> editingDomain.getCommandStack().execute(cmdRequiredConstraint);
>
> Resource res = editingDomain.getResourceSet().getResources().get(0);
> try {
> res.save(null);
> }
> catch (IOException e) {
> e.printStackTrace();
> }
>
>
> But then I get the following warning, which I don't really understand:
>
>
>
> When I'm adding another constraint, I get this error, which wasn't there before:
>
>
> java.lang.NullPointerException
> at org.eclipse.emf.edit.command.AddCommand.create(AddCommand.java:93)
> at org.eclipse.emf.edit.command.AddCommand.create(AddCommand.java:66)
> at property.sheet.internalConstraint.ConstraintDialog$1.widgetSelected(ConstraintDialog.java:165)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:826)
> at org.eclipse.jface.window.Window.open(Window.java:802)
>
>
> Am I persisting the resource wrong?
>
Re: Create own PropertyDescriptor [message #1237744 is a reply to message #1237740] Thu, 30 January 2014 13:21 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
One more thing, what I normally do is close the dialog without
persisting. The editor will be dirty (As notified by the command stack)
and then a regular editor save will persist your added objects. (But
this all have to be on the same editing domain).

On 30-01-14 14:19, Christophe Bouhier wrote:
> On 30-01-14 13:11, Phil H wrote:
>> Thx for your help so far, but I still have some questions
>>
>> Quote:
>>> I would really recommend to study a generator Editor for your model.
>>> It contains *all* the concepts dealing with persistence of EMF. (
>>> save/saveAs methods).
>>
>>
>> What do you mean by generator Editor? Are there any articles/links
>> describing this? Or do you mean I should take a look at a generated
>> class inside my EMF/GMF project?
>>
> I mean the generated editor, which you seem to be using judging from the
> warning you get. I think I understand your use case slightly better.
> What happens is that the resource is already in use and loaded in your
> .xyz editor. Then if you load the resource explicitly and save it, the
> editor will detect this and show the warning.
>
> So I think you should obtain your editing domain from the editor which
> implements: IEditingDomainProvider and execute the AddCommand on the
> stack of that Editingdomain. I am not very familiar with the
> getEditingDomain() code in AdapterFactory, but you could debug this and
> see what happens. (Is it the same editingdomain as the one used by the
> editor).
>
>
>
>> Quote:
>>> You are almost there. the final step is to save the 'container'
>>> holding the fm object. I would expect the fm object to stored in an
>>> EMF Resource. If so, calling the resource.save([options...]) will
>>> persist your change.
>>
>>
>> So I added the following lines of code after my AddCommand:
>>
>>
>> ...
>> editingDomain.getCommandStack().execute(cmdRequiredConstraint);
>>
>> Resource res = editingDomain.getResourceSet().getResources().get(0);
>> try {
>> res.save(null);
>> }
>> catch (IOException e) {
>> e.printStackTrace();
>> }
>>
>>
>> But then I get the following warning, which I don't really understand:
>>
>>
>>
>> When I'm adding another constraint, I get this error, which wasn't
>> there before:
>>
>>
>> java.lang.NullPointerException
>> at org.eclipse.emf.edit.command.AddCommand.create(AddCommand.java:93)
>> at org.eclipse.emf.edit.command.AddCommand.create(AddCommand.java:66)
>> at
>> property.sheet.internalConstraint.ConstraintDialog$1.widgetSelected(ConstraintDialog.java:165)
>>
>> at
>> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
>> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
>> at
>> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
>> at org.eclipse.jface.window.Window.runEventLoop(Window.java:826)
>> at org.eclipse.jface.window.Window.open(Window.java:802)
>>
>>
>> Am I persisting the resource wrong?
>>
>
Re: Create own PropertyDescriptor [message #1237781 is a reply to message #1237744] Thu, 30 January 2014 15:22 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Quote:

One more thing, what I normally do is close the dialog without persisting. The editor will be dirty (As notified by the command stack) and then a regular editor save will persist your added objects. (But this all have to be on the same editing domain).


That's what I orginally have done... I used the Add/RemoveCommand to assign the objects and later it should be persisted by a editor save. I used this code to get the editingDomain, as I didn't know a better way (notice that the object fm already exist in the model, so normally I should get the right EditingDomain?):

EditingDomain editingDomain = org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.getEditingDomainFor(fm);


Using then the commands with this editingdomain should produce a correct model, or not?
Re: Create own PropertyDescriptor [message #1237788 is a reply to message #1237781] Thu, 30 January 2014 15:41 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 30-01-14 16:22, Phil H wrote:
> Quote:
>> One more thing, what I normally do is close the dialog without
>> persisting. The editor will be dirty (As notified by the command
>> stack) and then a regular editor save will persist your added objects.
>> (But this all have to be on the same editing domain).
>
>
> That's what I orginally have done... I used the Add/RemoveCommand to
> assign the objects and later it should be persisted by a editor save. I
> used this code to get the editingDomain, as I didn't know a better way
> (notice that the object fm already exist in the model, so normally I
> should get the right EditingDomain?):
>
>
> EditingDomain editingDomain =
> org.eclipse.emf.edit.domain.AdapterFactoryEditingDomain.getEditingDomainFor(fm);
>
>
>
> Using then the commands with this editingdomain should produce a correct
> model, or not?
Yes, so something else is wrong. I can't judge from the info you provided.
Re: Create own PropertyDescriptor [message #1238069 is a reply to message #1237788] Fri, 31 January 2014 10:11 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
That's the problem, I'm stucked with this for a while now..

Maybe you or someone else can tell me, what it mean when objects are shown inside the property window, like in the following image:

index.php/fa/17382/0/

Using then the save mechanism, I would expect that they are persisted in the file, but this is not the case..

So it seems that the reference exist inside some EMF cache, but for some reasons can't be persisted in the file.
  • Attachment: Unbenannt.JPG
    (Size: 16.78KB, Downloaded 223 times)
Re: Create own PropertyDescriptor [message #1238078 is a reply to message #1238069] Fri, 31 January 2014 10:41 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 31-01-14 11:12, Phil H wrote:
> That's the problem, I'm stucked with this for a while now..
>
> Maybe you or someone else can tell me, what it mean when objects are shown inside the property window, like in the following image:
>
Hi,

Maybe it's worth studying a bit how this works.
In a generated editor you will see this:

public IPropertySheetPage getPropertySheetPage() {
PropertySheetPage propertySheetPage =
new ExtendedPropertySheetPage(editingDomain) {
@Override
public void setSelectionToViewer(List<?> selection) {
ServicesEditor.this.setSelectionToViewer(selection);
ServicesEditor.this.setFocus();
}

@Override
public void setActionBars(IActionBars actionBars) {
super.setActionBars(actionBars);
getActionBarContributor().shareGlobalActions(this, actionBars);
}
};
propertySheetPage.setPropertySourceProvider(new
AdapterFactoryContentProvider(adapterFactory));
propertySheetPages.add(propertySheetPage);

return propertySheetPage;
}



so the propertysource is an EMF AdapterFactoryContentProvider
This can adapt an object to an IItemPropertySource for an object.
Eventually when changing a value the code in ItemProperyDescriptor is
called:

public void setPropertyValue(Object object, Object value)

this uses the EditingDomain obtained from the factory and a SetCommand
to modify the object.


>
>
> Using then the save mechanism, I would expect that they are persisted in the file, but this is not the case..
they are persisted! (You get a warning the file changed). but it seems a
different *process* is writing the file, hence the warning. this is the
part I have no insight in.. perhaps you can share how the dialog saves
the code.

>
> So it seems that the reference exist inside some EMF cache, but for some reasons can't be persisted in the file.
>
Re: Create own PropertyDescriptor [message #1238093 is a reply to message #1238078] Fri, 31 January 2014 11:24 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Thx for your help till now!

Just to clarify:

they are persisted! (You get a warning the file changed). but it seems a different *process* is writing the file, hence the warning. this is the part I have no insight in.. perhaps you can share how the dialog saves the code.


What do you mean with the last sentence? What code should be saved?

The warning only appeared, because I added the resource.save stuff, but this causes only problems and the regular save mechanism sufficient..So I removed it and now I don't get any warning or exceptions..

I can add properties and close the dialog..When I reopen the dialog, the properties are still there, which is what I want:

index.php/fa/17383/0/

When I close the editor then, it ask me for saving (so it recognizes that there has been changes in the model), which I answer with yes..but when I reopen the editor, the properties are not existing anymore:

index.php/fa/17384/0/

So in my eyes it seems that they are cached somewhere during runtime, but not persisted for some reasons
Re: Create own PropertyDescriptor [message #1238111 is a reply to message #1238093] Fri, 31 January 2014 12:22 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 31-01-14 12:24, Phil H wrote:
> Thx for your help till now!
>
> Just to clarify:
>
>
> they are persisted! (You get a warning the file changed). but it seems a different *process* is writing the file, hence the warning. this is the part I have no insight in.. perhaps you can share how the dialog saves the code.
>
>
> What do you mean with the last sentence? What code should be saved?
>
> The warning only appeared, because I added the resource.save stuff, but this causes only problems and the regular save mechanism sufficient..So I removed it and now I don't get any warning or exceptions..
>
> I can add properties and close the dialog..When I reopen the dialog, the properties are still there, which is what I want:
>
>
>
> When I close the editor then, it ask me for saving (so it recognizes that there has been changes in the model), which I answer with yes..but when I reopen the editor, the properties are not existing anymore:
>
and you are sure the save is succesfull? Do you see the change appear in
the resource? (If you open the file holding your model with a text
editor, would you see the XML or XMI holding with your change in it?
>
>
> So in my eyes it seems that they are cached somewhere during runtime, but not persisted for some reasons
yes, look at the content of the file with a text editor. you can also
debug the save method of the editor.. If the Command is wrong for some
reason which would lead to an invalid model, this could break the save.
>
Re: Create own PropertyDescriptor [message #1238587 is a reply to message #1238111] Sat, 01 February 2014 20:44 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
I don't get any error when saving, but I'm not sure how to prove that..Other references are persisted, so I would expect that the save mechanism in generally is working..What would be a hook to start debugging the save mechanism?

The constraints are not persisted in the file,a fter saving. They just appear in the editor during runtime. So there seems to be something corrupt with my AddCommand?!

I thought now a lot about this, but I can't figure out what I'm doing wrong. It can't be that hard to create object references in EMF..
Maybe I have to use something like a create command for my constraint object, before I assign it to the fm object via the AddCommand? Or maybe the AddCommand isn't sufficient for this?
Re: Create own PropertyDescriptor [message #1239124 is a reply to message #1238587] Mon, 03 February 2014 12:16 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 01-02-14 21:44, Phil H wrote:
> I don't get any error when saving, but I'm not sure how to prove
> that..Other references are persisted, so I would expect that the save
> mechanism in generally is working..What would be a hook to start
> debugging the save mechanism?

put a breakpoint in the save method of your generated editor could be a
start?

>
> The constraints are not persisted in the file,a fter saving. They just
> appear in the editor during runtime. So there seems to be something
> corrupt with my AddCommand?!
>
> I thought now a lot about this, but I can't figure out what I'm doing
> wrong. It can't be that hard to create object references in EMF..
> Maybe I have to use something like a create command for my constraint
> object, before I assign it to the fm object via the AddCommand? Or maybe
> the AddCommand isn't sufficient for this?
Yes, objects have to be created before added as a reference. How do you
obtain the Constraint objects?
Re: Create own PropertyDescriptor [message #1239284 is a reply to message #1239124] Mon, 03 February 2014 21:14 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Quote:
Yes, objects have to be created before added as a reference. How do you
obtain the Constraint objects?


I just create a normal java object and use this in my AddCommand... I don't use any commands for creating my Constraint object, maybe that's the problem? But I couldn't find any sufficient commands in the Command Framework for this case..
Re: Create own PropertyDescriptor [message #1239584 is a reply to message #1239284] Tue, 04 February 2014 14:30 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 03-02-14 22:14, Phil H wrote:
> Quote:
>> Yes, objects have to be created before added as a reference. How do
>> you obtain the Constraint objects?
>
>
> I just create a normal java object and use this in my AddCommand... I
> don't use any commands for creating my Constraint object, maybe that's
> the problem? But I couldn't find any sufficient commands in the Command
> Framework for this case..
You can create with the EMF Factory, but you will need to add to the
resource holding all your objects, otherwise the reference will be
dangling (To a non stored model object).
Re: Create own PropertyDescriptor [message #1239610 is a reply to message #1239584] Tue, 04 February 2014 15:42 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Ah sry, I forgot that I already use the factory:

constraint = PldFactory.eINSTANCE.createVariantConstraint();
constraint.setSource(sourceFeature);
constraint.setTarget(targetFeature);
constraint.setConstraintType(ConstraintType.REQUIRE);

Command cmdRequiredConstraint = AddCommand.create(editingDomain, fm, PldPackage.Literals.F_M__INTERNAL_CONSTRAINTS, constraint);
editingDomain.getCommandStack().execute(cmdRequiredConstraint);


That should be the right approach, or?

What do you mean with "you will need to add to the resource holding all your objects"?
Re: Create own PropertyDescriptor [message #1240028 is a reply to message #1239610] Wed, 05 February 2014 15:08 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 04-02-14 16:42, Phil H wrote:
> Ah sry, I forgot that I already use the factory:
>
>
> constraint = PldFactory.eINSTANCE.createVariantConstraint();
> constraint.setSource(sourceFeature);
> constraint.setTarget(targetFeature);
> constraint.setConstraintType(ConstraintType.REQUIRE);
>
> Command cmdRequiredConstraint = AddCommand.create(editingDomain, fm,
> PldPackage.Literals.F_M__INTERNAL_CONSTRAINTS, constraint);
> editingDomain.getCommandStack().execute(cmdRequiredConstraint);
>
Here you add the constraint object to the fm object's feature named:
PldPackage.Literals.F_M__INTERNAL_CONSTRAINTS

You are not adding it to a Resource which holds your object, which is
needed for non-containment references. I have asked before, is the
EReference a containment reference?

>
> That should be the right approach, or?
>
> What do you mean with "you will need to add to the resource holding all
> your objects"?
Re: Create own PropertyDescriptor [message #1240106 is a reply to message #1240028] Wed, 05 February 2014 18:06 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Oh, you're maybe right. It's a non-containment reference, as shown here:

class FM{
  unsettable attr EString name = "FM";
  
  ref Constraint[*] internalConstraints;
}

class Constraint{
  unsettable attr ConstraintType constraintType;
	
  ref Feat[1] source;
  ref Feat[1] target; 
}


But for what reason is emf generating then F_M__INTERNAL_CONSTRAINTS ? This is the only reference between this two classes..

So constraint has only the reference to FM and no containment reference..Which is then the resurce which holds my object? I already searched for examples, but couldn't find any good explanation.. In the following there is snippet from my metamodel:

index.php/fa/17409/0/
  • Attachment: Unbenannt.JPG
    (Size: 24.82KB, Downloaded 183 times)

[Updated on: Wed, 05 February 2014 18:07]

Report message to a moderator

Re: Create own PropertyDescriptor [message #1240348 is a reply to message #1240106] Thu, 06 February 2014 09:15 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 05-02-14 19:06, Phil H wrote:
> Oh, you're maybe right. It's a non-containment reference, as shown here:
Sorry, I am not familiar with xcore. In the Ecore you can see it in the
properties.
>
>
> class FM{
> unsettable attr EString name = "FM";
>
> ref Constraint[*] internalConstraints;
> }
>
> class Constraint{
> unsettable attr ConstraintType constraintType;
>
> ref Feat[1] source;
> ref Feat[1] target;
> }
>
>
> But for what reason is emf generating then F_M__INTERNAL_CONSTRAINTS ? This is the only reference between this two classes..
Regardless if it's contained or not contained, a feature is generated
(also in the Literal format), as you specify this in your model. So to
answer your question: Because you told EMF to do so :P

The Resource can contain *any* EObject so the definition of a specific
feature is not needed to hold objects in Resource.
>
> So constraint has only the reference to FM and no containment reference.
Judging from the diagram, it's the other way around FM -> Contstraint.

..Which is then the resurce which holds my object?
You need to put it in the Resource opened by your editor. You can use an
ADD command for this also.

constraint = ...

myResource = ResourceSet.get(URI TO YOUR RESOURCE);
Command addToResource = new
AddCommand(editingService.getEditingDomain(),
myResource.getContents(),constraint);


a_command_stack.execute(addToResource)

have you tried this?

In the following there is snippet from my metamodel:
>
>
Re: Create own PropertyDescriptor [message #1240467 is a reply to message #1240348] Thu, 06 February 2014 14:31 Go to previous messageGo to next message
Phil H is currently offline Phil HFriend
Messages: 267
Registered: November 2012
Senior Member
Awesome, that did the trick - thanks!! Now I learned a little bit more about EMF.
Adding and removing works now like a charm.

Cheers,
Phil
Re: Create own PropertyDescriptor [message #1240482 is a reply to message #1240467] Thu, 06 February 2014 15:06 Go to previous message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 06-02-14 15:31, Phil H wrote:
> Awesome, that did the trick - thanks!! Now I learned a little bit more
> about EMF.
Great! the containment / non-containment principle is key to understand.

> Adding and removing works now like a charm.
>
> Cheers,
> Phil
>
Previous Topic:Opposite and many to many
Next Topic:[CDO/Dawn] Deadlocking w/ Display, Dawn's handleViewInvalidationEvent, & CDO's InvalidationRunna
Goto Forum:
  


Current Time: Sat Jul 22 09:22:19 GMT 2017

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

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