Home » Modeling » EMF » Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428464 is a reply to message #428455] |
Mon, 23 March 2009 12:00   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060705050205090007010106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
Comments below.
Daniel OKOUYA wrote:
> Hi all,
>
> I have the following case:
>
> In my model I have On top a Social Structure which contains roles
> which in turn contains objectives. However, Because Objective are
> unique in the model, The real Container of the objective is the Social
> Structure. Objective are Non-Contained-Child of Roles and Contained
> child of the Social Structure. I already manage the addition of new
> objective using a compound command, which when called from the role,
> add it both to the Social structure and the Role, avoiding de facto
> the "dangling Reference".
>
> My problem arises when I try to Delete this object and this is where
> please, I would require any advises: I want that when I delete an
> objective from a Role, if this Role or Non-Container Parent is the
> only one, then delete it both from the Role and its containing Parent
> which is the Social Structure. Otherwise, the object is removed only
> from the current Non-Containing-Parent.
>
> Please can any one give me some advise on how to implement it. The
> problem could be qualified as the general problem of managing shared
> global object locally as Non-contained-Child.
>
> To be more specific. I already tried implementing a version which as
> lead me to use ItemWrappers for the Non-contained-child. Those
> wrappers are created automatically in my RoleItemProvider. Meaning
> that IsWrappingNeeded always returns true.
>
>
> However I encountered problems when I tried to implement my own
> DeleteCommand called from my RoleItemProvider.
>
> It seams like The DeleteCommand in any case remove all Item even if
> the Item is a Warpper which is my problem. Indeed as I sated RemoveAll
> to true in The ActionBarContributor for the DeleteAction, It is the
> DeleteCommand which is used and is the general behavior I would like
> to have expect for Objective. However In its execution it does
> unwrap Item to find allUsage with a CrossReferencer. Meaning that, It
> does not focus on the Wrapper only but on what it represent. This
> situation has invalidate all the logic I have Implemented to check for
> the condition described above to comply to my the deletion criteria.
> Indeed with a wrapper, the getParent does not just yield the
> container. Using some crossReferencer I have been able to make the
> check discribed above.
> However I ended up with frustration as it was not working. After some
> debug, and looking into the the DeleteCommand I realize the behavior
> described earlier which in my opinion is the reason of my bug. Of
> course it might be anything else, that is why I'm open to any idea in
> that sense.
> Does any one have a good idea on how to implement this functionality?
> The only one that I see for now is :
>
> Using the Remove version of the DeleteAction, Implementing my own
> RemoveCommand specific for Each object called from my Items Providers,
> and use the EcoreUtil.delete when necessary. While the ides sounds
> ok. It is customizing the remove instead of customizing the delete. It
> seams to heavy and ugly to me. Therefore I think there might be
> another way.
There have certainly been quite set set of changes related to delete
command and what should all be deleted, with children being overlooked
at one point. I'm not entirely convinced looking at the code now that
we should ever be unwrapping objects. Perhaps we should have only been
checking instanceof EObject and only in that case do the delete all
references part... That probably addresses your issue right? I.e., if
we skipped the unwrapping step. Hnmmm.... But I think for feature map
entries we have wrappers, and they need to behave the way we have
currently. Maybe some improved factoring to make it easy to skip the
unwrapping would help...
>
>
> Please, do not hesitate on the suggestion.
>
>
--------------060705050205090007010106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel,<br>
<br>
Comments below.<br>
<br>
Daniel OKOUYA wrote:
<blockquote cite="mid:C5ECB24D.6527%25okouya_d@yahoo.fr" type="cite">
<title>Problem with Deletion : Managing Localy Shared global Object
as Non-contained-Child</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hi all, <br>
<br>
I have the following case: <br>
<br>
In my model I have On top a Social Structure which contains roles which
in turn contains objectives. However, Because Objective are unique in
the model, The real Container of the objective is the Social Structure.
Objective are Non-Contained-Child of Roles and Contained child of the
Social Structure. I already manage the addition of new objective using
a compound command, which when called from the role, add it both to
the Social structure and the Role, avoiding de facto the “dangling
Reference”.<br>
<br>
My problem arises when I try to Delete this object and this is where
please, I would require any advises: I want that when I delete an
objective from a Role, if this Role or Non-Container Parent is the only
one, then delete it both from the Role and its containing Parent which
is the Social Structure. Otherwise, the object is removed only from the
current Non-Containing-Parent.<br>
<br>
Please can any one give me some advise on how to implement it. The
problem could be qualified as the general problem of managing shared
global object locally as Non-contained-Child.<br>
<br>
To be more specific. I already tried implementing a version which as
lead me to use ItemWrappers for the Non-contained-child. Those
wrappers are created automatically in my RoleItemProvider. Meaning that
IsWrappingNeeded always returns true.<br>
<br>
<br>
However I encountered problems when I tried to implement my own
DeleteCommand called from my RoleItemProvider.<br>
<br>
It seams like The DeleteCommand in any case remove all Item even if the
Item is a Warpper which is my problem. Indeed as I sated RemoveAll to
true in The ActionBarContributor for the DeleteAction, It is the
DeleteCommand which is used and is the general behavior I would like
to have expect for Objective. However In its execution it does unwrap
Item to find allUsage with a CrossReferencer. Meaning that, It does not
focus on the Wrapper only but on what it represent. This situation has
invalidate all the logic I have Implemented to check for the condition
described above to comply to my the deletion criteria. Indeed with a
wrapper, the getParent does not just yield the container. Using some
crossReferencer I have been able to make the check discribed above.<br>
However I ended up with frustration as it was not working. After some
debug, and looking into the the DeleteCommand I realize the behavior
described earlier which in my opinion is the reason of my bug. Of
course it might be anything else, that is why I’m open to any idea in
that sense. <br>
Does any one have a good idea on how to implement this functionality?
The only one that I see for now is : <br>
<br>
Using the Remove version of the DeleteAction, Implementing my own
RemoveCommand specific for Each object called from my Items Providers,
and use the EcoreUtil.delete when necessary. While the ides sounds ok.
It is customizing the remove instead of customizing the delete. It
seams to heavy and ugly to me. Therefore I think there might be another
way.<br>
</span></font></blockquote>
There have certainly been quite set set of changes related to delete
command and what should all be deleted, with children being overlooked
at one point. I'm not entirely convinced looking at the code now that
we should ever be unwrapping objects. Perhaps we should have only been
checking instanceof EObject and only in that case do the delete all
references part... That probably addresses your issue right? I.e., if
we skipped the unwrapping step. Hnmmm.... But I think for feature map
entries we have wrappers, and they need to behave the way we have
currently. Maybe some improved factoring to make it easy to skip the
unwrapping would help... <br>
<blockquote cite="mid:C5ECB24D.6527%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
Please, do not hesitate on the suggestion.<br>
<br>
<br>
</span></font>
</blockquote>
</body>
</html>
--------------060705050205090007010106--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428473 is a reply to message #428472] |
Mon, 23 March 2009 14:01 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090809060709050307040203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
Comments below.
Daniel OKOUYA wrote:
> Sorry about the multiple post.
>
> Because, I like Things that are well engineer and well thought, and
> for the evolution of my application, I need to be sure my architecture
> and etc....
> So if you don't mind, I would like to do something, that is not going
> to be broken soon. Because, indeed, several month ago I contacted you
> about this problem and I'm pretty sure that my code was working. I
> don't know when was the update done, but it did change the behavior of
> my application.
I think it was ages ago.
> But in any case, I think the all point is to have a good
> interpretation of what should be
> DeleteCommand Behavior.
Of course different people might have different perceptions depending on
how they've used things.
>
> So please, for clarity:
>
> 1-/ What will or should be the actual behavior of the DELETECOMMAND.
> Semanticaly what you desicribe here:
>
> >>>>
> There have certainly been quite set set of changes related to delete
> command and what should all be deleted, with children being overlooked
> at one point. I'm not entirely convinced looking at the code now that
> we should ever be unwrapping objects. Perhaps we should have only
> been checking instanceof EObject and only in that case do the delete
> all references part... That probably addresses your issue right?
> I.e., if we skipped the unwrapping step. Hnmmm.... But I think for
> feature map entries we have wrappers, and they need to behave the way
> we have currently. Maybe some improved factoring to make it easy to
> skip the unwrapping would help...
> >>>>
>
> Means a behavior such as The object is not identified as being the
> object but as the reference of a Parent. Is it the desired behavior
> that you would like to have?
Other users might have a tree structure they induce with wrappers while
still wanting a delete to do the normal thing. When we realized delete
didn't properly delete references to children, we added support for
walking the children. In any case, the CVS history of the file is
public information you can inspect.
>
>
>
> 2-/ In the same line as what you said above concerning the
> refactoring you said in a preceding post I would like to ask :
>
> >>>>>
>
> 2-/ Then based on that, can anyone give me an advise about how
> to make sure that the delete only delete a wrapper and not the object
> everywhere else?
>
> You could specialize the editing domain's create
> command so that DeleteCommand is created only for non-wrappers and
> otherwise a remove command.
>
>
> 3-/ Also, how can I check that the actual item being selected is a
> wrapper, how does it works?
>
> You can check if if the object implements IWrapperItemProvider.
>
>
> >>>>>
>
>
> How do you do the (2) what is the proper way to do that without
> breaking the code. I mean shall I change the
> AdapterFactoryEditingDomain ?
Create a derived class and override the createCommand method to handle
your case and then call super. I.e., the usual Java technique.
> If yes, is there any registration I should be aware of before doing that?
The editing domain is created in the editor, so you can create your own
version there.
>
> 3-/More the same question than Same question for the (3)? Shall I
> change after subclassing it, where is the proper way to make the test.
> (I don't know AdapterFactoryEditingDomain yet)
I suppose just testing that the UI is behaving correctly is the way...
>
>
>
> Regards,
> Maatari
>
> On 3/23/09 1:00 PM, in article gq7tlq$fca$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
> Problem with Deletion : Managing Localy Shared global Object
> as Non-contained-Child Hi all,
>
> I have the following case:
>
> In my model I have On top a Social Structure which contains
> roles which in turn contains objectives. However, Because
> Objective are unique in the model, The real Container of the
> objective is the Social Structure. Objective are
> Non-Contained-Child of Roles and Contained child of the Social
> Structure. I already manage the addition of new objective
> using a compound command, which when called from the role,
> add it both to the Social structure and the Role, avoiding de
> facto the "dangling Reference".
>
> My problem arises when I try to Delete this object and this is
> where please, I would require any advises: I want that when I
> delete an objective from a Role, if this Role or Non-Container
> Parent is the only one, then delete it both from the Role and
> its containing Parent which is the Social Structure.
> Otherwise, the object is removed only from the current
> Non-Containing-Parent.
>
> Please can any one give me some advise on how to implement it.
> The problem could be qualified as the general problem of
> managing shared global object locally as Non-contained-Child.
>
> To be more specific. I already tried implementing a version
> which as lead me to use ItemWrappers for the
> Non-contained-child. Those wrappers are created automatically
> in my RoleItemProvider. Meaning that IsWrappingNeeded always
> returns true.
>
>
> However I encountered problems when I tried to implement my
> own DeleteCommand called from my RoleItemProvider.
>
> It seams like The DeleteCommand in any case remove all Item
> even if the Item is a Warpper which is my problem. Indeed as I
> sated RemoveAll to true in The ActionBarContributor for the
> DeleteAction, It is the DeleteCommand which is used and is
> the general behavior I would like to have expect for
> Objective. However In its execution it does unwrap Item to
> find allUsage with a CrossReferencer. Meaning that, It does
> not focus on the Wrapper only but on what it represent. This
> situation has invalidate all the logic I have Implemented to
> check for the condition described above to comply to my the
> deletion criteria. Indeed with a wrapper, the getParent does
> not just yield the container. Using some crossReferencer I
> have been able to make the check discribed above.
> However I ended up with frustration as it was not working.
> After some debug, and looking into the the DeleteCommand I
> realize the behavior described earlier which in my opinion is
> the reason of my bug. Of course it might be anything else,
> that is why I'm open to any idea in that sense.
> Does any one have a good idea on how to implement this
> functionality? The only one that I see for now is :
>
> Using the Remove version of the DeleteAction, Implementing my
> own RemoveCommand specific for Each object called from my
> Items Providers, and use the EcoreUtil.delete when necessary.
> While the ides sounds ok. It is customizing the remove
> instead of customizing the delete. It seams to heavy and ugly
> to me. Therefore I think there might be another way.
>
>
> There have certainly been quite set set of changes related to
> delete command and what should all be deleted, with children being
> overlooked at one point. I'm not entirely convinced looking at
> the code now that we should ever be unwrapping objects. Perhaps
> we should have only been checking instanceof EObject and only in
> that case do the delete all references part... That probably
> addresses your issue right? I.e., if we skipped the unwrapping
> step. Hnmmm.... But I think for feature map entries we have
> wrappers, and they need to behave the way we have currently.
> Maybe some improved factoring to make it easy to skip the
> unwrapping would help...
>
>
>
> Please, do not hesitate on the suggestion.
>
>
>
>
>
--------------090809060709050307040203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel,<br>
<br>
Comments below.<br>
<br>
Daniel OKOUYA wrote:
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite">
<title>Re: Problem with Deletion : Managing Localy Shared global
Object as Non-contained-Child</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Sorry about the multiple post.<br>
<br>
Because, I like Things that are well engineer and well thought, and for
the evolution of my application, I need to be sure my architecture and
etc....<br>
So if you don’t mind, I would like to do something, that is not going
to be broken soon. Because, indeed, several month ago I contacted you
about this problem and I’m pretty sure that my code was working. I
don’t know when was the update done, but it did change the behavior of
my application. <br>
</span></font></blockquote>
I think it was ages ago.<br>
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">But in any case, I think the all point is to
have a good interpretation of what should be<br>
DeleteCommand Behavior. <br>
</span></font></blockquote>
Of course different people might have different perceptions depending
on how they've used things.<br>
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
So please, for clarity: <br>
<br>
1-/ What will or should be the actual behavior of the DELETECOMMAND. <br>
Semanticaly what you desicribe here: <br>
<br>
>>>><br>
There have certainly been quite set set of changes related to delete
command and what should all be deleted, with children being overlooked
at one point. I'm not entirely convinced looking at the code now that
we should ever be unwrapping objects. Perhaps we should have only been
checking instanceof EObject and only in that case do the delete all
references part... That probably addresses your issue right? I.e., if
we skipped the unwrapping step. Hnmmm.... But I think for feature map
entries we have wrappers, and they need to behave the way we have
currently. Maybe some improved factoring to make it easy to skip the
unwrapping would help... <br>
>>>><br>
<br>
Means a behavior such as The object is not identified as being the
object but as the reference of a Parent. Is it the desired behavior
that you would like to have?<br>
</span></font></blockquote>
Other users might have a tree structure they induce with wrappers while
still wanting a delete to do the normal thing. When we realized delete
didn't properly delete references to children, we added support for
walking the children. In any case, the CVS history of the file is
public information you can inspect.<br>
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
<br>
2-/ In the same line as what you said above concerning the refactoring
you said in a preceding post I would like to ask :<br>
<br>
>>>>><br>
<br>
2-/ Then based on that, can anyone give me an advise about how
to make sure that the delete only delete a wrapper and not the object
everywhere else?<br>
<br>
You could specialize the editing domain's create command
so that DeleteCommand is created only for non-wrappers and otherwise a
remove command.<br>
<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">3-/ Also, how can I check that the actual
item being selected is a wrapper, how does it works?<br>
<br>
You can check if if the object implements IWrapperItemProvider.<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
>>>>><br>
<br>
<br>
How do you do the (2) what is the proper way to do that without
breaking the code. I mean shall I change the
AdapterFactoryEditingDomain ? </span></font></blockquote>
Create a derived class and override the createCommand method to handle
your case and then call super. I.e., the usual Java technique.<br>
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">If yes, is there any registration I should be
aware of before doing that?<br>
</span></font></blockquote>
The editing domain is created in the editor, so you can create your own
version there.<br>
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
3-/More the same question than Same question for the (3)? Shall I
change after subclassing it, where is the proper way to make the test.
(I don’t know AdapterFactoryEditingDomain yet)<br>
</span></font></blockquote>
I suppose just testing that the UI is behaving correctly is the way...<br>
<blockquote cite="mid:C5ED52D2.6FF3%25okouya_d@yahoo.fr" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
<br>
Regards,<br>
Maatari<br>
<br>
On 3/23/09 1:00 PM, in article <a moz-do-not-send="true"
href="gq7tlq$fca$1@build.eclipse.org">gq7tlq$fca$1@build.eclipse.org</a>,
"Ed Merks" <<a moz-do-not-send="true" href="Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>>
wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Daniel,<br>
<br>
Comments below.<br>
<br>
Daniel OKOUYA wrote: <br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> Problem with Deletion : Managing Localy
Shared global Object as Non-contained-Child Hi all, <br>
<br>
I have the following case: <br>
<br>
In my model I have On top a Social Structure which contains roles which
in turn contains objectives. However, Because Objective are unique in
the model, The real Container of the objective is the Social Structure.
Objective are Non-Contained-Child of Roles and Contained child of the
Social Structure. I already manage the addition of new objective using
a compound command, which when called from the role, add it both to
the Social structure and the Role, avoiding de facto the “dangling
Reference”.<br>
<br>
My problem arises when I try to Delete this object and this is where
please, I would require any advises: I want that when I delete an
objective from a Role, if this Role or Non-Container Parent is the only
one, then delete it both from the Role and its containing Parent which
is the Social Structure. Otherwise, the object is removed only from the
current Non-Containing-Parent.<br>
<br>
Please can any one give me some advise on how to implement it. The
problem could be qualified as the general problem of managing shared
global object locally as Non-contained-Child.<br>
<br>
To be more specific. I already tried implementing a version which as
lead me to use ItemWrappers for the Non-contained-child. Those
wrappers are created automatically in my RoleItemProvider. Meaning that
IsWrappingNeeded always returns true.<br>
<br>
<br>
However I encountered problems when I tried to implement my own
DeleteCommand called from my RoleItemProvider.<br>
<br>
It seams like The DeleteCommand in any case remove all Item even if the
Item is a Warpper which is my problem. Indeed as I sated RemoveAll to
true in The ActionBarContributor for the DeleteAction, It is the
DeleteCommand which is used and is the general behavior I would like
to have expect for Objective. However In its execution it does unwrap
Item to find allUsage with a CrossReferencer. Meaning that, It does not
focus on the Wrapper only but on what it represent. This situation has
invalidate all the logic I have Implemented to check for the condition
described above to comply to my the deletion criteria. Indeed with a
wrapper, the getParent does not just yield the container. Using some
crossReferencer I have been able to make the check discribed above.<br>
However I ended up with frustration as it was not working. After some
debug, and looking into the the DeleteCommand I realize the behavior
described earlier which in my opinion is the reason of my bug. Of
course it might be anything else, that is why I’m open to any idea in
that sense. <br>
Does any one have a good idea on how to implement this functionality?
The only one that I see for now is : <br>
<br>
Using the Remove version of the DeleteAction, Implementing my own
RemoveCommand specific for Each object called from my Items Providers,
and use the EcoreUtil.delete when necessary. While the ides sounds ok.
It is customizing the remove instead of customizing the delete. It
seams to heavy and ugly to me. Therefore I think there might be another
way.<br>
<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">There have certainly been quite set set of
changes related to delete command and what should all be deleted, with
children being overlooked at one point. I'm not entirely convinced
looking at the code now that we should ever be unwrapping objects.
Perhaps we should have only been checking instanceof EObject and only
in that case do the delete all references part... That probably
addresses your issue right? I.e., if we skipped the unwrapping step.
Hnmmm.... But I think for feature map entries we have wrappers, and
they need to behave the way we have currently. Maybe some improved
factoring to make it easy to skip the unwrapping would help... <br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
<br>
Please, do not hesitate on the suggestion.<br>
<br>
<br>
<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
</span></font></blockquote>
</blockquote>
</body>
</html>
--------------090809060709050307040203--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428536 is a reply to message #428533] |
Tue, 24 March 2009 17:25 |
Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
--=-2ak78MWQB3rZU6ttaJgt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi, Daniel,
Your GMF-generated editor registers its editing domain on the
org.eclipse.emf.transaction.editingDomains extension point. This
extension indicates the domain's unique ID and the factory class used to
create it (usually, this is the GMFEditingDomainFactory).
You can change your editor's extension to specify a factory of your own
devising, that extends the GMFEditingDomainFactory and creates your own
subclass of the GMF editing domain implementation.
HTH,
Christian
On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
> Hi I just try to follow your advise here, but I got stuck with the
> fact that because I=E2=80=99m integrating with GMF I use a shared Editing
> Domain.=20
> Would you advise the same thing, subclassing and rewriting the
> transactional editing domain? However if I may it is susbtantially a
> more complicate class, indeed,=20
> Its intiation is as follow TransactionalEditingDomain domain =3D
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();=20
>=20
> Therefore, please, it indeed a bit shamefull :-(, if you don=E2=80=99t mi=
nd,
> could you give me an OO advise here, as I don=E2=80=99t know how to subcl=
ass a
> class a class that as already nested class, that are static with
> static method etc..... Could help or maybe advise something else.=20
>=20
> Indeed, What I wanted to do following your advise was to check if the
> current element is instanceOf WrappedItem, and if yes calling remove
> instead of Delete.=20
> I have no problem overiding this method In the transactional editing
> domain, but just don=E2=80=99t know how to deal with nested element, espe=
cial
> if their internal method must be change.
>=20
> Kind regards,
> Daniel
>=20
>=20
>=20
> On 3/23/09 3:01 PM, in article gq84o0$63b$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>=20
>=20
> Daniel,
> =20
> Comments below.
> =20
> Daniel OKOUYA wrote:=20
> =20
> Re: Problem with Deletion : Managing Localy Shared
> global Object as Non-contained-Child Sorry about the
> multiple post.
> =20
> Because, I like Things that are well engineer and well
> thought, and for the evolution of my application, I
> need to be sure my architecture and etc....
> So if you don=E2=80=99t mind, I would like to do somethin=
g,
> that is not going to be broken soon. Because, indeed,
> several month ago I contacted you about this problem
> and I=E2=80=99m pretty sure that my code was working. I d=
on=E2=80=99t
> know when was the update done, but it did change the
> behavior of my application. =20
> =20
> =20
> I think it was ages ago.
> =20
> But in any case, I think the all point is to have a
> good interpretation of what should be
> DeleteCommand Behavior.=20
> =20
> =20
> Of course different people might have different perceptions
> depending on how they've used things.
> =20
> =20
> So please, for clarity:=20
> =20
> 1-/ What will or should be the actual behavior of the
> DELETECOMMAND.=20
> Semanticaly what you desicribe here:=20
> =20
> >>>>
> There have certainly been quite set set of changes
> related to delete command and what should all be
> deleted, with children being overlooked at one point.
> I'm not entirely convinced looking at the code now
> that we should ever be unwrapping objects. Perhaps we
> should have only been checking instanceof EObject and
> only in that case do the delete all references
> part... That probably addresses your issue right?
> I.e., if we skipped the unwrapping step. Hnmmm....
> But I think for feature map entries we have wrappers,
> and they need to behave the way we have currently.
> Maybe some improved factoring to make it easy to skip
> the unwrapping would help...=20
> >>>>
> =20
> Means a behavior such as The object is not identified
> as being the object but as the reference of a Parent.
> Is it the desired behavior that you would like to
> have?
> =20
> =20
> Other users might have a tree structure they induce with
> wrappers while still wanting a delete to do the normal thing.
> When we realized delete didn't properly delete references to
> children, we added support for walking the children. In any
> case, the CVS history of the file is public information you
> can inspect.
> =20
> =20
> =20
> =20
> 2-/ In the same line as what you said above
> concerning the refactoring you said in a preceding
> post I would like to ask :
> =20
> >>>>>
> =20
> 2-/ Then based on that, can anyone give me an
> advise about how to make sure that the delete only
> delete a wrapper and not the object everywhere else?
> =20
> You could specialize the editing
> domain's create command so that DeleteCommand is
> created only for non-wrappers and otherwise a remove
> command.
> =20
> =20
> =20
> =20
> 3-/ Also, how can I check that the actual item
> being selected is a wrapper, how does it
> works?
> =20
> You can check if if the object
> implements IWrapperItemProvider.
> =20
> =20
> =20
> >>>>>
> =20
> =20
> How do you do the (2) what is the proper way to do
> that without breaking the code. I mean shall I change
> the AdapterFactoryEditingDomain ?=20
> =20
> Create a derived class and override the createCommand method
> to handle your case and then call super. I.e., the usual Java
> technique.
> =20
> If yes, is there any registration I should be aware of
> before doing that?
> =20
> =20
> The editing domain is created in the editor, so you can create
> your own version there.
> =20
> =20
> 3-/More the same question than Same question for the
> (3)? Shall I change after subclassing it, where is the
> proper way to make the test. (I don=E2=80=99t know
> AdapterFactoryEditingDomain yet)
> =20
> =20
> I suppose just testing that the UI is behaving correctly is
> the way...
> =20
> =20
> =20
> =20
> Regards,
> Maatari
> =20
> On 3/23/09 1:00 PM, in article gq7tlq$fca
> $1@build.eclipse.org, "Ed Merks" <Ed.Merks@gmail.com>
> wrote:
> =20
> =20
> =20
> Daniel,
> =20
> Comments below.
> =20
> Daniel OKOUYA wrote:=20
> =20
> =20
> Problem with Deletion : Managing
> Localy Shared global Object as
> Non-contained-Child Hi all,=20
> =20
> I have the following case:=20
> =20
> In my model I have On top a Social
> Structure which contains roles which
> in turn contains objectives. However,
> Because Objective are unique in the
> model, The real Container of the
> objective is the Social Structure.
> Objective are Non-Contained-Child of
> Roles and Contained child of the
> Social Structure. I already manage the
> addition of new objective using a
> compound command, which when called
> from the role, add it both to the
> Social structure and the Role,
> avoiding de facto the =E2=80=9Cdangling
> Reference=E2=80=9D.
> =20
> My problem arises when I try to Delete
> this object and this is where please,
> I would require any advises: I want
> that when I delete an objective from a
> Role, if this Role or Non-Container
> Parent is the only one, then delete it
> both from the Role and its containing
> Parent which is the Social Structure.
> Otherwise, the object is removed only
> from the current
> Non-Containing-Parent.
> =20
> Please can any one give me some advise
> on how to implement it. The problem
> could be qualified as the general
> problem of managing shared global
> object locally as
> Non-contained-Child.
> =20
> To be more specific. I already tried
> implementing a version which as lead
> me to use ItemWrappers for the
> Non-contained-child. Those wrappers
> are created automatically in my
> RoleItemProvider. Meaning that
> IsWrappingNeeded always returns true.
> =20
> =20
> However I encountered problems when I
> tried to implement my own
> DeleteCommand called from my
> RoleItemProvider.
> =20
> It seams like The DeleteCommand in any
> case remove all Item even if the Item
> is a Warpper which is my problem.
> Indeed as I sated RemoveAll to true in
> The ActionBarContributor for the
> DeleteAction, It is the DeleteCommand
> which is used and is the general
> behavior I would like to have expect
> for Objective. However In its
> execution it does unwrap Item to find
> allUsage with a CrossReferencer.
> Meaning that, It does not focus on the
> Wrapper only but on what it represent.
> This situation has invalidate all the
> logic I have Implemented to check for
> the condition described above to
> comply to my the deletion criteria.
> Indeed with a wrapper, the getParent
> does not just yield the container.
> Using some crossReferencer I have been
> able to make the check discribed
> above.
> However I ended up with frustration as
> it was not working. After some debug,
> and looking into the the DeleteCommand
> I realize the behavior described
> earlier which in my opinion is the
> reason of my bug. Of course it might
> be anything else, that is why I=E2=80=99m=
open
> to any idea in that sense.=20
> Does any one have a good idea on how
> to implement this functionality? The
> only one that I see for now is :=20
> =20
> Using the Remove version of the
> DeleteAction, Implementing my own
> RemoveCommand specific for Each object
> called from my Items Providers, and
> use the EcoreUtil.delete when
> necessary. While the ides sounds ok.
> It is customizing the remove instead
> of customizing the delete. It seams to
> heavy and ugly to me. Therefore I
> think there might be another way.
> =20
> =20
> =20
> There have certainly been quite set set of
> changes related to delete command and what
> should all be deleted, with children being
> overlooked at one point. I'm not entirely
> convinced looking at the code now that we
> should ever be unwrapping objects. Perhaps we
> should have only been checking instanceof
> EObject and only in that case do the delete
> all references part... That probably
> addresses your issue right? I.e., if we
> skipped the unwrapping step. Hnmmm.... But I
> think for feature map entries we have
> wrappers, and they need to behave the way we
> have currently. Maybe some improved factoring
> to make it easy to skip the unwrapping would
> help...=20
> =20
> =20
> =20
> =20
> Please, do not hesitate on the
> suggestion.
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
--=-2ak78MWQB3rZU6ttaJgt
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
<TITLE>Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child</TITLE>
</HEAD>
<BODY>
Hi, Daniel,<BR>
<BR>
Your GMF-generated editor registers its editing domain on the org.eclipse.emf.transaction.editingDomains extension point. This extension indicates the domain's unique ID and the factory class used to create it (usually, this is the GMFEditingDomainFactory).<BR>
<BR>
You can change your editor's extension to specify a factory of your own devising, that extends the GMFEditingDomainFactory and creates your own subclass of the GMF editing domain implementation.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Hi I just try to follow your advise here, but I got stuck with the fact that because I’m integrating with GMF I use a shared Editing Domain. <BR>
Would you advise the same thing, subclassing and rewriting the transactional editing domain? However if I may it is susbtantially a more complicate class, indeed, <BR>
Its intiation is as follow TransactionalEditingDomain domain = TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain(); <BR>
<BR>
Therefore, please, it indeed a bit shamefull :-(, if you don’t mind, could you give me an OO advise here, as I don’t know how to subclass a class a class that as already nested class, that are static with static method etc..... Could help or maybe advise something else. <BR>
<BR>
Indeed, What I wanted to do following your advise was to check if the current element is instanceOf WrappedItem, and if yes calling remove instead of Delete. <BR>
I have no problem overiding this method In the transactional editing domain, but just don’t know how to deal with nested element, especial if their internal method must be change.<BR>
<BR>
Kind regards,<BR>
Daniel<BR>
<BR>
<BR>
<BR>
On 3/23/09 3:01 PM, in article <A HREF="gq84o0$63b$1@build.eclipse.org">gq84o0$63b$1@build.eclipse.org</A>, "Ed Merks" <<A HREF="Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote:<BR>
<BR>
<BLOCKQUOTE>
Daniel,<BR>
<BR>
Comments below.<BR>
<BR>
Daniel OKOUYA wrote: <BR>
<BLOCKQUOTE>
Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child Sorry about the multiple post.<BR>
<BR>
Because, I like Things that are well engineer and well thought, and for the evolution of my application, I need to be sure my architecture and etc....<BR>
So if you don’t mind, I would like to do something, that is not going to be broken soon. Because, indeed, several month ago I contacted you about this problem and I’m pretty sure that my code was working. I don’t know when was the update done, but it did change the behavior of my application. <BR>
<BR>
</BLOCKQUOTE>
I think it was ages ago.<BR>
<BLOCKQUOTE>
But in any case, I think the all point is to have a good interpretation of what should be<BR>
DeleteCommand Behavior. <BR>
<BR>
</BLOCKQUOTE>
Of course different people might have different perceptions depending on how they've used things.<BR>
<BLOCKQUOTE>
<BR>
So please, for clarity: <BR>
<BR>
1-/ What will or should be the actual behavior of the DELETECOMMAND. <BR>
Semanticaly what you desicribe here: <BR>
<BR>
>>>><BR>
There have certainly been quite set set of changes related to delete command and what should all be deleted, with children being overlooked at one point. I'm not entirely convinced looking at the code now that we should ever be unwrapping objects. Perhaps we should have only been checking instanceof EObject and only in that case do the delete all references part... That probably addresses your issue right? I.e., if we skipped the unwrapping step. Hnmmm.... But I think for feature map entries we have wrappers, and they need to behave the way we have currently. Maybe some improved factoring to make it easy to skip the unwrapping would help... <BR>
>>>><BR>
<BR>
Means a behavior such as The object is not identified as being the object but as the reference of a Parent. Is it the desired behavior that you would like to have?<BR>
<BR>
</BLOCKQUOTE>
Other users might have a tree structure they induce with wrappers while still wanting a delete to do the normal thing. When we realized delete didn't properly delete references to children, we added support for walking the children. In any case, the CVS history of the file is public information you can inspect.<BR>
<BLOCKQUOTE>
<BR>
<BR>
<BR>
2-/ In the same line as what you said above concerning the refactoring you said in a preceding post I would like to ask :<BR>
<BR>
>>>>><BR>
<BR>
2-/ Then based on that, can anyone give me an advise about how to make sure that the delete only delete a wrapper and not the object everywhere else?<BR>
<BR>
You could specialize the editing domain's create command so that DeleteCommand is created only for non-wrappers and otherwise a remove command.<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE>
3-/ Also, how can I check that the actual item being selected is a wrapper, how does it works?<BR>
<BR>
You can check if if the object implements IWrapperItemProvider.<BR>
<BR>
</BLOCKQUOTE>
<BR>
>>>>><BR>
<BR>
<BR>
How do you do the (2) what is the proper way to do that without breaking the code. I mean shall I change the AdapterFactoryEditingDomain ? <BR>
</BLOCKQUOTE>
Create a derived class and override the createCommand method to handle your case and then call super. I.e., the usual Java technique.<BR>
<BLOCKQUOTE>
If yes, is there any registration I should be aware of before doing that?<BR>
<BR>
</BLOCKQUOTE>
The editing domain is created in the editor, so you can create your own version there.<BR>
<BLOCKQUOTE>
<BR>
3-/More the same question than Same question for the (3)? Shall I change after subclassing it, where is the proper way to make the test. (I don’t know AdapterFactoryEditingDomain yet)<BR>
<BR>
</BLOCKQUOTE>
I suppose just testing that the UI is behaving correctly is the way...<BR>
<BLOCKQUOTE>
<BR>
<BR>
<BR>
Regards,<BR>
Maatari<BR>
<BR>
On 3/23/09 1:00 PM, in article <A HREF="gq7tlq$fca$1@build.eclipse.org">gq7tlq$fca$1@build.eclipse.org</A>, "Ed Merks" <<A HREF="Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote:<BR>
<BR>
<BR>
<BLOCKQUOTE>
Daniel,<BR>
<BR>
Comments below.<BR>
<BR>
Daniel OKOUYA wrote: <BR>
<BR>
<BLOCKQUOTE>
Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child Hi all, <BR>
<BR>
I have the following case: <BR>
<BR>
In my model I have On top a Social Structure which contains roles which in turn contains objectives. However, Because Objective are unique in the model, The real Container of the objective is the Social Structure. Objective are Non-Contained-Child of Roles and Contained child of the Social Structure. I already manage the addition of new objective using a compound command, which when called from the role, add it both to the Social structure and the Role, avoiding de facto the “dangling Reference”.<BR>
<BR>
My problem arises when I try to Delete this object and this is where please, I would require any advises: I want that when I delete an objective from a Role, if this Role or Non-Container Parent is the only one, then delete it both from the Role and its containing Parent which is the Social Structure. Otherwise, the object is removed only from the current Non-Containing-Parent.<BR>
<BR>
Please can any one give me some advise on how to implement it. The problem could be qualified as the general problem of managing shared global object locally as Non-contained-Child.<BR>
<BR>
To be more specific. I already tried implementing a version which as lead me to use ItemWrappers for the Non-contained-child. Those wrappers are created automatically in my RoleItemProvider. Meaning that IsWrappingNeeded always returns true.<BR>
<BR>
<BR>
However I encountered problems when I tried to implement my own DeleteCommand called from my RoleItemProvider.<BR>
<BR>
It seams like The DeleteCommand in any case remove all Item even if the Item is a Warpper which is my problem. Indeed as I sated RemoveAll to true in The ActionBarContributor for the DeleteAction, It is the DeleteCommand which is used and is the general behavior I would like to have expect for Objective. However In its execution it does unwrap Item to find allUsage with a CrossReferencer. Meaning that, It does not focus on the Wrapper only but on what it represent. This situation has invalidate all the logic I have Implemented to check for the condition described above to comply to my the deletion criteria. Indeed with a wrapper, the getParent does not just yield the container. Using some crossReferencer I have been able to make the check discribed above.<BR>
However I ended up with frustration as it was not working. After some debug, and looking into the the DeleteCommand I realize the behavior described earlier which in my opinion is the reason of my bug. Of course it might be anything else, that is why I’m open to any idea in that sense. <BR>
Does any one have a good idea on how to implement this functionality? The only one that I see for now is : <BR>
<BR>
Using the Remove version of the DeleteAction, Implementing my own RemoveCommand specific for Each object called from my Items Providers, and use the EcoreUtil.delete when necessary. While the ides sounds ok. It is customizing the remove instead of customizing the delete. It seams to heavy and ugly to me. Therefore I think there might be another way.<BR>
<BR>
<BR>
</BLOCKQUOTE>
There have certainly been quite set set of changes related to delete command and what should all be deleted, with children being overlooked at one point. I'm not entirely convinced looking at the code now that we should ever be unwrapping objects. Perhaps we should have only been checking instanceof EObject and only in that case do the delete all references part... That probably addresses your issue right? I.e., if we skipped the unwrapping step. Hnmmm.... But I think for feature map entries we have wrappers, and they need to behave the way we have currently. Maybe some improved factoring to make it easy to skip the unwrapping would help... <BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
Please, do not hesitate on the suggestion.<BR>
<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-2ak78MWQB3rZU6ttaJgt--
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428538 is a reply to message #428536] |
Tue, 24 March 2009 18:37 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3320768259_401726
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit
Thanks for the tips. However I think that once you have done the integration
the editingdomain is no more created by GMF itself but inside the
MultiPageEditor and that is the one that is passed to GMF. But in any case
in order to be fully sure I will also provide the modification you required.
Just for precision when you mean the GMFEditingDomain you meant
TransactionalEditingDomain?
Here, the technics should consit in: Extending The interface Transactional
Editing domain as well as the Implementation which extends
AdapterFactoryEditing domain.
In extending the interface, is a bit tricky right? I have to shadow some
element already there to support my own instantiation of Factory.Instance,
can it work?
Regards,
Daniel
On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
"Christian W. Damus" <give.a.damus@gmail.com> wrote:
> Hi, Daniel,
>
> Your GMF-generated editor registers its editing domain on the
> org.eclipse.emf.transaction.editingDomains extension point. This extension
> indicates the domain's unique ID and the factory class used to create it
> (usually, this is the GMFEditingDomainFactory).
>
> You can change your editor's extension to specify a factory of your own
> devising, that extends the GMFEditingDomainFactory and creates your own
> subclass of the GMF editing domain implementation.
>
> HTH,
>
> Christian
>
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>> Hi I just try to follow your advise here, but I got stuck with the fact that
>> because I
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428540 is a reply to message #428538] |
Tue, 24 March 2009 18:54 |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
--=-hgiXoEUIdNJjRRm2UabM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi, Daniel,
I don't know anything about multi-page editors in GMF, but I do know
that a GMF diagram editor expects to work with an instance of the
org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFac tory.DiagramEdi=
tingDomain class, because that editing domain implementation does some funk=
y handling of the DiagramEventBroker. This factory is a subclass of the GM=
FEditingDomainFactory, which isn't actually what you need (sorry).
So, if you define a subclass of the DiagramEditingDomainFactory that
creates a subclass of the nested DiagramEditingDomain class, with your
customizations, then I think you should be able to make it work. I
don't know enough about your original problem to speak to that; I just
jumped into the conversation when I saw your question about customizing
the transactional editing domain. :-)
As you are only looking to customize editing domain behaviours that are
orthogonal to concerns of transactioning, it should be very simple to
define the subclasses that you need. The
TransactionalEditingDomain.Registry.INSTANCE takes care of finding your
custom factory class from the extension point and using it to create
your editing domain the first time that it is requested by ID.
HTH,
Christian
On Tue, 2009-03-24 at 19:37 +0100, Daniel OKOUYA wrote:
> Thanks for the tips. However I think that once you have done the
> integration the editingdomain is no more created by GMF itself but
> inside the MultiPageEditor and that is the one that is passed to GMF.
> But in any case in order to be fully sure I will also provide the
> modification you required.=20
>=20
>=20
> Just for precision when you mean the GMFEditingDomain you meant
> TransactionalEditingDomain?
>=20
> Here, the technics should consit in: Extending The interface
> Transactional Editing domain as well as the Implementation which
> extends AdapterFactoryEditing domain.=20
> In extending the interface, is a bit tricky right? I have to shadow
> some element already there to support my own instantiation of
> Factory.Instance, can it work?
> Regards,
> Daniel
>=20
>=20
>=20
> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>=20
>=20
> Hi, Daniel,
> =20
> Your GMF-generated editor registers its editing domain on the
> org.eclipse.emf.transaction.editingDomains extension point.
> This extension indicates the domain's unique ID and the
> factory class used to create it (usually, this is the
> GMFEditingDomainFactory).
> =20
> You can change your editor's extension to specify a factory of
> your own devising, that extends the GMFEditingDomainFactory
> and creates your own subclass of the GMF editing domain
> implementation.
> =20
> HTH,
> =20
> Christian
> =20
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
> =20
> Hi I just try to follow your advise here, but I got
> stuck with the fact that because I=E2=80=99m integrating =
with
> GMF I use a shared Editing Domain.=20
> Would you advise the same thing, subclassing and
> rewriting the transactional editing domain? However if
> I may it is susbtantially a more complicate class,
> indeed,=20
> Its intiation is as follow TransactionalEditingDomain
> domain =3D
> TransactionalEditingDomain.Factory.INSTANCE.createEditing=
Domain();=20
> =20
> Therefore, please, it indeed a bit shamefull :-(, if
> you don=E2=80=99t mind, could you give me an OO advise he=
re,
> as I don=E2=80=99t know how to subclass a class a class t=
hat
> as already nested class, that are static with static
> method etc..... Could help or maybe advise something
> else.=20
> =20
> Indeed, What I wanted to do following your advise was
> to check if the current element is instanceOf
> WrappedItem, and if yes calling remove instead of
> Delete.=20
> I have no problem overiding this method In the
> transactional editing domain, but just don=E2=80=99t know=
how
> to deal with nested element, especial if their
> internal method must be change.
> =20
> Kind regards,
> Daniel
> =20
> =20
> =20
> On 3/23/09 3:01 PM, in article gq84o0$63b
> $1@build.eclipse.org, "Ed Merks" <Ed.Merks@gmail.com>
> wrote:
> =20
> =20
> =20
> Daniel,
> =20
> Comments below.
> =20
> Daniel OKOUYA wrote:=20
> =20
> =20
> Re: Problem with Deletion : Managing
> Localy Shared global Object as
> Non-contained-Child Sorry about the
> multiple post.
> =20
> Because, I like Things that are well
> engineer and well thought, and for the
> evolution of my application, I need to
> be sure my architecture and etc....
> So if you don=E2=80=99t mind, I would li=
ke to
> do something, that is not going to be
> broken soon. Because, indeed, several
> month ago I contacted you about this
> problem and I=E2=80=99m pretty sure that =
my
> code was working. I don=E2=80=99t know wh=
en
> was the update done, but it did change
> the behavior of my application. =20
> =20
> =20
> =20
> I think it was ages ago.
> =20
> =20
> But in any case, I think the all point
> is to have a good interpretation of
> what should be
> DeleteCommand Behavior.=20
> =20
> =20
> =20
> Of course different people might have
> different perceptions depending on how they've
> used things.
> =20
> =20
> =20
> So please, for clarity:=20
> =20
> 1-/ What will or should be the actual
> behavior of the DELETECOMMAND.=20
> Semanticaly what you desicribe here:=20
> =20
> >>>>
> There have certainly been quite set
> set of changes related to delete
> command and what should all be
> deleted, with children being
> overlooked at one point. I'm not
> entirely convinced looking at the code
> now that we should ever be unwrapping
> objects. Perhaps we should have only
> been checking instanceof EObject and
> only in that case do the delete all
> references part... That probably
> addresses your issue right? I.e., if
> we skipped the unwrapping step.
> Hnmmm.... But I think for feature
> map entries we have wrappers, and they
> need to behave the way we have
> currently. Maybe some improved
> factoring to make it easy to skip the
> unwrapping would help...=20
> >>>>
> =20
> Means a behavior such as The object
> is not identified as being the object
> but as the reference of a Parent. Is
> it the desired behavior that you would
> like to have?
> =20
> =20
> =20
> Other users might have a tree structure they
> induce with wrappers while still wanting a
> delete to do the normal thing. When we
> realized delete didn't properly delete
> references to children, we added support for
> walking the children. In any case, the CVS
> history of the file is public information you
> can inspect.
> =20
> =20
> =20
> =20
> =20
> 2-/ In the same line as what you said
> above concerning the refactoring you
> said in a preceding post I would like
> to ask :
> =20
> >>>>>
> =20
> 2-/ Then based on that, can
> anyone give me an advise about how to
> make sure that the delete only delete
> a wrapper and not the object
> everywhere else?
> =20
> You could specialize
> the editing domain's create command so
> that DeleteCommand is created only for
> non-wrappers and otherwise a remove
> command.
> =20
> =20
> =20
> =20
> =20
> 3-/ Also, how can I check that
> the actual item being selected
> is a wrapper, how does it
> works?
> =20
> You can check if if the
> object implements
> IWrapperItemProvider.
> =20
> =20
> =20
> =20
> >>>>>
> =20
> =20
> How do you do the (2) what is the
> proper way to do that without breaking
> the code. I mean shall I change the
> AdapterFactoryEditingDomain ?=20
> =20
> =20
> Create a derived class and override the
> createCommand method to handle your case and
> then call super. I.e., the usual Java
> technique.
> =20
> =20
> If yes, is there any registration I
> should be aware of before doing that?
> =20
> =20
> =20
> The editing domain is created in the editor,
> so you can create your own version there.
> =20
> =20
> =20
> 3-/More the same question than Same
> question for the (3)? Shall I change
> after subclassing it, where is the
> proper way to make the test. (I don=E2=80=
=99t
> know AdapterFactoryEditingDomain yet)
> =20
> =20
> =20
> I suppose just testing that the UI is behaving
> correctly is the way...
> =20
> =20
> =20
> =20
> =20
> Regards,
> Maatari
> =20
> On 3/23/09 1:00 PM, in article gq7tlq
> $fca$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
> =20
> =20
> =20
> =20
> Daniel,
> =20
> Comments below.
> =20
> Daniel OKOUYA wrote:=20
> =20
> =20
> =20
> Problem with
> Deletion : Managing
> Localy Shared global
> Object as
> Non-contained-Child Hi
> all,=20
> =20
> I have the following
> case:=20
> =20
> In my model I have On
> top a Social Structure
> which contains roles
> which in turn contains
> objectives. However,
> Because Objective are
> unique in the model,
> The real Container of
> the objective is the
> Social Structure.
> Objective are
> Non-Contained-Child of
> Roles and Contained
> child of the Social
> Structure. I already
> manage the addition of
> new objective using a
> compound command,
> which when called
> from the role, add it
> both to the Social
> structure and the
> Role, avoiding de
> facto the =E2=80=9Cdangli=
ng
> Reference=E2=80=9D.
> =20
> My problem arises
> when I try to Delete
> this object and this
> is where please, I
> would require any
> advises: I want that
> when I delete an
> objective from a Role,
> if this Role or
> Non-Container Parent
> is the only one, then
> delete it both from
> the Role and its
> containing Parent
> which is the Social
> Structure. Otherwise,
> the object is removed
> only from the current
> Non-Containing-Parent.
> =20
> Please can any one
> give me some advise on
> how to implement it.
> The problem could be
> qualified as the
> general problem of
> managing shared global
> object locally as
> Non-contained-Child.
> =20
> To be more specific.
> I already tried
> implementing a version
> which as lead me to
> use ItemWrappers for
> the
> Non-contained-child.
> Those wrappers are
> created automatically
> in my
> RoleItemProvider.
> Meaning that
> IsWrappingNeeded
> always returns true.
> =20
> =20
> However I encountered
> problems when I tried
> to implement my own
> DeleteCommand called
> from my
> RoleItemProvider.
> =20
> It seams like The
> DeleteCommand in any
> case remove all Item
> even if the Item is a
> Warpper which is my
> problem. Indeed as I
> sated RemoveAll to
> true in The
> ActionBarContributor
> for the DeleteAction,
> It is the
> DeleteCommand which
> is used and is the
> general behavior I
> would like to have
> expect for Objective.
> However In its
> execution it does
> unwrap Item to find
> allUsage with a
> CrossReferencer.
> Meaning that, It does
> not focus on the
> Wrapper only but on
> what it represent.
> This situation has
> invalidate all the
> logic I have
> Implemented to check
> for the condition
> described above to
> comply to my the
> deletion criteria.
> Indeed with a wrapper,
> the getParent does not
> just yield the
> container. Using some
> crossReferencer I have
> been able to make the
> check discribed above.
> However I ended up
> with frustration as it
> was not working. After
> some debug, and
> looking into the the
> DeleteCommand I
> realize the behavior
> described earlier
> which in my opinion is
> the reason of my bug.
> Of course it might be
> anything else, that is
> why I=E2=80=99m open to a=
ny
> idea in that sense.=20
> Does any one have a
> good idea on how to
> implement this
> functionality? The
> only one that I see
> for now is :=20
> =20
> Using the Remove
> version of the
> DeleteAction,
> Implementing my own
> RemoveCommand specific
> for Each object called
> from my Items
> Providers, and use the
> EcoreUtil.delete when
> necessary. While the
> ides sounds ok. It is
> customizing the remove
> instead of customizing
> the delete. It seams
> to heavy and ugly to
> me. Therefore I think
> there might be another
> way.
> =20
> =20
> =20
> =20
> There have certainly been
> quite set set of changes
> related to delete command and
> what should all be deleted,
> with children being overlooked
> at one point. I'm not
> entirely convinced looking at
> the code now that we should
> ever be unwrapping objects.
> Perhaps we should have only
> been checking instanceof
> EObject and only in that case
> do the delete all references
> part... That probably
> addresses your issue right?
> I.e., if we skipped the
> unwrapping step. Hnmmm....
> But I think for feature map
> entries we have wrappers, and
> they need to behave the way we
> have currently. Maybe some
> improved factoring to make it
> easy to skip the unwrapping
> would help...=20
> =20
> =20
> =20
> =20
> =20
> Please, do not
> hesitate on the
> suggestion.
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
--=-hgiXoEUIdNJjRRm2UabM
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
<TITLE>Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child</TITLE>
</HEAD>
<BODY>
Hi, Daniel,<BR>
<BR>
I don't know anything about multi-page editors in GMF, but I do know that a GMF diagram editor expects to work with an instance of the org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFac tory.DiagramEditingDomain class, because that editing domain implementation does some funky handling of the DiagramEventBroker. This factory is a subclass of the GMFEditingDomainFactory, which isn't actually what you need (sorry).<BR>
<BR>
So, if you define a subclass of the DiagramEditingDomainFactory that creates a subclass of the nested DiagramEditingDomain class, with your customizations, then I think you should be able to make it work. I don't know enough about your original problem to speak to that; I just jumped into the conversation when I saw your question about customizing the transactional editing domain. :-)<BR>
<BR>
As you are only looking to customize editing domain behaviours that are orthogonal to concerns of transactioning, it should be very simple to define the subclasses that you need. The TransactionalEditingDomain.Registry.INSTANCE takes care of finding your custom factory class from the extension point and using it to create your editing domain the first time that it is requested by ID.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Tue, 2009-03-24 at 19:37 +0100, Daniel OKOUYA wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Thanks for the tips. However I think that once you have done the integration the editingdomain is no more created by GMF itself but inside the MultiPageEditor and that is the one that is passed to GMF. But in any case in order to be fully sure I will also provide the modification you required. <BR>
<BR>
<BR>
Just for precision when you mean the GMFEditingDomain you meant TransactionalEditingDomain?<BR>
<BR>
Here, the technics should consit in: Extending The interface Transactional Editing domain as well as the Implementation which extends AdapterFactoryEditing domain. <BR>
In extending the interface, is a bit tricky right? I have to shadow some element already there to support my own instantiation of Factory.Instance, can it work?<BR>
Regards,<BR>
Daniel<BR>
<BR>
<BR>
<BR>
On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop, "Christian W. Damus" <<A HREF="give.a.damus@gmail.com">give.a.damus@gmail.com</A>> wrote:<BR>
<BR>
<BLOCKQUOTE>
Hi, Daniel,<BR>
<BR>
Your GMF-generated editor registers its editing domain on the org.eclipse.emf.transaction.editingDomains extension point. This extension indicates the domain's unique ID and the factory class used to create it (usually, this is the GMFEditingDomainFactory).<BR>
<BR>
You can change your editor's extension to specify a factory of your own devising, that extends the GMFEditingDomainFactory and creates your own subclass of the GMF editing domain implementation.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:<BR>
<BLOCKQUOTE>
Hi I just try to follow your advise here, but I got stuck with the fact that because I’m integrating with GMF I use a shared Editing Domain. <BR>
Would you advise the same thing, subclassing and rewriting the transactional editing domain? However if I may it is susbtantially a more complicate class, indeed, <BR>
Its intiation is as follow TransactionalEditingDomain domain = TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain(); <BR>
<BR>
Therefore, please, it indeed a bit shamefull :-(, if you don’t mind, could you give me an OO advise here, as I don’t know how to subclass a class a class that as already nested class, that are static with static method etc..... Could help or maybe advise something else. <BR>
<BR>
Indeed, What I wanted to do following your advise was to check if the current element is instanceOf WrappedItem, and if yes calling remove instead of Delete. <BR>
I have no problem overiding this method In the transactional editing domain, but just don’t know how to deal with nested element, especial if their internal method must be change.<BR>
<BR>
Kind regards,<BR>
Daniel<BR>
<BR>
<BR>
<BR>
On 3/23/09 3:01 PM, in article <A HREF="gq84o0$63b$1@build.eclipse.org">gq84o0$63b$1@build.eclipse.org</A>, "Ed Merks" <<A HREF="Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote:<BR>
<BR>
<BR>
<BLOCKQUOTE>
Daniel,<BR>
<BR>
Comments below.<BR>
<BR>
Daniel OKOUYA wrote: <BR>
<BR>
<BLOCKQUOTE>
Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child Sorry about the multiple post.<BR>
<BR>
Because, I like Things that are well engineer and well thought, and for the evolution of my application, I need to be sure my architecture and etc....<BR>
So if you don’t mind, I would like to do something, that is not going to be broken soon. Because, indeed, several month ago I contacted you about this problem and I’m pretty sure that my code was working. I don’t know when was the update done, but it did change the behavior of my application. <BR>
<BR>
<BR>
</BLOCKQUOTE>
I think it was ages ago.<BR>
<BR>
<BLOCKQUOTE>
But in any case, I think the all point is to have a good interpretation of what should be<BR>
DeleteCommand Behavior. <BR>
<BR>
<BR>
</BLOCKQUOTE>
Of course different people might have different perceptions depending on how they've used things.<BR>
<BR>
<BLOCKQUOTE>
<BR>
So please, for clarity: <BR>
<BR>
1-/ What will or should be the actual behavior of the DELETECOMMAND. <BR>
Semanticaly what you desicribe here: <BR>
<BR>
>>>><BR>
There have certainly been quite set set of changes related to delete command and what should all be deleted, with children being overlooked at one point. I'm not entirely convinced looking at the code now that we should ever be unwrapping objects. Perhaps we should have only been checking instanceof EObject and only in that case do the delete all references part... That probably addresses your issue right? I.e., if we skipped the unwrapping step. Hnmmm.... But I think for feature map entries we have wrappers, and they need to behave the way we have currently. Maybe some improved factoring to make it easy to skip the unwrapping would help... <BR>
>>>><BR>
<BR>
Means a behavior such as The object is not identified as being the object but as the reference of a Parent. Is it the desired behavior that you would like to have?<BR>
<BR>
<BR>
</BLOCKQUOTE>
Other users might have a tree structure they induce with wrappers while still wanting a delete to do the normal thing. When we realized delete didn't properly delete references to children, we added support for walking the children. In any case, the CVS history of the file is public information you can inspect.<BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
<BR>
2-/ In the same line as what you said above concerning the refactoring you said in a preceding post I would like to ask :<BR>
<BR>
>>>>><BR>
<BR>
2-/ Then based on that, can anyone give me an advise about how to make sure that the delete only delete a wrapper and not the object everywhere else?<BR>
<BR>
You could specialize the editing domain's create command so that DeleteCommand is created only for non-wrappers and otherwise a remove command.<BR>
<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE>
3-/ Also, how can I check that the actual item being selected is a wrapper, how does it works?<BR>
<BR>
You can check if if the object implements IWrapperItemProvider.<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
>>>>><BR>
<BR>
<BR>
How do you do the (2) what is the proper way to do that without breaking the code. I mean shall I change the AdapterFactoryEditingDomain ? <BR>
<BR>
</BLOCKQUOTE>
Create a derived class and override the createCommand method to handle your case and then call super. I.e., the usual Java technique.<BR>
<BR>
<BLOCKQUOTE>
If yes, is there any registration I should be aware of before doing that?<BR>
<BR>
<BR>
</BLOCKQUOTE>
The editing domain is created in the editor, so you can create your own version there.<BR>
<BR>
<BLOCKQUOTE>
<BR>
3-/More the same question than Same question for the (3)? Shall I change after subclassing it, where is the proper way to make the test. (I don’t know AdapterFactoryEditingDomain yet)<BR>
<BR>
<BR>
</BLOCKQUOTE>
I suppose just testing that the UI is behaving correctly is the way...<BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
<BR>
Regards,<BR>
Maatari<BR>
<BR>
On 3/23/09 1:00 PM, in article <A HREF="gq7tlq$fca$1@build.eclipse.org">gq7tlq$fca$1@build.eclipse.org</A>, "Ed Merks" <<A HREF="Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote:<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE>
Daniel,<BR>
<BR>
Comments below.<BR>
<BR>
Daniel OKOUYA wrote: <BR>
<BR>
<BR>
<BLOCKQUOTE>
Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child Hi all, <BR>
<BR>
I have the following case: <BR>
<BR>
In my model I have On top a Social Structure which contains roles which in turn contains objectives. However, Because Objective are unique in the model, The real Container of the objective is the Social Structure. Objective are Non-Contained-Child of Roles and Contained child of the Social Structure. I already manage the addition of new objective using a compound command, which when called from the role, add it both to the Social structure and the Role, avoiding de facto the “dangling Reference”.<BR>
<BR>
My problem arises when I try to Delete this object and this is where please, I would require any advises: I want that when I delete an objective from a Role, if this Role or Non-Container Parent is the only one, then delete it both from the Role and its containing Parent which is the Social Structure. Otherwise, the object is removed only from the current Non-Containing-Parent.<BR>
<BR>
Please can any one give me some advise on how to implement it. The problem could be qualified as the general problem of managing shared global object locally as Non-contained-Child.<BR>
<BR>
To be more specific. I already tried implementing a version which as lead me to use ItemWrappers for the Non-contained-child. Those wrappers are created automatically in my RoleItemProvider. Meaning that IsWrappingNeeded always returns true.<BR>
<BR>
<BR>
However I encountered problems when I tried to implement my own DeleteCommand called from my RoleItemProvider.<BR>
<BR>
It seams like The DeleteCommand in any case remove all Item even if the Item is a Warpper which is my problem. Indeed as I sated RemoveAll to true in The ActionBarContributor for the DeleteAction, It is the DeleteCommand which is used and is the general behavior I would like to have expect for Objective. However In its execution it does unwrap Item to find allUsage with a CrossReferencer. Meaning that, It does not focus on the Wrapper only but on what it represent. This situation has invalidate all the logic I have Implemented to check for the condition described above to comply to my the deletion criteria. Indeed with a wrapper, the getParent does not just yield the container. Using some crossReferencer I have been able to make the check discribed above.<BR>
However I ended up with frustration as it was not working. After some debug, and looking into the the DeleteCommand I realize the behavior described earlier which in my opinion is the reason of my bug. Of course it might be anything else, that is why I’m open to any idea in that sense. <BR>
Does any one have a good idea on how to implement this functionality? The only one that I see for now is : <BR>
<BR>
Using the Remove version of the DeleteAction, Implementing my own RemoveCommand specific for Each object called from my Items Providers, and use the EcoreUtil.delete when necessary. While the ides sounds ok. It is customizing the remove instead of customizing the delete. It seams to heavy and ugly to me. Therefore I think there might be another way.<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
There have certainly been quite set set of changes related to delete command and what should all be deleted, with children being overlooked at one point. I'm not entirely convinced looking at the code now that we should ever be unwrapping objects. Perhaps we should have only been checking instanceof EObject and only in that case do the delete all references part... That probably addresses your issue right? I.e., if we skipped the unwrapping step. Hnmmm.... But I think for feature map entries we have wrappers, and they need to behave the way we have currently. Maybe some improved factoring to make it easy to skip the unwrapping would help... <BR>
<BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
Please, do not hesitate on the suggestion.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-hgiXoEUIdNJjRRm2UabM--
|
|
| |
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428586 is a reply to message #428540] |
Tue, 24 March 2009 19:54 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3320772853_721301
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit
Many Thx.
Dan
On 3/24/09 7:54 PM, in article 1237920860.7244.21.camel@cdamus-laptop,
"Christian W. Damus" <give.a.damus@gmail.com> wrote:
> Hi, Daniel,
>
> I don't know anything about multi-page editors in GMF, but I do know that a
> GMF diagram editor expects to work with an instance of the
> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFac tory.DiagramEditin
> gDomain class, because that editing domain implementation does some funky
> handling of the DiagramEventBroker. This factory is a subclass of the
> GMFEditingDomainFactory, which isn't actually what you need (sorry).
>
> So, if you define a subclass of the DiagramEditingDomainFactory that creates a
> subclass of the nested DiagramEditingDomain class, with your customizations,
> then I think you should be able to make it work. I don't know enough about
> your original problem to speak to that; I just jumped into the conversation
> when I saw your question about customizing the transactional editing domain.
> :-)
>
> As you are only looking to customize editing domain behaviours that are
> orthogonal to concerns of transactioning, it should be very simple to define
> the subclasses that you need. The
> TransactionalEditingDomain.Registry.INSTANCE takes care of finding your custom
> factory class from the extension point and using it to create your editing
> domain the first time that it is requested by ID.
>
> HTH,
>
> Christian
>
> On Tue, 2009-03-24 at 19:37 +0100, Daniel OKOUYA wrote:
>> Thanks for the tips. However I think that once you have done the integration
>> the editingdomain is no more created by GMF itself but inside the
>> MultiPageEditor and that is the one that is passed to GMF. But in any case in
>> order to be fully sure I will also provide the modification you required.
>>
>>
>> Just for precision when you mean the GMFEditingDomain you meant
>> TransactionalEditingDomain?
>>
>> Here, the technics should consit in: Extending The interface Transactional
>> Editing domain as well as the Implementation which extends
>> AdapterFactoryEditing domain.
>> In extending the interface, is a bit tricky right? I have to shadow some
>> element already there to support my own instantiation of Factory.Instance,
>> can it work?
>> Regards,
>> Daniel
>>
>>
>>
>> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>
>>
>>> Hi, Daniel,
>>>
>>> Your GMF-generated editor registers its editing domain on the
>>> org.eclipse.emf.transaction.editingDomains extension point. This extension
>>> indicates the domain's unique ID and the factory class used to create it
>>> (usually, this is the GMFEditingDomainFactory).
>>>
>>> You can change your editor's extension to specify a factory of your own
>>> devising, that extends the GMFEditingDomainFactory and creates your own
>>> subclass of the GMF editing domain implementation.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>>>
>>>> Hi I just try to follow your advise here, but I got stuck with the fact
>>>> that because I
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428587 is a reply to message #428536] |
Tue, 24 March 2009 20:18 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3320774297_767787
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit
Sorry the Real Line is this one:
TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
"Christian W. Damus" <give.a.damus@gmail.com> wrote:
> Hi, Daniel,
>
> Your GMF-generated editor registers its editing domain on the
> org.eclipse.emf.transaction.editingDomains extension point. This extension
> indicates the domain's unique ID and the factory class used to create it
> (usually, this is the GMFEditingDomainFactory).
>
> You can change your editor's extension to specify a factory of your own
> devising, that extends the GMFEditingDomainFactory and creates your own
> subclass of the GMF editing domain implementation.
>
> HTH,
>
> Christian
>
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>> Hi I just try to follow your advise here, but I got stuck with the fact that
>> because I
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428588 is a reply to message #428587] |
Tue, 24 March 2009 20:33 |
| Eclipse User |
|
|
|
Originally posted by: give.a.damus.gmail.com
--=-QATKl50E/W1D3aTBeNSi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi, Daniel,
Sorry, as I mentioned, I don't know anything about the generation of
multi-page editors and how that differs from the simple diagram editor
generation which, the last time I used GMF, registered its editor on the
extension point.
If this editor is responsible for creating the editing domain, and it
creates a basic TransactionalEditingDomainImpl (which is what the code
snippet that you quote below would do), then that isn't going to work
nicely with GMF diagram editors because it won't have the special
DiagramEventBroker handling. I suppose you could just change the
generated code to create your custom editing domain, instead (derived
from the DiagramEditingDomain as I mentioned, already).
Other than that, I really don't understand the context of your problem,
so I would probably be more hindrance than help henceforward.
Cheers,
Christian
On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
> Sorry the Real Line is this one:
>=20
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>=20
>=20
> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>=20
>=20
> Hi, Daniel,
> =20
> Your GMF-generated editor registers its editing domain on the
> org.eclipse.emf.transaction.editingDomains extension point.
> This extension indicates the domain's unique ID and the
> factory class used to create it (usually, this is the
> GMFEditingDomainFactory).
> =20
> You can change your editor's extension to specify a factory of
> your own devising, that extends the GMFEditingDomainFactory
> and creates your own subclass of the GMF editing domain
> implementation.
> =20
> HTH,
> =20
> Christian
> =20
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
> =20
> Hi I just try to follow your advise here, but I got
> stuck with the fact that because I=E2=80=99m integrating =
with
> GMF I use a shared Editing Domain.=20
> Would you advise the same thing, subclassing and
> rewriting the transactional editing domain? However if
> I may it is susbtantially a more complicate class,
> indeed,=20
> Its intiation is as follow TransactionalEditingDomain
> domain =3D
> TransactionalEditingDomain.Factory.INSTANCE.createEditing=
Domain();=20
> =20
> Therefore, please, it indeed a bit shamefull :-(, if
> you don=E2=80=99t mind, could you give me an OO advise he=
re,
> as I don=E2=80=99t know how to subclass a class a class t=
hat
> as already nested class, that are static with static
> method etc..... Could help or maybe advise something
> else.=20
> =20
> Indeed, What I wanted to do following your advise was
> to check if the current element is instanceOf
> WrappedItem, and if yes calling remove instead of
> Delete.=20
> I have no problem overiding this method In the
> transactional editing domain, but just don=E2=80=99t know=
how
> to deal with nested element, especial if their
> internal method must be change.
> =20
> Kind regards,
> Daniel
> =20
> =20
> =20
> On 3/23/09 3:01 PM, in article gq84o0$63b
> $1@build.eclipse.org, "Ed Merks" <Ed.Merks@gmail.com>
> wrote:
> =20
> =20
> =20
> Daniel,
> =20
> Comments below.
> =20
> Daniel OKOUYA wrote:=20
> =20
> =20
> Re: Problem with Deletion : Managing
> Localy Shared global Object as
> Non-contained-Child Sorry about the
> multiple post.
> =20
> Because, I like Things that are well
> engineer and well thought, and for the
> evolution of my application, I need to
> be sure my architecture and etc....
> So if you don=E2=80=99t mind, I would li=
ke to
> do something, that is not going to be
> broken soon. Because, indeed, several
> month ago I contacted you about this
> problem and I=E2=80=99m pretty sure that =
my
> code was working. I don=E2=80=99t know wh=
en
> was the update done, but it did change
> the behavior of my application. =20
> =20
> =20
> =20
> I think it was ages ago.
> =20
> =20
> But in any case, I think the all point
> is to have a good interpretation of
> what should be
> DeleteCommand Behavior.=20
> =20
> =20
> =20
> Of course different people might have
> different perceptions depending on how they've
> used things.
> =20
> =20
> =20
> So please, for clarity:=20
> =20
> 1-/ What will or should be the actual
> behavior of the DELETECOMMAND.=20
> Semanticaly what you desicribe here:=20
> =20
> >>>>
> There have certainly been quite set
> set of changes related to delete
> command and what should all be
> deleted, with children being
> overlooked at one point. I'm not
> entirely convinced looking at the code
> now that we should ever be unwrapping
> objects. Perhaps we should have only
> been checking instanceof EObject and
> only in that case do the delete all
> references part... That probably
> addresses your issue right? I.e., if
> we skipped the unwrapping step.
> Hnmmm.... But I think for feature
> map entries we have wrappers, and they
> need to behave the way we have
> currently. Maybe some improved
> factoring to make it easy to skip the
> unwrapping would help...=20
> >>>>
> =20
> Means a behavior such as The object
> is not identified as being the object
> but as the reference of a Parent. Is
> it the desired behavior that you would
> like to have?
> =20
> =20
> =20
> Other users might have a tree structure they
> induce with wrappers while still wanting a
> delete to do the normal thing. When we
> realized delete didn't properly delete
> references to children, we added support for
> walking the children. In any case, the CVS
> history of the file is public information you
> can inspect.
> =20
> =20
> =20
> =20
> =20
> 2-/ In the same line as what you said
> above concerning the refactoring you
> said in a preceding post I would like
> to ask :
> =20
> >>>>>
> =20
> 2-/ Then based on that, can
> anyone give me an advise about how to
> make sure that the delete only delete
> a wrapper and not the object
> everywhere else?
> =20
> You could specialize
> the editing domain's create command so
> that DeleteCommand is created only for
> non-wrappers and otherwise a remove
> command.
> =20
> =20
> =20
> =20
> =20
> 3-/ Also, how can I check that
> the actual item being selected
> is a wrapper, how does it
> works?
> =20
> You can check if if the
> object implements
> IWrapperItemProvider.
> =20
> =20
> =20
> =20
> >>>>>
> =20
> =20
> How do you do the (2) what is the
> proper way to do that without breaking
> the code. I mean shall I change the
> AdapterFactoryEditingDomain ?=20
> =20
> =20
> Create a derived class and override the
> createCommand method to handle your case and
> then call super. I.e., the usual Java
> technique.
> =20
> =20
> If yes, is there any registration I
> should be aware of before doing that?
> =20
> =20
> =20
> The editing domain is created in the editor,
> so you can create your own version there.
> =20
> =20
> =20
> 3-/More the same question than Same
> question for the (3)? Shall I change
> after subclassing it, where is the
> proper way to make the test. (I don=E2=80=
=99t
> know AdapterFactoryEditingDomain yet)
> =20
> =20
> =20
> I suppose just testing that the UI is behaving
> correctly is the way...
> =20
> =20
> =20
> =20
> =20
> Regards,
> Maatari
> =20
> On 3/23/09 1:00 PM, in article gq7tlq
> $fca$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
> =20
> =20
> =20
> =20
> Daniel,
> =20
> Comments below.
> =20
> Daniel OKOUYA wrote:=20
> =20
> =20
> =20
> Problem with
> Deletion : Managing
> Localy Shared global
> Object as
> Non-contained-Child Hi
> all,=20
> =20
> I have the following
> case:=20
> =20
> In my model I have On
> top a Social Structure
> which contains roles
> which in turn contains
> objectives. However,
> Because Objective are
> unique in the model,
> The real Container of
> the objective is the
> Social Structure.
> Objective are
> Non-Contained-Child of
> Roles and Contained
> child of the Social
> Structure. I already
> manage the addition of
> new objective using a
> compound command,
> which when called
> from the role, add it
> both to the Social
> structure and the
> Role, avoiding de
> facto the =E2=80=9Cdangli=
ng
> Reference=E2=80=9D.
> =20
> My problem arises
> when I try to Delete
> this object and this
> is where please, I
> would require any
> advises: I want that
> when I delete an
> objective from a Role,
> if this Role or
> Non-Container Parent
> is the only one, then
> delete it both from
> the Role and its
> containing Parent
> which is the Social
> Structure. Otherwise,
> the object is removed
> only from the current
> Non-Containing-Parent.
> =20
> Please can any one
> give me some advise on
> how to implement it.
> The problem could be
> qualified as the
> general problem of
> managing shared global
> object locally as
> Non-contained-Child.
> =20
> To be more specific.
> I already tried
> implementing a version
> which as lead me to
> use ItemWrappers for
> the
> Non-contained-child.
> Those wrappers are
> created automatically
> in my
> RoleItemProvider.
> Meaning that
> IsWrappingNeeded
> always returns true.
> =20
> =20
> However I encountered
> problems when I tried
> to implement my own
> DeleteCommand called
> from my
> RoleItemProvider.
> =20
> It seams like The
> DeleteCommand in any
> case remove all Item
> even if the Item is a
> Warpper which is my
> problem. Indeed as I
> sated RemoveAll to
> true in The
> ActionBarContributor
> for the DeleteAction,
> It is the
> DeleteCommand which
> is used and is the
> general behavior I
> would like to have
> expect for Objective.
> However In its
> execution it does
> unwrap Item to find
> allUsage with a
> CrossReferencer.
> Meaning that, It does
> not focus on the
> Wrapper only but on
> what it represent.
> This situation has
> invalidate all the
> logic I have
> Implemented to check
> for the condition
> described above to
> comply to my the
> deletion criteria.
> Indeed with a wrapper,
> the getParent does not
> just yield the
> container. Using some
> crossReferencer I have
> been able to make the
> check discribed above.
> However I ended up
> with frustration as it
> was not working. After
> some debug, and
> looking into the the
> DeleteCommand I
> realize the behavior
> described earlier
> which in my opinion is
> the reason of my bug.
> Of course it might be
> anything else, that is
> why I=E2=80=99m open to a=
ny
> idea in that sense.=20
> Does any one have a
> good idea on how to
> implement this
> functionality? The
> only one that I see
> for now is :=20
> =20
> Using the Remove
> version of the
> DeleteAction,
> Implementing my own
> RemoveCommand specific
> for Each object called
> from my Items
> Providers, and use the
> EcoreUtil.delete when
> necessary. While the
> ides sounds ok. It is
> customizing the remove
> instead of customizing
> the delete. It seams
> to heavy and ugly to
> me. Therefore I think
> there might be another
> way.
> =20
> =20
> =20
> =20
> There have certainly been
> quite set set of changes
> related to delete command and
> what should all be deleted,
> with children being overlooked
> at one point. I'm not
> entirely convinced looking at
> the code now that we should
> ever be unwrapping objects.
> Perhaps we should have only
> been checking instanceof
> EObject and only in that case
> do the delete all references
> part... That probably
> addresses your issue right?
> I.e., if we skipped the
> unwrapping step. Hnmmm....
> But I think for feature map
> entries we have wrappers, and
> they need to behave the way we
> have currently. Maybe some
> improved factoring to make it
> easy to skip the unwrapping
> would help...=20
> =20
> =20
> =20
> =20
> =20
> Please, do not
> hesitate on the
> suggestion.
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
--=-QATKl50E/W1D3aTBeNSi
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
<TITLE>Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child</TITLE>
</HEAD>
<BODY>
Hi, Daniel,<BR>
<BR>
Sorry, as I mentioned, I don't know anything about the generation of multi-page editors and how that differs from the simple diagram editor generation which, the last time I used GMF, registered its editor on the extension point.<BR>
<BR>
If this editor is responsible for creating the editing domain, and it creates a basic TransactionalEditingDomainImpl (which is what the code snippet that you quote below would do), then that isn't going to work nicely with GMF diagram editors because it won't have the special DiagramEventBroker handling. I suppose you could just change the generated code to create your custom editing domain, instead (derived from the DiagramEditingDomain as I mentioned, already).<BR>
<BR>
Other than that, I really don't understand the context of your problem, so I would probably be more hindrance than help henceforward.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Sorry the Real Line is this one:<BR>
<BR>
TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain(); <BR>
<BR>
<BR>
On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop, "Christian W. Damus" <<A HREF="give.a.damus@gmail.com">give.a.damus@gmail.com</A>> wrote:<BR>
<BR>
<BLOCKQUOTE>
Hi, Daniel,<BR>
<BR>
Your GMF-generated editor registers its editing domain on the org.eclipse.emf.transaction.editingDomains extension point. This extension indicates the domain's unique ID and the factory class used to create it (usually, this is the GMFEditingDomainFactory).<BR>
<BR>
You can change your editor's extension to specify a factory of your own devising, that extends the GMFEditingDomainFactory and creates your own subclass of the GMF editing domain implementation.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:<BR>
<BLOCKQUOTE>
Hi I just try to follow your advise here, but I got stuck with the fact that because I’m integrating with GMF I use a shared Editing Domain. <BR>
Would you advise the same thing, subclassing and rewriting the transactional editing domain? However if I may it is susbtantially a more complicate class, indeed, <BR>
Its intiation is as follow TransactionalEditingDomain domain = TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain(); <BR>
<BR>
Therefore, please, it indeed a bit shamefull :-(, if you don’t mind, could you give me an OO advise here, as I don’t know how to subclass a class a class that as already nested class, that are static with static method etc..... Could help or maybe advise something else. <BR>
<BR>
Indeed, What I wanted to do following your advise was to check if the current element is instanceOf WrappedItem, and if yes calling remove instead of Delete. <BR>
I have no problem overiding this method In the transactional editing domain, but just don’t know how to deal with nested element, especial if their internal method must be change.<BR>
<BR>
Kind regards,<BR>
Daniel<BR>
<BR>
<BR>
<BR>
On 3/23/09 3:01 PM, in article <A HREF="gq84o0$63b$1@build.eclipse.org">gq84o0$63b$1@build.eclipse.org</A>, "Ed Merks" <<A HREF="Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote:<BR>
<BR>
<BR>
<BLOCKQUOTE>
Daniel,<BR>
<BR>
Comments below.<BR>
<BR>
Daniel OKOUYA wrote: <BR>
<BR>
<BLOCKQUOTE>
Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child Sorry about the multiple post.<BR>
<BR>
Because, I like Things that are well engineer and well thought, and for the evolution of my application, I need to be sure my architecture and etc....<BR>
So if you don’t mind, I would like to do something, that is not going to be broken soon. Because, indeed, several month ago I contacted you about this problem and I’m pretty sure that my code was working. I don’t know when was the update done, but it did change the behavior of my application. <BR>
<BR>
<BR>
</BLOCKQUOTE>
I think it was ages ago.<BR>
<BR>
<BLOCKQUOTE>
But in any case, I think the all point is to have a good interpretation of what should be<BR>
DeleteCommand Behavior. <BR>
<BR>
<BR>
</BLOCKQUOTE>
Of course different people might have different perceptions depending on how they've used things.<BR>
<BR>
<BLOCKQUOTE>
<BR>
So please, for clarity: <BR>
<BR>
1-/ What will or should be the actual behavior of the DELETECOMMAND. <BR>
Semanticaly what you desicribe here: <BR>
<BR>
>>>><BR>
There have certainly been quite set set of changes related to delete command and what should all be deleted, with children being overlooked at one point. I'm not entirely convinced looking at the code now that we should ever be unwrapping objects. Perhaps we should have only been checking instanceof EObject and only in that case do the delete all references part... That probably addresses your issue right? I.e., if we skipped the unwrapping step. Hnmmm.... But I think for feature map entries we have wrappers, and they need to behave the way we have currently. Maybe some improved factoring to make it easy to skip the unwrapping would help... <BR>
>>>><BR>
<BR>
Means a behavior such as The object is not identified as being the object but as the reference of a Parent. Is it the desired behavior that you would like to have?<BR>
<BR>
<BR>
</BLOCKQUOTE>
Other users might have a tree structure they induce with wrappers while still wanting a delete to do the normal thing. When we realized delete didn't properly delete references to children, we added support for walking the children. In any case, the CVS history of the file is public information you can inspect.<BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
<BR>
2-/ In the same line as what you said above concerning the refactoring you said in a preceding post I would like to ask :<BR>
<BR>
>>>>><BR>
<BR>
2-/ Then based on that, can anyone give me an advise about how to make sure that the delete only delete a wrapper and not the object everywhere else?<BR>
<BR>
You could specialize the editing domain's create command so that DeleteCommand is created only for non-wrappers and otherwise a remove command.<BR>
<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE>
3-/ Also, how can I check that the actual item being selected is a wrapper, how does it works?<BR>
<BR>
You can check if if the object implements IWrapperItemProvider.<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
>>>>><BR>
<BR>
<BR>
How do you do the (2) what is the proper way to do that without breaking the code. I mean shall I change the AdapterFactoryEditingDomain ? <BR>
<BR>
</BLOCKQUOTE>
Create a derived class and override the createCommand method to handle your case and then call super. I.e., the usual Java technique.<BR>
<BR>
<BLOCKQUOTE>
If yes, is there any registration I should be aware of before doing that?<BR>
<BR>
<BR>
</BLOCKQUOTE>
The editing domain is created in the editor, so you can create your own version there.<BR>
<BR>
<BLOCKQUOTE>
<BR>
3-/More the same question than Same question for the (3)? Shall I change after subclassing it, where is the proper way to make the test. (I don’t know AdapterFactoryEditingDomain yet)<BR>
<BR>
<BR>
</BLOCKQUOTE>
I suppose just testing that the UI is behaving correctly is the way...<BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
<BR>
Regards,<BR>
Maatari<BR>
<BR>
On 3/23/09 1:00 PM, in article <A HREF="gq7tlq$fca$1@build.eclipse.org">gq7tlq$fca$1@build.eclipse.org</A>, "Ed Merks" <<A HREF="Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote:<BR>
<BR>
<BR>
<BR>
<BLOCKQUOTE>
Daniel,<BR>
<BR>
Comments below.<BR>
<BR>
Daniel OKOUYA wrote: <BR>
<BR>
<BR>
<BLOCKQUOTE>
Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child Hi all, <BR>
<BR>
I have the following case: <BR>
<BR>
In my model I have On top a Social Structure which contains roles which in turn contains objectives. However, Because Objective are unique in the model, The real Container of the objective is the Social Structure. Objective are Non-Contained-Child of Roles and Contained child of the Social Structure. I already manage the addition of new objective using a compound command, which when called from the role, add it both to the Social structure and the Role, avoiding de facto the “dangling Reference”.<BR>
<BR>
My problem arises when I try to Delete this object and this is where please, I would require any advises: I want that when I delete an objective from a Role, if this Role or Non-Container Parent is the only one, then delete it both from the Role and its containing Parent which is the Social Structure. Otherwise, the object is removed only from the current Non-Containing-Parent.<BR>
<BR>
Please can any one give me some advise on how to implement it. The problem could be qualified as the general problem of managing shared global object locally as Non-contained-Child.<BR>
<BR>
To be more specific. I already tried implementing a version which as lead me to use ItemWrappers for the Non-contained-child. Those wrappers are created automatically in my RoleItemProvider. Meaning that IsWrappingNeeded always returns true.<BR>
<BR>
<BR>
However I encountered problems when I tried to implement my own DeleteCommand called from my RoleItemProvider.<BR>
<BR>
It seams like The DeleteCommand in any case remove all Item even if the Item is a Warpper which is my problem. Indeed as I sated RemoveAll to true in The ActionBarContributor for the DeleteAction, It is the DeleteCommand which is used and is the general behavior I would like to have expect for Objective. However In its execution it does unwrap Item to find allUsage with a CrossReferencer. Meaning that, It does not focus on the Wrapper only but on what it represent. This situation has invalidate all the logic I have Implemented to check for the condition described above to comply to my the deletion criteria. Indeed with a wrapper, the getParent does not just yield the container. Using some crossReferencer I have been able to make the check discribed above.<BR>
However I ended up with frustration as it was not working. After some debug, and looking into the the DeleteCommand I realize the behavior described earlier which in my opinion is the reason of my bug. Of course it might be anything else, that is why I’m open to any idea in that sense. <BR>
Does any one have a good idea on how to implement this functionality? The only one that I see for now is : <BR>
<BR>
Using the Remove version of the DeleteAction, Implementing my own RemoveCommand specific for Each object called from my Items Providers, and use the EcoreUtil.delete when necessary. While the ides sounds ok. It is customizing the remove instead of customizing the delete. It seams to heavy and ugly to me. Therefore I think there might be another way.<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
There have certainly been quite set set of changes related to delete command and what should all be deleted, with children being overlooked at one point. I'm not entirely convinced looking at the code now that we should ever be unwrapping objects. Perhaps we should have only been checking instanceof EObject and only in that case do the delete all references part... That probably addresses your issue right? I.e., if we skipped the unwrapping step. Hnmmm.... But I think for feature map entries we have wrappers, and they need to behave the way we have currently. Maybe some improved factoring to make it easy to skip the unwrapping would help... <BR>
<BR>
<BR>
<BLOCKQUOTE>
<BR>
<BR>
Please, do not hesitate on the suggestion.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-QATKl50E/W1D3aTBeNSi--
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428591 is a reply to message #428540] |
Tue, 24 March 2009 21:26 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3320778369_990556
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit
Hi all,
I have done the adaptation advised, namely: making my own
TransactionalEditingdomain.
As defined first an interface :
public interface OperaTransactionalEditingDomain extends
InternalTransactionalEditingDomain {
......................
With a redifinition of the factory as in the following:
interface Factory extends TransactionalEditingDomain.Factory { /**
* Static factory instance that can create instances of the default *
transactional editing domain implementation. */ Factory
INSTANCE = new OperaTransactionalEditingDomainImpl.FactoryImpl();
...............................
}
Meanwhile I defined the Implementation class as such:
public class OperaTransactionalEditingDomainImpl extends
TransactionalEditingDomainImpl implements OperaTransactionalEditingDomain,
InternalTransactionalEditingDomain, Adaptable,
TransactionalEditingDomain.DefaultOptions {
As well as my factoryimpl :
public static class FactoryImpl implements
OperaTransactionalEditingDomain.Factory { // Documentation copied
from the inherited specification public synchronized
TransactionalEditingDomain createEditingDomain() {
TransactionalEditingDomain result = new OperaTransactionalEditingDomainImpl(
new
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE))
; mapResourceSet(result); return result; }
...............
}
I have attached the file with the source: The interface as well as the
implementation. I hope you can check it, it will be straightforward, I did
not had any customization yet only what is necessary for it to function as
if it was a TransactionalEditingdomainImpl class itself.
However,
Surprisingly :-), it breaks the Diagram code. No error but, the diamgram
Page doesn
|
|
|
| Re: Problem with Deletion : files [message #428595 is a reply to message #428588] |
Tue, 24 March 2009 21:42 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3320786648_1546777
Content-type: multipart/alternative;
boundary="B_3320786648_1544405"
--B_3320786648_1544405
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: 8bit
Sorry, I forgot the files in the preceding mail
Thx, in adavance.
On 3/24/09 9:33 PM, in article 1237926781.7244.28.camel@cdamus-laptop,
"Christian W. Damus" <give.a.damus@gmail.com> wrote:
> Hi, Daniel,
>
> Sorry, as I mentioned, I don't know anything about the generation of
> multi-page editors and how that differs from the simple diagram editor
> generation which, the last time I used GMF, registered its editor on the
> extension point.
>
> If this editor is responsible for creating the editing domain, and it creates
> a basic TransactionalEditingDomainImpl (which is what the code snippet that
> you quote below would do), then that isn't going to work nicely with GMF
> diagram editors because it won't have the special DiagramEventBroker handling.
> I suppose you could just change the generated code to create your custom
> editing domain, instead (derived from the DiagramEditingDomain as I mentioned,
> already).
>
> Other than that, I really don't understand the context of your problem, so I
> would probably be more hindrance than help henceforward.
>
> Cheers,
>
> Christian
>
>
> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>> Sorry the Real Line is this one:
>>
>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>
>>
>> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>
>>
>>> Hi, Daniel,
>>>
>>> Your GMF-generated editor registers its editing domain on the
>>> org.eclipse.emf.transaction.editingDomains extension point. This extension
>>> indicates the domain's unique ID and the factory class used to create it
>>> (usually, this is the GMFEditingDomainFactory).
>>>
>>> You can change your editor's extension to specify a factory of your own
>>> devising, that extends the GMFEditingDomainFactory and creates your own
>>> subclass of the GMF editing domain implementation.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>>>
>>>> Hi I just try to follow your advise here, but I got stuck with the fact
>>>> that because I
|
|
| |
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428606 is a reply to message #428601] |
Wed, 25 March 2009 11:40 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030606000508060109010404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
This is certainly a very long running thread and the formatting of this
posting effectively makes it impossible to consume. You have to stop
and figure too that there is a limit on how much time folks have to help
with the minutiae of someone's specific problems. Certainly helping
with the details of GMF's editors and how transactional editing domains
are create is beyond what I personally have the skills to address... I
often find that people under utilize the debugger. Looking at source
code statically is not nearly as effective as setting and hitting a
breakpoint and seeing a stack illustrating how dynamic execution got to
that point in the code. I know these frameworks are very complex
(they're solving hard problems so it's inevitable) and that the layers
of them just makes it more complex, but there's only so much free time
to help people...
I still wonder if there isn't some good trick that could be employed
right in the DeleteCommand itself. Here's a *completely untested*
change to DeleteCommand's execute method:
@Override
public void execute()
{
Collection<EObject> eObjects = new LinkedHashSet<EObject>();
Map<Notifier, Collection<EObject>> childrenMap = new
LinkedHashMap<Notifier, Collection<EObject>>();
for (Object wrappedObject : collection)
{
Object object = AdapterFactoryEditingDomain.unwrap(wrappedObject);
if (object instanceof EObject)
{
EObject eObject = (EObject)object;
eObjects.add(eObject);
Collection<EObject> all = new LinkedHashSet<EObject>();
all.add(eObject);
childrenMap.put(eObject, all);
for (Iterator<EObject> j = eObject.eAllContents();
j.hasNext(); )
{
EObject child = j.next();
eObjects.add(child);
all.add(child);
}
}
else if (object instanceof Resource)
{
Resource resource = (Resource)object;
Collection<EObject> all = new LinkedHashSet<EObject>();
childrenMap.put(resource, all);
for (Iterator<EObject> j = resource.getAllContents();
j.hasNext(); )
{
EObject child = j.next();
eObjects.add(child);
all.add(child);
}
}
}
Map<EObject, Collection<EStructuralFeature.Setting>> usages =
EcoreUtil.UsageCrossReferencer.findAll(eObjects,
domain.getResourceSet());
super.execute();
for (Map.Entry<Notifier, Collection<EObject>> entry :
childrenMap.entrySet())
{
Notifier root = entry.getKey();
if (root instanceof EObject)
{
EObject eObject = (EObject)root;
if (eObject.eContainer() != null || eObject.eResource() != null)
{
usages.keySet().removeAll(entry.getValue());
}
}
else if (root instanceof Resource)
{
Resource resource = (Resource)root;
if (resource.getResourceSet() != null)
{
usages.keySet().removeAll(entry.getValue());
}
}
}
for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>>
entry : usages.entrySet())
{
EObject eObject = entry.getKey();
Collection<EStructuralFeature.Setting> settings =
entry.getValue();
for (EStructuralFeature.Setting setting : settings)
{
EObject referencingEObject = setting.getEObject();
if (!eObjects.contains(referencingEObject))
{
EStructuralFeature eStructuralFeature =
setting.getEStructuralFeature();
if (eStructuralFeature.isChangeable())
{
if (eStructuralFeature.isMany())
{
appendAndExecute(RemoveCommand.create(domain,
referencingEObject, eStructuralFeature, eObject));
}
else
{
appendAndExecute(SetCommand.create(domain,
referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));
}
}
}
}
}
}
The idea being that we keep track of which roots each set of children
descends from and after executing the call to super, we check to see
which roots are still actually attached via containment to a parent.
So if the delete merely removed a wrapper from its parent, we'd detect
that and not clean up all references to it. You might want to give that
a try...
Daniel OKOUYA wrote:
> Hey Christian,
>
> Thx for the comment in any case. But still, as I need to search in
> many direction, could you please at least have a look at my 2 class
> and let me know if what I'm doing from an OO point of view is correct.
> The subclassing of the couple Interfacte/class with their respective
> nested class. Please, that would help in narrowing the research to
> resolve this issue. Eliminating the facto this aspect. If you can't
> download the file here are the sources code (I'm not yet comfortable
> in formatting with my current news reader so sorry about that).
>
> public class OperaTransactionalEditingDomainImpl extends
> TransactionalEditingDomainImpl implements
> OperaTransactionalEditingDomain, InternalTransactionalEditingDomain,
> Adaptable, OperaTransactionalEditingDomain.DefaultOptions {
> public OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory) { super(adapterFactory); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
> TransactionalCommandStack stack) {
> super(adapterFactory, stack); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
> ResourceSet resourceSet) { super(adapterFactory,
> resourceSet); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
> TransactionalCommandStack stack, ResourceSet resourceSet) {
> super(adapterFactory, stack, resourceSet); } /**
> * Default implementation of a transaction editing domain factory.
> This * class creates {@link TransactionalEditingDomainImpl}s and
> provides the mapping of * resource sets to editing domain
> instances. * <p> * Clients that implement their own factory
> can plug in to the mapping * of resource sets to editing domains
> using the static instance's * {@link
> #mapResourceSet(TransactionalEditingDomain)} and * {@link
> #unmapResourceSet(TransactionalEditingDomain)} methods by casting the
> * {@link TransactionalEditingDomain.Factory#INSTANCE} to the *
> <code>TransactionalEditingDomainImpl.FactoryImpl</code> type. *
> </p> * * @author Christian W. Damus (cdamus) */ public
> static class FactoryImpl implements
> OperaTransactionalEditingDomain.Factory { // Documentation
> copied from the inherited specification public synchronized
> TransactionalEditingDomain createEditingDomain() {
> TransactionalEditingDomain result = new
> OperaTransactionalEditingDomainImpl( new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE));
> mapResourceSet(result); return
> result; } // Documentation copied from the inherited
> specification public synchronized TransactionalEditingDomain
> createEditingDomain(ResourceSet rset) {
> TransactionalEditingDomain result = new
> OperaTransactionalEditingDomainImpl( new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE),
> rset); mapResourceSet(result); return result;
> } // Documentation copied from the inherited
> specification public TransactionalEditingDomain
> getEditingDomain(ResourceSet rset) {
> TransactionalEditingDomain result = null;
> ResourceSetDomainLink link = (ResourceSetDomainLink)
> EcoreUtil.getAdapter( rset.eAdapters(),
> ResourceSetDomainLink.class); if (link
> != null) { result = link.getDomain(); }
> return result; } /** * Adds the
> specified editing domain to the global reverse mapping * of
> resource sets. * * @param domain the editing domain to
> add to the resource set mapping */ public synchronized
> void mapResourceSet(TransactionalEditingDomain domain) {
> domain.getResourceSet().eAdapters().add(
> new ResourceSetDomainLink(domain)); }
> /** * Removes the specified editing domain from the
> global reverse mapping * of resource sets. * *
> @param domain the editing domain to remove from the resource set
> mapping */ public synchronized void
> unmapResourceSet(TransactionalEditingDomain domain) { for
> (Iterator<Adapter> iter =
> domain.getResourceSet().eAdapters().iterator();
> iter.hasNext();) { Adapter next =
> iter.next(); if
> (next.isAdapterForType(ResourceSetDomainLink.class)) {
> iter.remove(); // continue
> processing because maybe there are multiple //
> links to the same domain } } }
> /** * An adapter that attaches a weak reference
> to the editing domain * onto the resource set that it manages.
> * * @author Christian W. Damus (cdamus) */
> private static class ResourceSetDomainLink extends AdapterImpl
> implements IEditingDomainProvider { private final
> WeakReference<TransactionalEditingDomain> domain;
> ResourceSetDomainLink(TransactionalEditingDomain domain2) {
> this.domain = new
> WeakReference<TransactionalEditingDomain>(domain2); }
> @Override public boolean isAdapterForType(Object
> type) { return (type == ResourceSetDomainLink.class) ||
> (type == IEditingDomainProvider.class); }
> final TransactionalEditingDomain getDomain() {
> TransactionalEditingDomain result = domain.get();
> if (result == null) { // no longer
> need the adapter
> getTarget().eAdapters().remove(this);
> } return result; }
> public final EditingDomain getEditingDomain() {
> return getDomain(); } }//private
> } //Factory // @Override // public Command
> createCommand(Class<? extends Command> commandClass, //
> CommandParameter commandParameter) { // //
> if (commandClass == DeleteCommand.class) { // //
> if () { // // } //
> return new DeleteCommand(this,
> commandParameter.getCollection()); // } // return
> super.createCommand(commandClass, commandParameter); // } }
> And finally the interface:
>
> package opera.domain; import
> org.eclipse.emf.ecore.resource.ResourceSet; import
> org.eclipse.emf.transaction.TransactionalEditingDomain; import
> org.eclipse.emf.transaction.impl.InternalTransactionalEditin gDomain;
> public interface OperaTransactionalEditingDomain extends
> InternalTransactionalEditingDomain { /** * This is a
> copy/Paste from the Parent interface with one modification * to
> support our own TransactionalDomain Implementation. * Interface
> defining the protocol for creating transactional editing *
> domains. Non-shared editing domains can be created by accessing the
> * static factory {@link #INSTANCE}. Shared editing domains
> (registered * on the
> <code>org.eclipse.emf.transaction.editingDomains</code> *
> extension point are obtained via the {@link Registry}. * *
> @author Christian W. Damus (cdamus) */ interface Factory
> extends TransactionalEditingDomain.Factory { /** *
> Static factory instance that can create instances of the default
> * transactional editing domain implementation. */
> Factory INSTANCE = new
> OperaTransactionalEditingDomainImpl.FactoryImpl(); /**
> * Creates an editing domain with a default resource set
> implementation. * * @return the new editing domain
> */ TransactionalEditingDomain createEditingDomain();
> /** * Creates a new transactional editing
> domain on the specified resource * set. Although it is
> possible to create multiple editing domains on * the same
> resource set, this would rarely be useful. * * @param
> rset the resource set * * @return a new editing domain
> on the supplied resource set */
> TransactionalEditingDomain createEditingDomain(ResourceSet
> rset); /** * Obtains the transactional editing
> domain (if any) that is currently * managing the specified
> resource set. * * @param rset a resource set *
> * @return its editing domain, or <code>null</code> if it is
> not managed * by any
> <code>TransactionalEditingDomain</code> */
> TransactionalEditingDomain getEditingDomain(ResourceSet rset); }
> }
> I think normally it should do the trick. However as I told you the
> integration of GMF and EMF editor works fine when I don't use my
> Transactional editing domain. It is only when I replace the simple
> line of instanciation which means just adding the prefix opera to the
> TransactionalEditingdomain.Factory.Instance, then the diagram Editor
> does work. For now on it pertains to magical phenomenon :-). I need
> some demystification here lol.
>
>
>
> On 3/24/09 9:33 PM, in article 1237926781.7244.28.camel@cdamus-laptop,
> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>
> Hi, Daniel,
>
> Sorry, as I mentioned, I don't know anything about the generation
> of multi-page editors and how that differs from the simple diagram
> editor generation which, the last time I used GMF, registered its
> editor on the extension point.
>
> If this editor is responsible for creating the editing domain, and
> it creates a basic TransactionalEditingDomainImpl (which is what
> the code snippet that you quote below would do), then that isn't
> going to work nicely with GMF diagram editors because it won't
> have the special DiagramEventBroker handling. I suppose you could
> just change the generated code to create your custom editing
> domain, instead (derived from the DiagramEditingDomain as I
> mentioned, already).
>
> Other than that, I really don't understand the context of your
> problem, so I would probably be more hindrance than help henceforward.
>
> Cheers,
>
> Christian
>
>
> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>
> Sorry the Real Line is this one:
>
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>
>
> On 3/24/09 6:25 PM, in article
> 1237915526.7244.12.camel@cdamus-laptop, "Christian W. Damus"
> <give.a.damus@gmail.com> wrote:
>
>
>
> Hi, Daniel,
>
> Your GMF-generated editor registers its editing domain on
> the org.eclipse.emf.transaction.editingDomains extension
> point. This extension indicates the domain's unique ID
> and the factory class used to create it (usually, this is
> the GMFEditingDomainFactory).
>
> You can change your editor's extension to specify a
> factory of your own devising, that extends the
> GMFEditingDomainFactory and creates your own subclass of
> the GMF editing domain implementation.
>
> HTH,
>
> Christian
>
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>
>
> Hi I just try to follow your advise here, but I got
> stuck with the fact that because I'm integrating with
> GMF I use a shared Editing Domain.
> Would you advise the same thing, subclassing and
> rewriting the transactional editing domain? However if
> I may it is susbtantially a more complicate class,
> indeed,
> Its intiation is as follow
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>
>
> Therefore, please, it indeed a bit shamefull :-(, if
> you don't mind, could you give me an OO advise here,
> as I don't know how to subclass a class a class that
> as already nested class, that are static with static
> method etc..... Could help or maybe advise something
> else.
>
> Indeed, What I wanted to do following your advise
> was to check if the current element is instanceOf
> WrappedItem, and if yes calling remove instead of Delete.
> I have no problem overiding this method In the
> transactional editing domain, but just don't know how
> to deal with nested element, especial if their
> internal method must be change.
>
> Kind regards,
> Daniel
>
>
>
> On 3/23/09 3:01 PM, in article
> gq84o0$63b$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
>
>
>
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
>
> Re: Problem with Deletion : Managing Localy
> Shared global Object as Non-contained-Child
> Sorry about the multiple post.
>
> Because, I like Things that are well
> engineer and well thought, and for the
> evolution of my application, I need to be sure
> my architecture and etc....
> So if you don't mind, I would like to do
> something, that is not going to be broken
> soon. Because, indeed, several month ago I
> contacted you about this problem and I'm
> pretty sure that my code was working. I don't
> know when was the update done, but it did
> change the behavior of my application.
>
>
>
>
> I think it was ages ago.
>
>
>
> But in any case, I think the all point is to
> have a good interpretation of what should be
> DeleteCommand Behavior.
>
>
>
>
> Of course different people might have different
> perceptions depending on how they've used things.
>
>
>
>
> So please, for clarity:
>
> 1-/ What will or should be the actual
> behavior of the DELETECOMMAND.
> Semanticaly what you desicribe here:
>
> >>>>
> There have certainly been quite set set of
> changes related to delete command and what
> should all be deleted, with children being
> overlooked at one point. I'm not entirely
> convinced looking at the code now that we
> should ever be unwrapping objects. Perhaps we
> should have only been checking instanceof
> EObject and only in that case do the delete
> all references part... That probably
> addresses your issue right? I.e., if we
> skipped the unwrapping step. Hnmmm.... But I
> think for feature map entries we have
> wrappers, and they need to behave the way we
> have currently. Maybe some improved factoring
> to make it easy to skip the unwrapping would
> help...
> >>>>
>
> Means a behavior such as The object is not
> identified as being the object but as the
> reference of a Parent. Is it the desired
> behavior that you would like to have?
>
>
>
>
> Other users might have a tree structure they
> induce with wrappers while still wanting a delete
> to do the normal thing. When we realized delete
> didn't properly delete references to children, we
> added support for walking the children. In any
> case, the CVS history of the file is public
> information you can inspect.
>
>
>
>
>
>
> 2-/ In the same line as what you said above
> concerning the refactoring you said in a
> preceding post I would like to ask :
>
> >>>>>
>
> 2-/ Then based on that, can anyone
> give me an advise about how to make sure that
> the delete only delete a wrapper and not the
> object everywhere else?
>
> You could specialize the
> editing domain's create command so that
> DeleteCommand is created only for non-wrappers
> and otherwise a remove command.
>
>
>
>
>
>
> 3-/ Also, how can I check that the actual
> item being selected is a wrapper, how does
> it works?
>
> You can check if if the object
> implements IWrapperItemProvider.
>
>
>
>
>
> >>>>>
>
>
> How do you do the (2) what is the proper
> way to do that without breaking the code. I
> mean shall I change the
> AdapterFactoryEditingDomain ?
>
>
>
> Create a derived class and override the
> createCommand method to handle your case and then
> call super. I.e., the usual Java technique.
>
>
>
> If yes, is there any registration I should be
> aware of before doing that?
>
>
>
>
> The editing domain is created in the editor, so
> you can create your own version there.
>
>
>
>
> 3-/More the same question than Same question
> for the (3)? Shall I change after subclassing
> it, where is the proper way to make the test.
> (I don't know AdapterFactoryEditingDomain yet)
>
>
>
>
> I suppose just testing that the UI is behaving
> correctly is the way...
>
>
>
>
>
>
> Regards,
> Maatari
>
> On 3/23/09 1:00 PM, in article
> gq7tlq$fca$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
>
>
>
>
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
>
>
> Problem with Deletion : Managing Localy Shared global Object as
> Non-contained-Child Hi all,
>
> I have the following case:
>
> In my model I have On top a Social Structure which contains roles
> which in turn contains objectives. However, Because Objective are
> unique in the model, The real Container of the objective is the Social
> Structure. Objective are Non-Contained-Child of Roles and Contained
> child of the Social Structure. I already manage the addition of new
> objective using a compound command, which when called from the role,
> add it both to the Social structure and the Role, avoiding de facto
> the "dangling Reference".
>
> My problem arises when I try to Delete this object and this is where
> please, I would require any advises: I want that when I delete an
> objective from a Role, if this Role or Non-Container Parent is the
> only one, then delete it both from the Role and its containing Parent
> which is the Social Structure. Otherwise, the object is removed only
> from the current Non-Containing-Parent.
>
> Please can any one give me some advise on how to implement it. The
> problem could be qualified as the general problem of managing shared
> global object locally as Non-contained-Child.
>
> To be more specific. I already tried implementing a version which
> as lead me to use ItemWrappers for the Non-contained-child. Those
> wrappers are created automatically in my RoleItemProvider. Meaning
> that IsWrappingNeeded always returns true.
>
>
> However I encountered problems when I tried to implement my own
> DeleteCommand called from my RoleItemProvider.
>
> It seams like The DeleteCommand in any case remove all Item even if
> the Item is a Warpper which is my problem. Indeed as I sated RemoveAll
> to true in The ActionBarContributor for the DeleteAction, It is the
> DeleteCommand which is used and is the general behavior I would like
> to have expect for Objective. However In its execution it does
> unwrap Item to find allUsage with a CrossReferencer. Meaning that, It
> does not focus on the Wrapper only but on what it represent. This
> situation has invalidate all the logic I have Implemented to check for
> the condition described above to comply to my the deletion criteria.
> Indeed with a wrapper, the getParent does not just yield the
> container. Using some crossReferencer I have been able to make the
> check discribed above.
> However I ended up with frustration as it was not working. After
> some debug, and looking into the the DeleteCommand I realize the
> behavior described earlier which in my opinion is the reason of my
> bug. Of course it might be anything else, that is why I'm open to any
> idea in that sense.
> Does any one have a good idea on how to implement this
> functionality? The only one that I see for now is :
>
> Using the Remove version of the DeleteAction, Implementing my own
> RemoveCommand specific for Each object called from my Items Providers,
> and use the EcoreUtil.delete when necessary. While the ides sounds
> ok. It is customizing the remove instead of customizing the delete. It
> seams to heavy and ugly to me. Therefore I think there might be
> another way.
>
>
>
>
>
> There have certainly been quite set set of
> changes related to delete command and what
> should all be deleted, with children being
> overlooked at one point. I'm not entirely
> convinced looking at the code now that we
> should ever be unwrapping objects.
> Perhaps we should have only been checking
> instanceof EObject and only in that case
> do the delete all references part... That
> probably addresses your issue right? I.e.,
> if we skipped the unwrapping step.
> Hnmmm.... But I think for feature map
> entries we have wrappers, and they need to
> behave the way we have currently. Maybe
> some improved factoring to make it easy to
> skip the unwrapping would help...
>
>
>
>
>
>
> Please, do not hesitate on the suggestion.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--------------030606000508060109010404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel,<br>
<br>
This is certainly a very long running thread and the formatting of this
posting effectively makes it impossible to consume. You have to stop
and figure too that there is a limit on how much time folks have to
help with the minutiae of someone's specific problems. Certainly
helping with the details of GMF's editors and how transactional editing
domains are create is beyond what I personally have the skills to
address... I often find that people under utilize the debugger.
Looking at source code statically is not nearly as effective as setting
and hitting a breakpoint and seeing a stack illustrating how dynamic
execution got to that point in the code. I know these frameworks are
very complex (they're solving hard problems so it's inevitable) and
that the layers of them just makes it more complex, but there's only so
much free time to help people...<br>
<br>
I still wonder if there isn't some good trick that could be employed
right in the DeleteCommand itself. Here's a <b>completely untested</b>
change to DeleteCommand's execute method:<br>
<blockquote><small> @Override</small><br>
<small> public void execute()</small><br>
<small> {</small><br>
<small> Collection<EObject> eObjects = new
LinkedHashSet<EObject>();</small><br>
<small> Map<Notifier, Collection<EObject>> childrenMap
= new LinkedHashMap<Notifier, Collection<EObject>>();</small><br>
<small> for (Object wrappedObject : collection)</small><br>
<small> {</small><br>
<small> Object object =
AdapterFactoryEditingDomain.unwrap(wrappedObject);</small><br >
<small> if (object instanceof EObject)</small><br>
<small> {</small><br>
<small> EObject eObject = (EObject)object;</small><br>
<small> eObjects.add(eObject);</small><br>
<small> Collection<EObject> all = new
LinkedHashSet<EObject>();</small><br>
<small> all.add(eObject);</small><br>
<small> childrenMap.put(eObject, all);</small><br>
<small> for (Iterator<EObject> j =
eObject.eAllContents(); j.hasNext(); )</small><br>
<small> {</small><br>
<small> EObject child = j.next();</small><br>
<small> eObjects.add(child);</small><br>
<small> all.add(child);</small><br>
<small> }</small><br>
<small> }</small><br>
<small> else if (object instanceof Resource)</small><br>
<small> {</small><br>
<small> Resource resource = (Resource)object;</small><br>
<small> Collection<EObject> all = new
LinkedHashSet<EObject>();</small><br>
<small> childrenMap.put(resource, all);</small><br>
<small> for (Iterator<EObject> j =
resource.getAllContents(); j.hasNext(); )</small><br>
<small> {</small><br>
<small> EObject child = j.next();</small><br>
<small> eObjects.add(child);</small><br>
<small> all.add(child);</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
<small> </small><br>
<small> Map<EObject,
Collection<EStructuralFeature.Setting>> usages =
EcoreUtil.UsageCrossReferencer.findAll(eObjects,
domain.getResourceSet());</small><br>
<small> </small><br>
<small> super.execute();</small><br>
<small> </small><br>
<small> for (Map.Entry<Notifier, Collection<EObject>>
entry : childrenMap.entrySet())</small><br>
<small> {</small><br>
<small> Notifier root = entry.getKey();</small><br>
<small> if (root instanceof EObject)</small><br>
<small> {</small><br>
<small> EObject eObject = (EObject)root;</small><br>
<small> if (eObject.eContainer() != null ||
eObject.eResource() != null)</small><br>
<small> {</small><br>
<small> usages.keySet().removeAll(entry.getValue());</small><br>
<small> }</small><br>
<small> }</small><br>
<small> else if (root instanceof Resource)</small><br>
<small> {</small><br>
<small> Resource resource = (Resource)root;</small><br>
<small> if (resource.getResourceSet() != null)</small><br>
<small> {</small><br>
<small> usages.keySet().removeAll(entry.getValue());</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
<br>
<small> for (Map.Entry<EObject,
Collection<EStructuralFeature.Setting>> entry :
usages.entrySet())</small><br>
<small> {</small><br>
<small> EObject eObject = entry.getKey();</small><br>
<small> Collection<EStructuralFeature.Setting> settings =
entry.getValue();</small><br>
<small> for (EStructuralFeature.Setting setting : settings)</small><br>
<small> {</small><br>
<small> EObject referencingEObject = setting.getEObject();</small><br>
<small> if (!eObjects.contains(referencingEObject))</small><br>
<small> {</small><br>
<small> EStructuralFeature eStructuralFeature =
setting.getEStructuralFeature();</small><br>
<small> if (eStructuralFeature.isChangeable())</small><br>
<small> {</small><br>
<small> if (eStructuralFeature.isMany())</small><br>
<small> {</small><br>
<small> appendAndExecute(RemoveCommand.create(domain,
referencingEObject, eStructuralFeature, eObject));</small><br>
<small> }</small><br>
<small> else</small><br>
<small> {</small><br>
<small> appendAndExecute(SetCommand.create(domain,
referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
<small> }</small><br>
</blockquote>
The idea being that we keep track of which roots each set of children
descends from and after executing the call to super, we check to see
which roots are still actually attached via containment to a parent.
So if the delete merely removed a wrapper from its parent, we'd detect
that and not clean up all references to it. You might want to give
that a try...<br>
<br>
<br>
Daniel OKOUYA wrote:
<blockquote cite="mid:C5EFC86E.8030%25okouya_d@yahoo.fr" type="cite">
<title>Re: Problem with Deletion : Managing Localy Shared global
Object as Non-contained-Child</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hey Christian, <br>
<br>
Thx for the comment in any case. But still, as I need to search in many
direction, could you please at least have a look at my 2 class and let
me know if what I’m doing from an OO point of view is correct. The
subclassing of the couple Interfacte/class with their respective nested
class. Please, that would help in narrowing the research to resolve
this issue. Eliminating the facto this aspect. If you can’t download
the file here are the sources code (I’m not yet comfortable in
formatting with my current news reader so sorry about that).<br>
<br>
public class OperaTransactionalEditingDomainImpl extends
TransactionalEditingDomainImpl implements
OperaTransactionalEditingDomain, InternalTransactionalEditingDomain,
Adaptable, OperaTransactionalEditingDomain.DefaultOptions {
public OperaTransactionalEditingDomainImpl(AdapterFactory
adapterFactory) { super(adapterFactory); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
Transactio nalCommandStack stack) {
super(adapterFactory, stack); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
ResourceSe t resourceSet) { super(adapterFactory,
resourceSet); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
Transactio nalCommandStack stack, ResourceSet resourceSet) {
super(adapterFactory, stack, resourceSet); } /** *
Default implementation of a transaction editing domain factory. This
* class creates {@link TransactionalEditingDomainImpl}s and
provides the mapping of * resource sets to editing domain
instances. * <p> * Clients that implement their own
factory can plug in to the mapping * of resource sets to editing
domains using the static instance's * {@link
#mapResourceSet(TransactionalEditingDomain)} and * {@link
#unmapResourceSet(TransactionalEditingDomain)} methods by casting the
* {@link TransactionalEditingDomain.Factory#INSTANCE} to the *
<code>TransactionalEditingDomainImpl.FactoryIm pl</code>
type. * </p> * * @author Christian W. Damus (cdamus)
*/ public static class FactoryImpl implements
OperaTransactionalEditingDomain.Factory { // Documentation
copied from the inherited specification public synchronized
TransactionalEditingDomain createEditingDomain() {
Transactio nalEditingDomain result = new
OperaTransactionalEditingDomainImpl( new
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE));
mapResourc eSet(result); return
result; } // Documentation copied from the inherited
specification public synchronized TransactionalEditingDomain
createEditingDomain(ResourceSet rset) {
Transactio nalEditingDomain result = new
OperaTransactionalEditingDomainImpl( new
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE),
rset); mapResourc eSet(result); return result;
} // Documentation copied from the inherited
specification public TransactionalEditingDomain
getEditingDomain(ResourceSet rset) {
Transactio nalEditingDomain result = null;
ResourceSe tDomainLink link = (ResourceSetDomainLink)
EcoreUtil.getAdapter( rset.eAdapters(),
ResourceSetDomainLink.class); if (link !=
null) { result = link.getDomain(); }
return result; } /** * Adds the
specified editing domain to the global reverse mapping * of
resource sets. * * @param domain the editing domain to
add to the resource set mapping */ public synchronized
void mapResourceSet(TransactionalEditingDomain domain) {
domain.get ResourceSet().eAdapters().add(
new ResourceSetDomainLink(domain)); }
/** * Removes the specified editing domain from the
global reverse mapping * of resource sets. * *
@param domain the editing domain to remove from the resource set
mapping */ public synchronized void
unmapResourceSet(TransactionalEditingDomain domain) { for
(Iterator<Adapter> iter =
domain.getResourceSet().eAdapters().iterator();
iter.hasNe xt();) { Adapter next =
iter.next(); if
(next.isAdapterForType(ResourceSetDomainLink.class)) {
&n
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428616 is a reply to message #428610] |
Wed, 25 March 2009 14:13 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050909030001010209020402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
Note that the change I'm suggesting would be to the base implementation
of DeleteCommand directly in EMF. So if you imported that plugin with
source with the PDE's help and made that change directly to the base
code, you could test it... I think this would be a safe change for the
base code because it's unlikely to change behavior in a bad way for
existing clients who want the full recursive delete behavior.
Daniel OKOUYA wrote:
> Many Thanx for your reply and your time too, and I'll definitively
> take into account your remarks. But know that I have been testing and
> making some debugging already. Especially the first time I solve this
> issue ages ago as you said. And today I come back with the same issue
> because of some changes in the code. But in fact, if we think
> carrefully about this, this is precisely because I solve it partially
> with some debugging. Not understanding the all picture. If I had
> understood to the real meaning of DeleteCommand, or at least what it
> intend to do (wether it is still buggy or) I would have not
> implemented my code the way I did. So I'm now spending time on
> something I should have spend time on long time ago.
> So, I definitively understand your remarks, but please, don't feel
> like I'm not getting into the code, it is just that my engineering
> experience tells me that, Big picture is always important !!!!
>
> However, concering your last comment, I thought that it was impossible
> to change the delete command because it is already fixed in the
> AdapterFactoryEditingDomain so how can I change change it ?
>
> But indeed, it could be done there. But I'm feeling like it is not the
> right place. I will have problem updating my code in the future when
> new version of EMF will appear I think, in any case I still consider it.
>
> Regards,
> Daniel
>
> Ps:
>
> Using a debugger is good but it should not be the only thing because
> at the end you still need to understand the engineering or
> architecture so that your code don't get broken every time and this
> takes much more time than the debugger only. To be more specific, If I
> did not have Your BOOK on EMF 2nd edition, It would have been more
> than impossible for me. So, I got the book, I debug, and now, I'm just
> asking you questions :-)
>
> Regards,
> Daniel
>
> On 3/25/09 12:40 PM, in article gqd589$dbm$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
> Daniel,
>
> This is certainly a very long running thread and the formatting of
> this posting effectively makes it impossible to consume. You have
> to stop and figure too that there is a limit on how much time
> folks have to help with the minutiae of someone's specific
> problems. Certainly helping with the details of GMF's editors
> and how transactional editing domains are create is beyond what I
> personally have the skills to address... I often find that people
> under utilize the debugger. Looking at source code statically is
> not nearly as effective as setting and hitting a breakpoint and
> seeing a stack illustrating how dynamic execution got to that
> point in the code. I know these frameworks are very complex
> (they're solving hard problems so it's inevitable) and that the
> layers of them just makes it more complex, but there's only so
> much free time to help people...
>
> I still wonder if there isn't some good trick that could be
> employed right in the DeleteCommand itself. Here's a *completely
> untested* change to DeleteCommand's execute method:
>
> @Override
> public void execute()
> {
> Collection<EObject> eObjects = new LinkedHashSet<EObject>();
> Map<Notifier, Collection<EObject>> childrenMap = new
> LinkedHashMap<Notifier, Collection<EObject>>();
> for (Object wrappedObject : collection)
> {
> Object object =
> AdapterFactoryEditingDomain.unwrap(wrappedObject);
> if (object instanceof EObject)
> {
> EObject eObject = (EObject)object;
> eObjects.add(eObject);
> Collection<EObject> all = new LinkedHashSet<EObject>();
> all.add(eObject);
> childrenMap.put(eObject, all);
> for (Iterator<EObject> j = eObject.eAllContents();
> j.hasNext(); )
> {
> EObject child = j.next();
> eObjects.add(child);
> all.add(child);
> }
> }
> else if (object instanceof Resource)
> {
> Resource resource = (Resource)object;
> Collection<EObject> all = new LinkedHashSet<EObject>();
> childrenMap.put(resource, all);
> for (Iterator<EObject> j = resource.getAllContents();
> j.hasNext(); )
> {
> EObject child = j.next();
> eObjects.add(child);
> all.add(child);
> }
> }
> }
>
> Map<EObject, Collection<EStructuralFeature.Setting>>
> usages = EcoreUtil.UsageCrossReferencer.findAll(eObjects,
> domain.getResourceSet());
>
> super.execute();
>
> for (Map.Entry<Notifier, Collection<EObject>> entry :
> childrenMap.entrySet())
> {
> Notifier root = entry.getKey();
> if (root instanceof EObject)
> {
> EObject eObject = (EObject)root;
> if (eObject.eContainer() != null ||
> eObject.eResource() != null)
> {
> usages.keySet().removeAll(entry.getValue());
> }
> }
> else if (root instanceof Resource)
> {
> Resource resource = (Resource)root;
> if (resource.getResourceSet() != null)
> {
> usages.keySet().removeAll(entry.getValue());
> }
> }
> }
>
> for (Map.Entry<EObject,
> Collection<EStructuralFeature.Setting>> entry : usages.entrySet())
> {
> EObject eObject = entry.getKey();
> Collection<EStructuralFeature.Setting> settings =
> entry.getValue();
> for (EStructuralFeature.Setting setting : settings)
> {
> EObject referencingEObject = setting.getEObject();
> if (!eObjects.contains(referencingEObject))
> {
> EStructuralFeature eStructuralFeature =
> setting.getEStructuralFeature();
> if (eStructuralFeature.isChangeable())
> {
> if (eStructuralFeature.isMany())
> {
> appendAndExecute(RemoveCommand.create(domain,
> referencingEObject, eStructuralFeature, eObject));
> }
> else
> {
> appendAndExecute(SetCommand.create(domain,
> referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));
> }
> }
> }
> }
> }
> }
>
> The idea being that we keep track of which roots each set of
> children descends from and after executing the call to super, we
> check to see which roots are still actually attached via
> containment to a parent. So if the delete merely removed a
> wrapper from its parent, we'd detect that and not clean up all
> references to it. You might want to give that a try...
>
>
> Daniel OKOUYA wrote:
>
> Re: Problem with Deletion : Managing Localy Shared global
> Object as Non-contained-Child Hey Christian,
>
> Thx for the comment in any case. But still, as I need to
> search in many direction, could you please at least have a
> look at my 2 class and let me know if what I'm doing from an
> OO point of view is correct. The subclassing of the couple
> Interfacte/class with their respective nested class. Please,
> that would help in narrowing the research to resolve this
> issue. Eliminating the facto this aspect. If you can't
> download the file here are the sources code (I'm not yet
> comfortable in formatting with my current news reader so sorry
> about that).
>
> public class OperaTransactionalEditingDomainImpl extends
> TransactionalEditingDomainImpl implements
> OperaTransactionalEditingDomain,
> InternalTransactionalEditingDomain, Adaptable,
> OperaTransactionalEditingDomain.DefaultOptions {
> public OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory) { super(adapterFactory); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory, TransactionalCommandStack stack) {
> super(adapterFactory, stack); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory, ResourceSet resourceSet) {
> super(adapterFactory, resourceSet); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory, TransactionalCommandStack stack,
> ResourceSet resourceSet) { super(adapterFactory, stack,
> resourceSet); } /** * Default implementation of
> a transaction editing domain factory. This * class
> creates {@link TransactionalEditingDomainImpl}s and provides
> the mapping of * resource sets to editing domain
> instances. * <p> * Clients that implement their own
> factory can plug in to the mapping * of resource sets to
> editing domains using the static instance's * {@link
> #mapResourceSet(TransactionalEditingDomain)} and * {@link
> #unmapResourceSet(TransactionalEditingDomain)} methods by
> casting the * {@link
> TransactionalEditingDomain.Factory#INSTANCE} to the *
> <code>TransactionalEditingDomainImpl.FactoryImpl</code> type.
> * </p> * * @author Christian W. Damus (cdamus)
> */ public static class FactoryImpl implements
> OperaTransactionalEditingDomain.Factory { //
> Documentation copied from the inherited specification
> public synchronized TransactionalEditingDomain
> createEditingDomain() { TransactionalEditingDomain
> result = new OperaTransactionalEditingDomainImpl(
> new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE));
> mapResourceSet(result);
> return result; } //
> Documentation copied from the inherited specification
> public synchronized TransactionalEditingDomain
> createEditingDomain(ResourceSet rset) {
> TransactionalEditingDomain result = new
> OperaTransactionalEditingDomainImpl( new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE),
> rset); mapResourceSet(result); return
> result; } // Documentation copied from the
> inherited specification public
> TransactionalEditingDomain getEditingDomain(ResourceSet rset)
> { TransactionalEditingDomain result =
> null; ResourceSetDomainLink link =
> (ResourceSetDomainLink) EcoreUtil.getAdapter(
> rset.eAdapters(),
> ResourceSetDomainLink.class); if
> (link != null) { result = link.getDomain();
> } return result; } /**
> * Adds the specified editing domain to the global
> reverse mapping * of resource sets. *
> * @param domain the editing domain to add to the
> resource set mapping */ public synchronized
> void mapResourceSet(TransactionalEditingDomain domain) {
> domain.getResourceSet().eAdapters().add(
> new ResourceSetDomainLink(domain));
> } /** * Removes the specified editing
> domain from the global reverse mapping * of resource
> sets. * * @param domain the editing domain to
> remove from the resource set mapping */ public
> synchronized void unmapResourceSet(TransactionalEditingDomain
> domain) { for (Iterator<Adapter> iter =
> domain.getResourceSet().eAdapters().iterator();
> iter.hasNext();) { Adapter next =
> iter.next(); if
> (next.isAdapterForType(ResourceSetDomainLink.class)) {
> iter.remove(); //
> continue processing because maybe there are multiple
> // links to the same domain
> } } } /**
> * An adapter that attaches a weak reference to the
> editing domain * onto the resource set that it
> manages. * * @author Christian W. Damus
> (cdamus) */ private static class
> ResourceSetDomainLink extends AdapterImpl implements
> IEditingDomainProvider { private final
> WeakReference<TransactionalEditingDomain> domain;
> ResourceSetDomainLink(TransactionalEditingDomain
> domain2) { this.domain = new
> WeakReference<TransactionalEditingDomain>(domain2);
> } @Override public boolean
> isAdapterForType(Object type) { return (type ==
> ResourceSetDomainLink.class) || (type ==
> IEditingDomainProvider.class); } final
> TransactionalEditingDomain getDomain() {
> TransactionalEditingDomain result =
> domain.get(); if (result == null) {
> // no longer need the adapter
> getTarget().eAdapters().remove(this);
> } return result; }
> public final EditingDomain getEditingDomain() {
> return getDomain(); }
> }//private } //Factory //
> @Override // public Command createCommand(Class<?
> extends Command> commandClass, // CommandParameter
> commandParameter) { // // if (commandClass ==
> DeleteCommand.class) { // // if () { //
> // } // return new
> DeleteCommand(this, commandParameter.getCollection()); //
> } // return super.createCommand(commandClass,
> commandParameter); // } }
> And finally the interface:
>
> package opera.domain; import
> org.eclipse.emf.ecore.resource.ResourceSet; import
> org.eclipse.emf.transaction.TransactionalEditingDomain; import
> org.eclipse.emf.transaction.impl.InternalTransactionalEditin gDomain;
> public interface OperaTransactionalEditingDomain extends
> InternalTransactionalEditingDomain { /** * This is
> a copy/Paste from the Parent interface with one modification
> * to support our own TransactionalDomain Implementation.
> * Interface defining the protocol for creating
> transactional editing * domains. Non-shared editing
> domains can be created by accessing the * static factory
> {@link #INSTANCE}. Shared editing domains (registered *
> on the <code>org.eclipse.emf.transaction.editingDomains</code>
> * extension point are obtained via the {@link Registry}.
> * * @author Christian W. Damus (cdamus) */
> interface Factory extends
> TransactionalEditingDomain.Factory { /** *
> Static factory instance that can create instances of the
> default * transactional editing domain implementation.
> */ Factory INSTANCE = new
> OperaTransactionalEditingDomainImpl.FactoryImpl();
> /** * Creates an editing domain with a
> default resource set implementation. * *
> @return the new editing domain */
> TransactionalEditingDomain createEditingDomain();
> /** * Creates a new transactional
> editing domain on the specified resource * set.
> Although it is possible to create multiple editing domains on
> * the same resource set, this would rarely be useful.
> * * @param rset the resource set *
> * @return a new editing domain on the supplied
> resource set */ TransactionalEditingDomain
> createEditingDomain(ResourceSet rset); /**
> * Obtains the transactional editing domain (if any)
> that is currently * managing the specified resource
> set. * * @param rset a resource set *
> * @return its editing domain, or <code>null</code> if
> it is not managed * by any
> <code>TransactionalEditingDomain</code> */
> TransactionalEditingDomain getEditingDomain(ResourceSet
> rset); }
> }
> I think normally it should do the trick. However as I told
> you the integration of GMF and EMF editor works fine when I
> don't use my Transactional editing domain. It is only when I
> replace the simple line of instanciation which means just
> adding the prefix opera to the
> TransactionalEditingdomain.Factory.Instance, then the diagram
> Editor does work. For now on it pertains to magical phenomenon
> :-). I need some demystification here lol.
>
>
>
> On 3/24/09 9:33 PM, in article
> 1237926781.7244.28.camel@cdamus-laptop, "Christian W. Damus"
> <give.a.damus@gmail.com> wrote:
>
>
>
> Hi, Daniel,
>
> Sorry, as I mentioned, I don't know anything about the
> generation of multi-page editors and how that differs from
> the simple diagram editor generation which, the last time
> I used GMF, registered its editor on the extension point.
>
> If this editor is responsible for creating the editing
> domain, and it creates a basic
> TransactionalEditingDomainImpl (which is what the code
> snippet that you quote below would do), then that isn't
> going to work nicely with GMF diagram editors because it
> won't have the special DiagramEventBroker handling. I
> suppose you could just change the generated code to create
> your custom editing domain, instead (derived from the
> DiagramEditingDomain as I mentioned, already).
>
> Other than that, I really don't understand the context of
> your problem, so I would probably be more hindrance than
> help henceforward.
>
> Cheers,
>
> Christian
>
>
> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>
>
> Sorry the Real Line is this one:
>
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>
>
> On 3/24/09 6:25 PM, in article
> 1237915526.7244.12.camel@cdamus-laptop, "Christian W.
> Damus" <give.a.damus@gmail.com> wrote:
>
>
>
>
> Hi, Daniel,
>
> Your GMF-generated editor registers its editing
> domain on the
> org.eclipse.emf.transaction.editingDomains
> extension point. This extension indicates the
> domain's unique ID and the factory class used to
> create it (usually, this is the
> GMFEditingDomainFactory).
>
> You can change your editor's extension to specify
> a factory of your own devising, that extends the
> GMFEditingDomainFactory and creates your own
> subclass of the GMF editing domain implementation.
>
> HTH,
>
> Christian
>
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA
> wrote:
>
>
>
> Hi I just try to follow your advise here, but
> I got stuck with the fact that because I'm
> integrating with GMF I use a shared Editing
> Domain.
> Would you advise the same thing, subclassing
> and rewriting the transactional editing
> domain? However if I may it is susbtantially a
> more complicate class, indeed,
> Its intiation is as follow
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>
>
> Therefore, please, it indeed a bit shamefull
> :-(, if you don't mind, could you give me an
> OO advise here, as I don't know how to
> subclass a class a class that as already
> nested class, that are static with static
> method etc..... Could help or maybe advise
> something else.
>
> Indeed, What I wanted to do following your
> advise was to check if the current element is
> instanceOf WrappedItem, and if yes calling
> remove instead of Delete.
> I have no problem overiding this method In
> the transactional editing domain, but just
> don't know how to deal with nested element,
> especial if their internal method must be change.
>
> Kind regards,
> Daniel
>
>
>
> On 3/23/09 3:01 PM, in article
> gq84o0$63b$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
>
>
>
>
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
>
>
> Re: Problem with Deletion : Managing Localy Shared global Object as
> Non-contained-Child Sorry about the multiple post.
>
> Because, I like Things that are well engineer and well thought, and
> for the evolution of my application, I need to be sure my architecture
> and etc....
> So if you don't mind, I would like to do something, that is not
> going to be broken soon. Because, indeed, several month ago I
> contacted you about this problem and I'm pretty sure that my code was
> working. I don't know when was the update done, but it did change the
> behavior of my application.
>
>
>
>
>
> I think it was ages ago.
>
>
>
>
> But in any case, I think the all point is to have a good
> interpretation of what should be
> DeleteCommand Behavior.
>
>
>
>
>
> Of course different people might have
> different perceptions depending on how
> they've used things.
>
>
>
>
>
> So please, for clarity:
>
> 1-/ What will or should be the actual behavior of the DELETECOMMAND.
> Semanticaly what you desicribe here:
>
> >>>>
> There have certainly been quite set set of changes related to delete
> command and what should all be deleted, with children being overlooked
> at one point. I'm not entirely convinced looking at the code now that
> we should ever be unwrapping objects. Perhaps we should have only
> been checking instanceof EObject and only in that case do the delete
> all references part... That probably addresses your issue right?
> I.e., if we skipped the unwrapping step. Hnmmm.... But I think for
> feature map entries we have wrappers, and they need to behave the way
> we have currently. Maybe some improved factoring to make it easy to
> skip the unwrapping would help...
> >>>>
>
> Means a behavior such as The object is not identified as being the
> object but as the reference of a Parent. Is it the desired behavior
> that you would like to have?
>
>
>
>
>
> Other users might have a tree structure
> they induce with wrappers while still
> wanting a delete to do the normal thing.
> When we realized delete didn't properly
> delete references to children, we added
> support for walking the children. In any
> case, the CVS history of the file is
> public information you can inspect.
>
>
>
>
>
>
>
> 2-/ In the same line as what you said above concerning the
> refactoring you said in a preceding post I would like to ask :
>
> >>>>>
>
> 2-/ Then based on that, can anyone give me an advise about
> how to make sure that the delete only delete a wrapper and not the
> object everywhere else?
>
> You could specialize the editing domain's create
> command so that DeleteCommand is created only for non-wrappers and
> otherwise a remove command.
>
>
>
>
>
>
> 3-/ Also, how can I check that the actual item being selected is a
> wrapper, how does it works?
>
> You can check if if the object implements IWrapperItemProvider.
>
>
>
>
>
> >>>>>
>
>
> How do you do the (2) what is the proper way to do that without
> breaking the code. I mean shall I change the
> AdapterFactoryEditingDomain ?
>
>
>
>
> Create a derived class and override the
> createCommand method to handle your case
> and then call super. I.e., the usual Java
> technique.
>
>
>
>
> If yes, is there any registration I should be aware of before doing that?
>
>
>
>
>
> The editing domain is created in the
> editor, so you can create your own version
> there.
>
>
>
>
>
> 3-/More the same question than Same question for the (3)? Shall I
> change after subclassing it, where is the proper way to make the test.
> (I don't know AdapterFactoryEditingDomain yet)
>
>
>
>
>
> I suppose just testing that the UI is
> behaving correctly is the way...
>
>
>
>
>
>
>
> Regards,
> Maatari
>
> On 3/23/09 1:00 PM, in article gq7tlq$fca$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
>
>
>
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
>
>
>
>
>
>
>
>
>
> Problem with Deletion : Managing Localy Shared global Object
> as Non-contained-Child Hi all,
>
> I have the following case:
>
> In my model I have On top a Social Structure which contains
> roles which in turn contains objectives. However, Because
> Objective are unique in the model, The real Container of the
> objective is the Social Structure. Objective are
> Non-Contained-Child of Roles and Contained child of the Social
> Structure. I already manage the addition of new objective
> using a compound command, which when called from the role,
> add it both to the Social structure and the Role, avoiding de
> facto the "dangling Reference".
>
> My problem arises when I try to Delete this object and this
> is where please, I would require any advises: I want that when
> I delete an objective from a Role, if this Role or
> Non-Container Parent is the only one, then delete it both from
> the Role and its containing Parent which is the Social
> Structure. Otherwise, the object is removed only from the
> current Non-Containing-Parent.
>
> Please can any one give me some advise on how to implement
> it. The problem could be qualified as the general problem of
> managing shared global object locally as Non-contained-Child.
>
> To be more specific. I already tried implementing a version
> which as lead me to use ItemWrappers for the
> Non-contained-child. Those wrappers are created automatically
> in my RoleItemProvider. Meaning that IsWrappingNeeded always
> returns true.
>
>
> However I encountered problems when I tried to implement my
> own DeleteCommand called from my RoleItemProvider.
>
> It seams like The DeleteCommand in any case remove all Item
> even if the Item is a Warpper which is my problem. Indeed as I
> sated RemoveAll to true in The ActionBarContributor for the
> DeleteAction, It is the DeleteCommand which is used and is
> the general behavior I would like to have expect for
> Objective. However In its execution it does unwrap Item to
> find allUsage with a CrossReferencer. Meaning that, It does
> not focus on the Wrapper only but on what it represent. This
> situation has invalidate all the logic I have Implemented to
> check for the condition described above to comply to my the
> deletion criteria. Indeed with a wrapper, the getParent does
> not just yield the container. Using some crossReferencer I
> have been able to make the check discribed above.
> However I ended up with frustration as it was not working.
> After some debug, and looking into the the DeleteCommand I
> realize the behavior described earlier which in my opinion is
> the reason of my bug. Of course it might be anything else,
> that is why I'm open to any idea in that sense.
> Does any one have a good idea on how to implement this
> functionality? The only one that I see for now is :
>
> Using the Remove version of the DeleteAction, Implementing
> my own RemoveCommand specific for Each object called from my
> Items Providers, and use the EcoreUtil.delete when necessary.
> While the ides sounds ok. It is customizing the remove
> instead of customizing the delete. It seams to heavy and ugly
> to me. Therefore I think there might be another way.
>
>
>
>
>
>
>
>
>
>
>
>
> There have certainly been quite set set of changes related to delete
> command and what should all be deleted, with children being overlooked
> at one point. I'm not entirely convinced looking at the code now that
> we should ever be unwrapping objects. Perhaps we should have only
> been checking instanceof EObject and only in that case do the delete
> all references part... That probably addresses your issue right?
> I.e., if we skipped the unwrapping step. Hnmmm.... But I think for
> feature map entries we have wrappers, and they need to behave the way
> we have currently. Maybe some improved factoring to make it easy to
> skip the unwrapping would help...
>
>
>
>
>
>
>
>
>
>
>
>
>
> Please, do not hesitate on the suggestion.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--------------050909030001010209020402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel,<br>
<br>
Note that the change I'm suggesting would be to the base implementation
of DeleteCommand directly in EMF. So if you imported that plugin with
source with the PDE's help and made that change directly to the base
code, you could test it... I think this would be a safe change for the
base code because it's unlikely to change behavior in a bad way for
existing clients who want the full recursive delete behavior.<br>
<br>
<br>
Daniel OKOUYA wrote:
<blockquote cite="mid:C5EFE08C.82A6%25okouya_d@yahoo.fr" type="cite">
<title>Re: Problem with Deletion : Managing Localy Shared global
Object as Non-contained-Child</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Many Thanx for your reply and your time too,
and I’ll definitively take into account your remarks. But know that I
have been testing and making some debugging already. Especially the
first time I solve this issue ages ago as you said. And today I come
back with the same issue because of some changes in the code. But in
fact, if we think carrefully about this, this is precisely because I
solve it partially with some debugging. Not understanding the all
picture. If I had understood to the real meaning of DeleteCommand, or
at least what it intend to do (wether it is still buggy or) I would
have not implemented my code the way I did. So I’m now spending time on
something I should have spend time on long time ago. <br>
So, I definitively understand your remarks, but please, don’t feel like
I’m not getting into the code, it is just that my engineering
experience tells me that, Big picture is always important !!!!<br>
<br>
However, concering your last comment, I thought that it was impossible
to change the delete command because it is already fixed in the
AdapterFactoryEditingDomain so how can I change change it ? <br>
<br>
But indeed, it could be done there. But I’m feeling like it is not the
right place. I will have problem updating my code in the future when
new version of EMF will appear I think, in any case I still consider it.<br>
<br>
Regards,<br>
Daniel<br>
<br>
Ps:<br>
<br>
Using a debugger is good but it should not be the only thing because at
the end you still need to understand the engineering or architecture so
that your code don’t get broken every time and this takes much more
time than the debugger only. To be more specific, If I did not have
Your BOOK on EMF 2nd edition, It would have been more than impossible
for me. So, I got the book, I debug, and now, I’m just asking you
questions :-)<br>
<br>
Regards,<br>
Daniel<br>
<br>
On 3/25/09 12:40 PM, in article <a moz-do-not-send="true"
href="gqd589$dbm$1@build.eclipse.org">gqd589$dbm$1@build.eclipse.org</a>,
"Ed Merks" <<a moz-do-not-send="true" href="Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>>
wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Daniel,<br>
<br>
This is certainly a very long running thread and the formatting of this
posting effectively makes it impossible to consume. You have to stop
and figure too that there is a limit on how much time folks have to
help with the minutiae of someone's specific problems. Certainly
helping with the details of GMF's editors and how transactional editing
domains are create is beyond what I personally have the skills to
address... I often find that people under utilize the debugger.
Looking at source code statically is not nearly as effective as setting
and hitting a breakpoint and seeing a stack illustrating how dynamic
execution got to that point in the code. I know these frameworks are
very complex (they're solving hard problems so it's inevitable) and
that the layers of them just makes it more complex, but there's only so
much free time to help people...<br>
<br>
I still wonder if there isn't some good trick that could be employed
right in the DeleteCommand itself. Here's a <b>completely untested</b>
change to DeleteCommand's execute method:<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> @Override<br>
public void execute()<br>
{<br>
Collection <EObject> eObjects = new
LinkedHashSet<EObject>();<br>
Map< ;Notifier, Collection<EObject>> childrenMap = new
LinkedHashMap<Notifier, Collection<EObject>>();<br>
for (Object wrappedObject : collection)<br>
{<br>
Object object =
AdapterFactoryEditingDomain.unwrap(wrappedObject);<br>
if (object instanceof EObject)<br>
{ <br>
EObject eObject = (EObject)object;<br>
eObjects.add(eObject); <br>
Collection<EObject& gt; all = new
LinkedHashSet<EObject>();<br>
all.add(eObject); <br>
childrenMap.put(eObject, all);<br>
for (Iterator<EObject> j = eObject.eAllContents();
j.hasNext(); )<br>
{ <br>
EObject child = j.next();<br>
eObjects.a dd(child); <br>
all.add(ch ild); <br>
} <br>
} <br>
else if (object instanceof Resource)<br>
{ <br>
Resource resource = (Resource)object;<br>
Collection<EObject& gt; all = new
LinkedHashSet<EObject>();<br>
childrenMap.put(resource, all);<br>
for (Iterator<EObject> j = resource.getAllContents();
j.hasNext(); )<br>
{ <br>
EObject child = j.next();<br>
eObjects.a dd(child); <br>
all.add(ch ild); <br>
} <br>
} <br>
}<br>
<br>
Map< ;EObject, Collection<EStructuralFeature.Setting>>
usages = EcoreUtil.UsageCrossReferencer.findAll(eObjects,
domain.getResourceSet());<br>
<br>
super.exec ute(); <br>
<br>
for (Map.Entry<Notifier, Collection<EObject>> entry :
childrenMap.entrySet())<br>
{<br>
Notifier root = entry.getKey();<br>
if (root instanceof EObject)<br>
{ <br>
EObject eObject = (EObject)root;<br>
if (eObject.eContainer() != null || eObject.eResource() !=
null)<br>
{ <br>
usages.keySet().removeAll(entry.getValue()); <br>
} <br>
} <br>
else if (root instanceof Resource)<br>
{ <br>
Resource resource = (Resource)root;<br>
if (resource.getResourceSet() != null)<br>
{ <br>
usages.keySet().removeAll(entry.getValue()); <br>
} <br>
} <br>
}<br>
<br>
for (Map.Entry<EObject,
Collection<EStructuralFeature.Setting>> entry :
usages.entrySet())<br>
{<br>
EObject eObject = entry.getKey();<br>
Collection<EStructuralFeature.Setting&g t; settings =
entry.getValue();<br>
for (EStructuralFeature.Setting setting : settings)<br>
{ <br>
EObject referencingEObject = setting.getEObject();<br>
if (!eObjects.contains(referencingEObject))<br>
{ <br>
EStructura lFeature eStructuralFeature =
setting.getEStructuralFeature();<br>
if (eStructuralFeature.isChangeable())<br>
{ <br>
if (eStructuralFeature.isMany())<br>
{ <br>
appendAndExecute(RemoveCommand .create(domain,
referencingEObject, eStructuralFeature, eObject));<br>
} <br>
else <br>
{ <br>
appendAndExecute(SetCommand.cr eate(domain,
referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));<br>
} <br>
} <br>
} <br>
} <br>
}<br>
}<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">The idea being that we keep track of which
roots each set of children descends from and after executing the call
to super, we check to see which roots are still actually attached via
containment to a parent. So if the delete merely removed a wrapper
from its parent, we'd detect that and not clean up all references to
it. You might want to give that a try...<br>
<br>
<br>
Daniel OKOUYA wrote: <br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> Re: Problem with Deletion : Managing Localy
Shared global Object as Non-contained-Child Hey Christian, <br>
<br>
Thx for the comment in any case. But still, as I need to search in many
direction, could you please at least have a look at my 2 class and let
me know if what I’m doing from an OO point of view is correct. The
subclassing of the couple Interfacte/class with their respective nested
class. Please, that would help in narrowing the research to resolve
this issue. Eliminating the facto this aspect. If you can’t download
the file here are the sources code (I’m not yet comfortable in
formatting with my current news reader so sorry about that).<br>
<br>
public class OperaTransactionalEditingDomainImpl extends
TransactionalEditingDomainImpl implements
OperaTransactionalEditingDomain, InternalTransactionalEditingDomain,
Adaptable, OperaTransactionalEditingDomain.DefaultOptions {
public OperaTransactionalEditingDomainImpl(AdapterFactory
adapterFactory) { super(adapterFactory); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
Transactio nalCommandStack stack) {
super(adapterFactory, stack); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
ResourceSe t resourceSet) { super(adapterFactory,
resourceSet); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
Transactio nalCommandStack stack, ResourceSet resourceSet) {
super(adapterFactory, stack, resourceSet); } /** *
Default implementati
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428622 is a reply to message #428588] |
Wed, 25 March 2009 14:24 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
Hi Christian,
Again, thanks for your last explanation.
Meanwhile, as your the expert on the subject, I would required a little bit
more of your expertise:
Indeed after making some debug (I removed the logger that was catching my
exception) I found that:
My bug was coming from the folowing lines:
public static TransactionalEditingDomain getEditingDomain(ResourceSet rset){
return
TransactionalEditingDomain.Factory.INSTANCE.getEditingDomain (rset);
}
In the TransactionUtilClass.
More specifically from
public TransactionalEditingDomain getEditingDomain(ResourceSet rset) {
TransactionalEditingDomain result = null;
ResourceSetDomainLink link = (ResourceSetDomainLink)
EcoreUtil.getAdapter(rset.eAdapters(), ResourceSetDomainLink.class);
if (link != null){
result = link.getDomain();
}
return result;
}
Link is simply null and therefore source of the bug issue :-)
Please could you let me know, What does it means to you? What should have
been done (where)? Why the adapters my editing domain isn't in the list of
Adapters? Please, just let me know what you have in mind without hearting
yourself at thinking of it lol :-)
Kind regards,
Daniel
On 3/24/09 9:33 PM, in article 1237926781.7244.28.camel@cdamus-laptop,
"Christian W. Damus" <give.a.damus@gmail.com> wrote:
> Hi, Daniel,
>
> Sorry, as I mentioned, I don't know anything about the generation of
> multi-page editors and how that differs from the simple diagram editor
> generation which, the last time I used GMF, registered its editor on the
> extension point.
>
> If this editor is responsible for creating the editing domain, and it creates
> a basic TransactionalEditingDomainImpl (which is what the code snippet that
> you quote below would do), then that isn't going to work nicely with GMF
> diagram editors because it won't have the special DiagramEventBroker handling.
> I suppose you could just change the generated code to create your custom
> editing domain, instead (derived from the DiagramEditingDomain as I mentioned,
> already).
>
> Other than that, I really don't understand the context of your problem, so I
> would probably be more hindrance than help henceforward.
>
> Cheers,
>
> Christian
>
>
> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>> Sorry the Real Line is this one:
>>
>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>
>>
>> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>
>>
>>> Hi, Daniel,
>>>
>>> Your GMF-generated editor registers its editing domain on the
>>> org.eclipse.emf.transaction.editingDomains extension point. This extension
>>> indicates the domain's unique ID and the factory class used to create it
>>> (usually, this is the GMFEditingDomainFactory).
>>>
>>> You can change your editor's extension to specify a factory of your own
>>> devising, that extends the GMFEditingDomainFactory and creates your own
>>> subclass of the GMF editing domain implementation.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>>>
>>>> Hi I just try to follow your advise here, but I got stuck with the fact
>>>> that because I¹m integrating with GMF I use a shared Editing Domain.
>>>> Would you advise the same thing, subclassing and rewriting the
>>>> transactional editing domain? However if I may it is susbtantially a more
>>>> complicate class, indeed,
>>>> Its intiation is as follow TransactionalEditingDomain domain =
>>>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>>>
>>>> Therefore, please, it indeed a bit shamefull :-(, if you don¹t mind,
>>>> could you give me an OO advise here, as I don¹t know how to subclass a
>>>> class a class that as already nested class, that are static with static
>>>> method etc..... Could help or maybe advise something else.
>>>>
>>>> Indeed, What I wanted to do following your advise was to check if the
>>>> current element is instanceOf WrappedItem, and if yes calling remove
>>>> instead of Delete.
>>>> I have no problem overiding this method In the transactional editing
>>>> domain, but just don¹t know how to deal with nested element, especial if
>>>> their internal method must be change.
>>>>
>>>> Kind regards,
>>>> Daniel
>>>>
>>>>
>>>>
>>>> On 3/23/09 3:01 PM, in article gq84o0$63b$1@build.eclipse.org, "Ed Merks"
>>>> <Ed.Merks@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> Daniel,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Daniel OKOUYA wrote:
>>>>>
>>>>>
>>>>>> Re: Problem with Deletion : Managing Localy Shared global Object as
>>>>>> Non-contained-Child Sorry about the multiple post.
>>>>>>
>>>>>> Because, I like Things that are well engineer and well thought, and for
>>>>>> the evolution of my application, I need to be sure my architecture and
>>>>>> etc....
>>>>>> So if you don¹t mind, I would like to do something, that is not going
>>>>>> to be broken soon. Because, indeed, several month ago I contacted you
>>>>>> about this problem and I¹m pretty sure that my code was working. I don¹t
>>>>>> know when was the update done, but it did change the behavior of my
>>>>>> application.
>>>>>>
>>>>>>
>>>>>>
>>>>> I think it was ages ago.
>>>>>
>>>>>
>>>>>> But in any case, I think the all point is to have a good interpretation
>>>>>> of what should be
>>>>>> DeleteCommand Behavior.
>>>>>>
>>>>>>
>>>>>>
>>>>> Of course different people might have different perceptions depending on
>>>>> how they've used things.
>>>>>
>>>>>
>>>>>>
>>>>>> So please, for clarity:
>>>>>>
>>>>>> 1-/ What will or should be the actual behavior of the DELETECOMMAND.
>>>>>> Semanticaly what you desicribe here:
>>>>>>
>>>>>>>>>>
>>>>>> There have certainly been quite set set of changes related to delete
>>>>>> command and what should all be deleted, with children being overlooked at
>>>>>> one point. I'm not entirely convinced looking at the code now that we
>>>>>> should ever be unwrapping objects. Perhaps we should have only been
>>>>>> checking instanceof EObject and only in that case do the delete all
>>>>>> references part... That probably addresses your issue right? I.e., if we
>>>>>> skipped the unwrapping step. Hnmmm.... But I think for feature map
>>>>>> entries we have wrappers, and they need to behave the way we have
>>>>>> currently. Maybe some improved factoring to make it easy to skip the
>>>>>> unwrapping would help...
>>>>>>>>>>
>>>>>>
>>>>>> Means a behavior such as The object is not identified as being the
>>>>>> object but as the reference of a Parent. Is it the desired behavior that
>>>>>> you would like to have?
>>>>>>
>>>>>>
>>>>>>
>>>>> Other users might have a tree structure they induce with wrappers while
>>>>> still wanting a delete to do the normal thing. When we realized delete
>>>>> didn't properly delete references to children, we added support for
>>>>> walking the children. In any case, the CVS history of the file is public
>>>>> information you can inspect.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2-/ In the same line as what you said above concerning the refactoring
>>>>>> you said in a preceding post I would like to ask :
>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>> 2-/ Then based on that, can anyone give me an advise about how
>>>>>> to make sure that the delete only delete a wrapper and not the object
>>>>>> everywhere else?
>>>>>>
>>>>>> You could specialize the editing domain's create command
>>>>>> so that DeleteCommand is created only for non-wrappers and otherwise a
>>>>>> remove command.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 3-/ Also, how can I check that the actual item being selected is a
>>>>>>> wrapper, how does it works?
>>>>>>>
>>>>>>> You can check if if the object implements IWrapperItemProvider.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> How do you do the (2) what is the proper way to do that without
>>>>>> breaking the code. I mean shall I change the AdapterFactoryEditingDomain
>>>>>> ?
>>>>>>
>>>>>>
>>>>> Create a derived class and override the createCommand method to handle
>>>>> your case and then call super. I.e., the usual Java technique.
>>>>>
>>>>>
>>>>>> If yes, is there any registration I should be aware of before doing
>>>>>> that?
>>>>>>
>>>>>>
>>>>>>
>>>>> The editing domain is created in the editor, so you can create your own
>>>>> version there.
>>>>>
>>>>>
>>>>>>
>>>>>> 3-/More the same question than Same question for the (3)? Shall I
>>>>>> change after subclassing it, where is the proper way to make the test. (I
>>>>>> don¹t know AdapterFactoryEditingDomain yet)
>>>>>>
>>>>>>
>>>>>>
>>>>> I suppose just testing that the UI is behaving correctly is the way...
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Maatari
>>>>>>
>>>>>> On 3/23/09 1:00 PM, in article gq7tlq$fca$1@build.eclipse.org, "Ed
>>>>>> Merks" <Ed.Merks@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Daniel,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Daniel OKOUYA wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Problem with Deletion : Managing Localy Shared global Object as
>>>>>>>> Non-contained-Child Hi all,
>>>>>>>>
>>>>>>>> I have the following case:
>>>>>>>>
>>>>>>>> In my model I have On top a Social Structure which contains roles
>>>>>>>> which in turn contains objectives. However, Because Objective are
>>>>>>>> unique in the model, The real Container of the objective is the Social
>>>>>>>> Structure. Objective are Non-Contained-Child of Roles and Contained
>>>>>>>> child of the Social Structure. I already manage the addition of new
>>>>>>>> objective using a compound command, which when called from the role,
>>>>>>>> add it both to the Social structure and the Role, avoiding de facto the
>>>>>>>> ³dangling Reference².
>>>>>>>>
>>>>>>>> My problem arises when I try to Delete this object and this is where
>>>>>>>> please, I would require any advises: I want that when I delete an
>>>>>>>> objective from a Role, if this Role or Non-Container Parent is the only
>>>>>>>> one, then delete it both from the Role and its containing Parent which
>>>>>>>> is the Social Structure. Otherwise, the object is removed only from the
>>>>>>>> current Non-Containing-Parent.
>>>>>>>>
>>>>>>>> Please can any one give me some advise on how to implement it. The
>>>>>>>> problem could be qualified as the general problem of managing shared
>>>>>>>> global object locally as Non-contained-Child.
>>>>>>>>
>>>>>>>> To be more specific. I already tried implementing a version which as
>>>>>>>> lead me to use ItemWrappers for the Non-contained-child. Those
>>>>>>>> wrappers are created automatically in my RoleItemProvider. Meaning that
>>>>>>>> IsWrappingNeeded always returns true.
>>>>>>>>
>>>>>>>>
>>>>>>>> However I encountered problems when I tried to implement my own
>>>>>>>> DeleteCommand called from my RoleItemProvider.
>>>>>>>>
>>>>>>>> It seams like The DeleteCommand in any case remove all Item even if
>>>>>>>> the Item is a Warpper which is my problem. Indeed as I sated RemoveAll
>>>>>>>> to true in The ActionBarContributor for the DeleteAction, It is the
>>>>>>>> DeleteCommand which is used and is the general behavior I would like to
>>>>>>>> have expect for Objective. However In its execution it does unwrap
>>>>>>>> Item to find allUsage with a CrossReferencer. Meaning that, It does not
>>>>>>>> focus on the Wrapper only but on what it represent. This situation has
>>>>>>>> invalidate all the logic I have Implemented to check for the condition
>>>>>>>> described above to comply to my the deletion criteria. Indeed with a
>>>>>>>> wrapper, the getParent does not just yield the container. Using some
>>>>>>>> crossReferencer I have been able to make the check discribed above.
>>>>>>>> However I ended up with frustration as it was not working. After some
>>>>>>>> debug, and looking into the the DeleteCommand I realize the behavior
>>>>>>>> described earlier which in my opinion is the reason of my bug. Of
>>>>>>>> course it might be anything else, that is why I¹m open to any idea in
>>>>>>>> that sense.
>>>>>>>> Does any one have a good idea on how to implement this functionality?
>>>>>>>> The only one that I see for now is :
>>>>>>>>
>>>>>>>> Using the Remove version of the DeleteAction, Implementing my own
>>>>>>>> RemoveCommand specific for Each object called from my Items Providers,
>>>>>>>> and use the EcoreUtil.delete when necessary. While the ides sounds ok.
>>>>>>>> It is customizing the remove instead of customizing the delete. It
>>>>>>>> seams to heavy and ugly to me. Therefore I think there might be another
>>>>>>>> way.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> There have certainly been quite set set of changes related to delete
>>>>>>> command and what should all be deleted, with children being overlooked
>>>>>>> at one point. I'm not entirely convinced looking at the code now that
>>>>>>> we should ever be unwrapping objects. Perhaps we should have only been
>>>>>>> checking instanceof EObject and only in that case do the delete all
>>>>>>> references part... That probably addresses your issue right? I.e., if
>>>>>>> we skipped the unwrapping step. Hnmmm.... But I think for feature map
>>>>>>> entries we have wrappers, and they need to behave the way we have
>>>>>>> currently. Maybe some improved factoring to make it easy to skip the
>>>>>>> unwrapping would help...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please, do not hesitate on the suggestion.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428630 is a reply to message #428616] |
Wed, 25 March 2009 15:10 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
Hi,
Yep I understand. Thanks, and I will try it right away. But still, I prefer
the first solution you advised me , meaning the overriding which I think is
more flexible. In the sense that, I just need to call super after my
instructions in order to retrieve the original EMF version, which can evolve
whenever I want in that case, it is just the code that invoke the delete
that change finally. More elegant, powerful and whatever.... At my humble
opinion :-)
However on the other aspect of your explanation, although I know it is not
your expertise but maybe you might be interested to know what I found.
Because Unless I encounter again another tricky (I better be aware that this
is C.Sc. and its buggy :-) as indeed it is a young field), Then it should
work.
I think after that one I will be able to implement your first solution.
While I finally found the problem it doesn¹t mean that is solvable lol
because this is an OO issue and has to do with the impl. At the end I both
case I might end doing something close to your last proposal.
Actually it is simple to be exposed: In the following method:
public TransactionalEditingDomain getEditingDomain(ResourceSet rset) {
TransactionalEditingDomain result = null;
ResourceSetDomainLink link =
(ResourceSetDomainLink)EcoreUtil.getAdapter(rset.eAdapters() ,
ResourceSetDomainLink.class);
if (link != null) {
result = link.getDomain();
}
return result;
}
ResourceSetDomainLink.class is a private class defined in
TransactionalEditingDomainImpl.
I have the same private class and in the list of adapters, indeed you find:
opera.domain.OperaTransactionalEditingDomainImpl$FactoryImpl $ResourceSetDoma
inLink@bb381d
So I just don't know if it is finally feasible. If indeed this
class/Interface couple is extensible?
But that question is more for Christian I think, anyways,
If any one has a suggestion, you're welcome.
Kind regards,
Daniel
On 3/25/09 3:13 PM, in article gqde67$l6j$1@build.eclipse.org, "Ed Merks"
<Ed.Merks@gmail.com> wrote:
> Daniel,
>
> Note that the change I'm suggesting would be to the base implementation of
> DeleteCommand directly in EMF. So if you imported that plugin with source
> with the PDE's help and made that change directly to the base code, you could
> test it... I think this would be a safe change for the base code because it's
> unlikely to change behavior in a bad way for existing clients who want the
> full recursive delete behavior.
>
>
> Daniel OKOUYA wrote:
>> Re: Problem with Deletion : Managing Localy Shared global Object as
>> Non-contained-Child Many Thanx for your reply and your time too, and I¹ll
>> definitively take into account your remarks. But know that I have been
>> testing and making some debugging already. Especially the first time I solve
>> this issue ages ago as you said. And today I come back with the same issue
>> because of some changes in the code. But in fact, if we think carrefully
>> about this, this is precisely because I solve it partially with some
>> debugging. Not understanding the all picture. If I had understood to the real
>> meaning of DeleteCommand, or at least what it intend to do (wether it is
>> still buggy or) I would have not implemented my code the way I did. So I¹m
>> now spending time on something I should have spend time on long time ago.
>> So, I definitively understand your remarks, but please, don¹t feel like I¹m
>> not getting into the code, it is just that my engineering experience tells me
>> that, Big picture is always important !!!!
>>
>> However, concering your last comment, I thought that it was impossible to
>> change the delete command because it is already fixed in the
>> AdapterFactoryEditingDomain so how can I change change it ?
>>
>> But indeed, it could be done there. But I¹m feeling like it is not the right
>> place. I will have problem updating my code in the future when new version of
>> EMF will appear I think, in any case I still consider it.
>>
>> Regards,
>> Daniel
>>
>> Ps:
>>
>> Using a debugger is good but it should not be the only thing because at the
>> end you still need to understand the engineering or architecture so that your
>> code don¹t get broken every time and this takes much more time than the
>> debugger only. To be more specific, If I did not have Your BOOK on EMF 2nd
>> edition, It would have been more than impossible for me. So, I got the book,
>> I debug, and now, I¹m just asking you questions :-)
>>
>> Regards,
>> Daniel
>>
>> On 3/25/09 12:40 PM, in article gqd589$dbm$1@build.eclipse.org, "Ed Merks"
>> <Ed.Merks@gmail.com> wrote:
>>
>>
>>> Daniel,
>>>
>>> This is certainly a very long running thread and the formatting of this
>>> posting effectively makes it impossible to consume. You have to stop and
>>> figure too that there is a limit on how much time folks have to help with
>>> the minutiae of someone's specific problems. Certainly helping with the
>>> details of GMF's editors and how transactional editing domains are create is
>>> beyond what I personally have the skills to address... I often find that
>>> people under utilize the debugger. Looking at source code statically is not
>>> nearly as effective as setting and hitting a breakpoint and seeing a stack
>>> illustrating how dynamic execution got to that point in the code. I know
>>> these frameworks are very complex (they're solving hard problems so it's
>>> inevitable) and that the layers of them just makes it more complex, but
>>> there's only so much free time to help people...
>>>
>>> I still wonder if there isn't some good trick that could be employed right
>>> in the DeleteCommand itself. Here's a completely untested change to
>>> DeleteCommand's execute method:
>>>
>>>> @Override
>>>> public void execute()
>>>> {
>>>> Collection<EObject> eObjects = new LinkedHashSet<EObject>();
>>>> Map<Notifier, Collection<EObject>> childrenMap = new
>>>> LinkedHashMap<Notifier, Collection<EObject>>();
>>>> for (Object wrappedObject : collection)
>>>> {
>>>> Object object = AdapterFactoryEditingDomain.unwrap(wrappedObject);
>>>> if (object instanceof EObject)
>>>> {
>>>> EObject eObject = (EObject)object;
>>>> eObjects.add(eObject);
>>>> Collection<EObject> all = new LinkedHashSet<EObject>();
>>>> all.add(eObject);
>>>> childrenMap.put(eObject, all);
>>>> for (Iterator<EObject> j = eObject.eAllContents(); j.hasNext(); )
>>>> {
>>>> EObject child = j.next();
>>>> eObjects.add(child);
>>>> all.add(child);
>>>> }
>>>> }
>>>> else if (object instanceof Resource)
>>>> {
>>>> Resource resource = (Resource)object;
>>>> Collection<EObject> all = new LinkedHashSet<EObject>();
>>>> childrenMap.put(resource, all);
>>>> for (Iterator<EObject> j = resource.getAllContents(); j.hasNext();
>>>> )
>>>> {
>>>> EObject child = j.next();
>>>> eObjects.add(child);
>>>> all.add(child);
>>>> }
>>>> }
>>>> }
>>>>
>>>> Map<EObject, Collection<EStructuralFeature.Setting>> usages =
>>>> EcoreUtil.UsageCrossReferencer.findAll(eObjects, domain.getResourceSet());
>>>>
>>>> super.execute();
>>>>
>>>> for (Map.Entry<Notifier, Collection<EObject>> entry :
>>>> childrenMap.entrySet())
>>>> {
>>>> Notifier root = entry.getKey();
>>>> if (root instanceof EObject)
>>>> {
>>>> EObject eObject = (EObject)root;
>>>> if (eObject.eContainer() != null || eObject.eResource() != null)
>>>> {
>>>> usages.keySet().removeAll(entry.getValue());
>>>> }
>>>> }
>>>> else if (root instanceof Resource)
>>>> {
>>>> Resource resource = (Resource)root;
>>>> if (resource.getResourceSet() != null)
>>>> {
>>>> usages.keySet().removeAll(entry.getValue());
>>>> }
>>>> }
>>>> }
>>>>
>>>> for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>> entry
>>>> : usages.entrySet())
>>>> {
>>>> EObject eObject = entry.getKey();
>>>> Collection<EStructuralFeature.Setting> settings = entry.getValue();
>>>> for (EStructuralFeature.Setting setting : settings)
>>>> {
>>>> EObject referencingEObject = setting.getEObject();
>>>> if (!eObjects.contains(referencingEObject))
>>>> {
>>>> EStructuralFeature eStructuralFeature =
>>>> setting.getEStructuralFeature();
>>>> if (eStructuralFeature.isChangeable())
>>>> {
>>>> if (eStructuralFeature.isMany())
>>>> {
>>>> appendAndExecute(RemoveCommand.create(domain,
>>>> referencingEObject, eStructuralFeature, eObject));
>>>> }
>>>> else
>>>> {
>>>> appendAndExecute(SetCommand.create(domain,
>>>> referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>> The idea being that we keep track of which roots each set of children
>>> descends from and after executing the call to super, we check to see which
>>> roots are still actually attached via containment to a parent. So if the
>>> delete merely removed a wrapper from its parent, we'd detect that and not
>>> clean up all references to it. You might want to give that a try...
>>>
>>>
>>> Daniel OKOUYA wrote:
>>>
>>>> Re: Problem with Deletion : Managing Localy Shared global Object as
>>>> Non-contained-Child Hey Christian,
>>>>
>>>> Thx for the comment in any case. But still, as I need to search in many
>>>> direction, could you please at least have a look at my 2 class and let me
>>>> know if what I¹m doing from an OO point of view is correct. The subclassing
>>>> of the couple Interfacte/class with their respective nested class. Please,
>>>> that would help in narrowing the research to resolve this issue.
>>>> Eliminating the facto this aspect. If you can¹t download the file here are
>>>> the sources code (I¹m not yet comfortable in formatting with my current
>>>> news reader so sorry about that).
>>>>
>>>> public class OperaTransactionalEditingDomainImpl extends
>>>> TransactionalEditingDomainImpl implements OperaTransactionalEditingDomain,
>>>> InternalTransactionalEditingDomain, Adaptable,
>>>> OperaTransactionalEditingDomain.DefaultOptions { public
>>>> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory) {
>>>> super(adapterFactory); } public
>>>> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
>>>> TransactionalCommandStack stack) { super(adapterFactory, stack);
>>>> } public OperaTransactionalEditingDomainImpl(AdapterFactory
>>>> adapterFactory, ResourceSet resourceSet) {
>>>> super(adapterFactory, resourceSet); } public
>>>> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
>>>> TransactionalCommandStack stack, ResourceSet resourceSet) {
>>>> super(adapterFactory, stack, resourceSet); } /** * Default
>>>> implementation of a transaction editing domain factory. This * class
>>>> creates {@link TransactionalEditingDomainImpl}s and provides the mapping of
>>>> * resource sets to editing domain instances. * <p> * Clients that
>>>> implement their own factory can plug in to the mapping * of resource
>>>> sets to editing domains using the static instance's * {@link
>>>> #mapResourceSet(TransactionalEditingDomain)} and * {@link
>>>> #unmapResourceSet(TransactionalEditingDomain)} methods by casting the *
>>>> {@link TransactionalEditingDomain.Factory#INSTANCE} to the *
>>>> <code>TransactionalEditingDomainImpl.FactoryImpl</code> type. * </p>
>>>> * * @author Christian W. Damus (cdamus) */ public static class
>>>> FactoryImpl implements OperaTransactionalEditingDomain.Factory { //
>>>> Documentation copied from the inherited specification public
>>>> synchronized TransactionalEditingDomain createEditingDomain() {
>>>> TransactionalEditingDomain result = new
>>>> OperaTransactionalEditingDomainImpl( new
>>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE)
>>>> ); mapResourceSet(result); return result;
>>>> } // Documentation copied from the inherited specification
>>>> public synchronized TransactionalEditingDomain
>>>> createEditingDomain(ResourceSet rset) {
>>>> TransactionalEditingDomain result = new
>>>> OperaTransactionalEditingDomainImpl( new
>>>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE)
>>>> , rset); mapResourceSet(result); return result;
>>>> } // Documentation copied from the inherited specification
>>>> public TransactionalEditingDomain getEditingDomain(ResourceSet rset) {
>>>> TransactionalEditingDomain result = null;
>>>> ResourceSetDomainLink link = (ResourceSetDomainLink) EcoreUtil.getAdapter(
>>>> rset.eAdapters(), ResourceSetDomainLink.class);
>>>> if (link != null) { result = link.getDomain(); }
>>>> return result; } /** * Adds the specified editing
>>>> domain to the global reverse mapping * of resource sets. *
>>>> * @param domain the editing domain to add to the resource set mapping
>>>> */ public synchronized void
>>>> mapResourceSet(TransactionalEditingDomain domain) {
>>>> domain.getResourceSet().eAdapters().add( new
>>>> ResourceSetDomainLink(domain)); } /** * Removes the
>>>> specified editing domain from the global reverse mapping * of
>>>> resource sets. * * @param domain the editing domain to
>>>> remove from the resource set mapping */ public synchronized
>>>> void unmapResourceSet(TransactionalEditingDomain domain) { for
>>>> (Iterator<Adapter> iter = domain.getResourceSet().eAdapters().iterator();
>>>> iter.hasNext();) { Adapter next = iter.next();
>>>> if (next.isAdapterForType(ResourceSetDomainLink.class)) {
>>>> iter.remove(); // continue processing because maybe
>>>> there are multiple // links to the same domain
>>>> } } } /** * An adapter that
>>>> attaches a weak reference to the editing domain * onto the resource
>>>> set that it manages. * * @author Christian W. Damus
>>>> (cdamus) */ private static class ResourceSetDomainLink
>>>> extends AdapterImpl implements IEditingDomainProvider { private
>>>> final WeakReference<TransactionalEditingDomain> domain;
>>>> ResourceSetDomainLink(TransactionalEditingDomain domain2) {
>>>> this.domain = new WeakReference<TransactionalEditingDomain>(domain2);
>>>> } @Override public boolean isAdapterForType(Object
>>>> type) { return (type == ResourceSetDomainLink.class) ||
>>>> (type == IEditingDomainProvider.class); } final
>>>> TransactionalEditingDomain getDomain() {
>>>> TransactionalEditingDomain result = domain.get(); if (result
>>>> == null) { // no longer need the adapter
>>>> getTarget().eAdapters().remove(this); }
>>>> return result; } public final EditingDomain
>>>> getEditingDomain() { return getDomain(); }
>>>> }//private } //Factory // @Override // public
>>>> Command createCommand(Class<? extends Command> commandClass, //
>>>> CommandParameter commandParameter) { // // if (commandClass
>>>> == DeleteCommand.class) { // // if () { //
>>>> // } // return new DeleteCommand(this,
>>>> commandParameter.getCollection()); // } // return
>>>> super.createCommand(commandClass, commandParameter); // } }
>>>> And finally the interface:
>>>>
>>>> package opera.domain; import org.eclipse.emf.ecore.resource.ResourceSet;
>>>> import org.eclipse.emf.transaction.TransactionalEditingDomain; import
>>>> org.eclipse.emf.transaction.impl.InternalTransactionalEditin gDomain; public
>>>> interface OperaTransactionalEditingDomain extends
>>>> InternalTransactionalEditingDomain { /** * This is a copy/Paste
>>>> from the Parent interface with one modification * to support our own
>>>> TransactionalDomain Implementation. * Interface defining the protocol
>>>> for creating transactional editing * domains. Non-shared editing
>>>> domains can be created by accessing the * static factory {@link
>>>> #INSTANCE}. Shared editing domains (registered * on the
>>>> <code>org.eclipse.emf.transaction.editingDomains</code> * extension
>>>> point are obtained via the {@link Registry}. * * @author Christian
>>>> W. Damus (cdamus) */ interface Factory extends
>>>> TransactionalEditingDomain.Factory { /** * Static factory
>>>> instance that can create instances of the default * transactional
>>>> editing domain implementation. */ Factory INSTANCE = new
>>>> OperaTransactionalEditingDomainImpl.FactoryImpl(); /**
>>>> * Creates an editing domain with a default resource set implementation.
>>>> * * @return the new editing domain */
>>>> TransactionalEditingDomain createEditingDomain(); /**
>>>> * Creates a new transactional editing domain on the specified resource
>>>> * set. Although it is possible to create multiple editing domains on
>>>> * the same resource set, this would rarely be useful. * *
>>>> @param rset the resource set * * @return a new editing
>>>> domain on the supplied resource set */
>>>> TransactionalEditingDomain createEditingDomain(ResourceSet rset);
>>>> /** * Obtains the transactional editing domain (if any) that is
>>>> currently * managing the specified resource set. *
>>>> * @param rset a resource set * * @return its editing
>>>> domain, or <code>null</code> if it is not managed * by any
>>>> <code>TransactionalEditingDomain</code> */
>>>> TransactionalEditingDomain getEditingDomain(ResourceSet rset); }
>>>> }
>>>> I think normally it should do the trick. However as I told you the
>>>> integration of GMF and EMF editor works fine when I don¹t use my
>>>> Transactional editing domain. It is only when I replace the simple line of
>>>> instanciation which means just adding the prefix opera to the
>>>> TransactionalEditingdomain.Factory.Instance, then the diagram Editor does
>>>> work. For now on it pertains to magical phenomenon :-). I need some
>>>> demystification here lol.
>>>>
>>>>
>>>>
>>>> On 3/24/09 9:33 PM, in article 1237926781.7244.28.camel@cdamus-laptop,
>>>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> Hi, Daniel,
>>>>>
>>>>> Sorry, as I mentioned, I don't know anything about the generation of
>>>>> multi-page editors and how that differs from the simple diagram editor
>>>>> generation which, the last time I used GMF, registered its editor on the
>>>>> extension point.
>>>>>
>>>>> If this editor is responsible for creating the editing domain, and it
>>>>> creates a basic TransactionalEditingDomainImpl (which is what the code
>>>>> snippet that you quote below would do), then that isn't going to work
>>>>> nicely with GMF diagram editors because it won't have the special
>>>>> DiagramEventBroker handling. I suppose you could just change the
>>>>> generated code to create your custom editing domain, instead (derived from
>>>>> the DiagramEditingDomain as I mentioned, already).
>>>>>
>>>>> Other than that, I really don't understand the context of your problem, so
>>>>> I would probably be more hindrance than help henceforward.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>>>>>
>>>>>
>>>>>> Sorry the Real Line is this one:
>>>>>>
>>>>>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>>>>>
>>>>>>
>>>>>> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
>>>>>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi, Daniel,
>>>>>>>
>>>>>>> Your GMF-generated editor registers its editing domain on the
>>>>>>> org.eclipse.emf.transaction.editingDomains extension point. This
>>>>>>> extension indicates the domain's unique ID and the factory class used to
>>>>>>> create it (usually, this is the GMFEditingDomainFactory).
>>>>>>>
>>>>>>> You can change your editor's extension to specify a factory of your own
>>>>>>> devising, that extends the GMFEditingDomainFactory and creates your own
>>>>>>> subclass of the GMF editing domain implementation.
>>>>>>>
>>>>>>> HTH,
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi I just try to follow your advise here, but I got stuck with the
>>>>>>>> fact that because I¹m integrating with GMF I use a shared Editing
>>>>>>>> Domain.
>>>>>>>> Would you advise the same thing, subclassing and rewriting the
>>>>>>>> transactional editing domain? However if I may it is susbtantially a
>>>>>>>> more complicate class, indeed,
>>>>>>>> Its intiation is as follow TransactionalEditingDomain domain =
>>>>>>>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>>>>>>>
>>>>>>>> Therefore, please, it indeed a bit shamefull :-(, if you don¹t mind,
>>>>>>>> could you give me an OO advise here, as I don¹t know how to subclass a
>>>>>>>> class a class that as already nested class, that are static with static
>>>>>>>> method etc..... Could help or maybe advise something else.
>>>>>>>>
>>>>>>>> Indeed, What I wanted to do following your advise was to check if the
>>>>>>>> current element is instanceOf WrappedItem, and if yes calling remove
>>>>>>>> instead of Delete.
>>>>>>>> I have no problem overiding this method In the transactional editing
>>>>>>>> domain, but just don¹t know how to deal with nested element, especial
>>>>>>>> if their internal method must be change.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/23/09 3:01 PM, in article gq84o0$63b$1@build.eclipse.org, "Ed
>>>>>>>> Merks" <Ed.Merks@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Daniel,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Daniel OKOUYA wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> Re: Problem with Deletion : Managing Localy Shared global Object as
>> Non-contained-Child Sorry about the multiple post.
>>
>> Because, I like Things that are well engineer and well thought, and for the
>> evolution of my application, I need to be sure my architecture and etc....
>> So if you don¹t mind, I would like to do something, that is not going to be
>> broken soon. Because, indeed, several month ago I contacted you about this
>> problem and I¹m pretty sure that my code was working. I don¹t know when was
>> the update done, but it did change the behavior of my application.
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I think it was ages ago.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> But in any case, I think the all point is to have a good interpretation of
>> what should be
>> DeleteCommand Behavior.
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Of course different people might have different perceptions depending
>>>>>>>> on how they've used things.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> So please, for clarity:
>>
>> 1-/ What will or should be the actual behavior of the DELETECOMMAND.
>> Semanticaly what you desicribe here:
>>
>>>>>>
>> There have certainly been quite set set of changes related to delete
>> command and what should all be deleted, with children being overlooked at one
>> point. I'm not entirely convinced looking at the code now that we should
>> ever be unwrapping objects. Perhaps we should have only been checking
>> instanceof EObject and only in that case do the delete all references part...
>> That probably addresses your issue right? I.e., if we skipped the unwrapping
>> step. Hnmmm.... But I think for feature map entries we have wrappers, and
>> they need to behave the way we have currently. Maybe some improved factoring
>> to make it easy to skip the unwrapping would help...
>>>>>>
>>
>> Means a behavior such as The object is not identified as being the object
>> but as the reference of a Parent. Is it the desired behavior that you would
>> like to have?
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Other users might have a tree structure they induce with wrappers
>>>>>>>> while still wanting a delete to do the normal thing. When we realized
>>>>>>>> delete didn't properly delete references to children, we added support
>>>>>>>> for walking the children. In any case, the CVS history of the file is
>>>>>>>> public information you can inspect.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> 2-/ In the same line as what you said above concerning the refactoring you
>> said in a preceding post I would like to ask :
>>
>>>>>>>
>>
>> 2-/ Then based on that, can anyone give me an advise about how to
>> make sure that the delete only delete a wrapper and not the object everywhere
>> else?
>>
>> You could specialize the editing domain's create command so
>> that DeleteCommand is created only for non-wrappers and otherwise a remove
>> command.
>>
>>
>>
>>
>>
>>
>> 3-/ Also, how can I check that the actual item being selected is a wrapper,
>> how does it works?
>>
>> You can check if if the object implements IWrapperItemProvider.
>>
>>
>>
>>
>>
>>>>>>>
>>
>>
>> How do you do the (2) what is the proper way to do that without breaking
>> the code. I mean shall I change the AdapterFactoryEditingDomain ?
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Create a derived class and override the createCommand method to
>>>>>>>> handle your case and then call super. I.e., the usual Java technique.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> If yes, is there any registration I should be aware of before doing that?
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> The editing domain is created in the editor, so you can create your
>>>>>>>> own version there.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> 3-/More the same question than Same question for the (3)? Shall I change
>> after subclassing it, where is the proper way to make the test. (I don¹t know
>> AdapterFactoryEditingDomain yet)
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I suppose just testing that the UI is behaving correctly is the
>>>>>>>> way...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> Regards,
>> Maatari
>>
>> On 3/23/09 1:00 PM, in article gq7tlq$fca$1@build.eclipse.org, "Ed Merks"
>> <Ed.Merks@gmail.com> wrote:
>>
>>
>>
>>
>>
>> Daniel,
>>
>> Comments below.
>>
>> Daniel OKOUYA wrote:
>>
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> Problem with Deletion : Managing Localy Shared global Object as
>>>> Non-contained-Child Hi all,
>>>>
>>>> I have the following case:
>>>>
>>>> In my model I have On top a Social Structure which contains roles which
>>>> in turn contains objectives. However, Because Objective are unique in the
>>>> model, The real Container of the objective is the Social Structure.
>>>> Objective are Non-Contained-Child of Roles and Contained child of the
>>>> Social Structure. I already manage the addition of new objective using a
>>>> compound command, which when called from the role, add it both to the
>>>> Social structure and the Role, avoiding de facto the ³dangling Reference².
>>>>
>>>> My problem arises when I try to Delete this object and this is where
>>>> please, I would require any advises: I want that when I delete an objective
>>>> from a Role, if this Role or Non-Container Parent is the only one, then
>>>> delete it both from the Role and its containing Parent which is the Social
>>>> Structure. Otherwise, the object is removed only from the current
>>>> Non-Containing-Parent.
>>>>
>>>> Please can any one give me some advise on how to implement it. The
>>>> problem could be qualified as the general problem of managing shared global
>>>> object locally as Non-contained-Child.
>>>>
>>>> To be more specific. I already tried implementing a version which as
>>>> lead me to use ItemWrappers for the Non-contained-child. Those wrappers
>>>> are created automatically in my RoleItemProvider. Meaning that
>>>> IsWrappingNeeded always returns true.
>>>>
>>>>
>>>> However I encountered problems when I tried to implement my own
>>>> DeleteCommand called from my RoleItemProvider.
>>>>
>>>> It seams like The DeleteCommand in any case remove all Item even if the
>>>> Item is a Warpper which is my problem. Indeed as I sated RemoveAll to true
>>>> in The ActionBarContributor for the DeleteAction, It is the DeleteCommand
>>>> which is used and is the general behavior I would like to have expect for
>>>> Objective. However In its execution it does unwrap Item to find allUsage
>>>> with a CrossReferencer. Meaning that, It does not focus on the Wrapper only
>>>> but on what it represent. This situation has invalidate all the logic I
>>>> have Implemented to check for the condition described above to comply to my
>>>> the deletion criteria. Indeed with a wrapper, the getParent does not just
>>>> yield the container. Using some crossReferencer I have been able to make
>>>> the check discribed above.
>>>> However I ended up with frustration as it was not working. After some
>>>> debug, and looking into the the DeleteCommand I realize the behavior
>>>> described earlier which in my opinion is the reason of my bug. Of course it
>>>> might be anything else, that is why I¹m open to any idea in that sense.
>>>> Does any one have a good idea on how to implement this functionality?
>>>> The only one that I see for now is :
>>>>
>>>> Using the Remove version of the DeleteAction, Implementing my own
>>>> RemoveCommand specific for Each object called from my Items Providers, and
>>>> use the EcoreUtil.delete when necessary. While the ides sounds ok. It is
>>>> customizing the remove instead of customizing the delete. It seams to heavy
>>>> and ugly to me. Therefore I think there might be another way.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> There have certainly been quite set set of changes related to delete command
>> and what should all be deleted, with children being overlooked at one point.
>> I'm not entirely convinced looking at the code now that we should ever be
>> unwrapping objects. Perhaps we should have only been checking instanceof
>> EObject and only in that case do the delete all references part... That
>> probably addresses your issue right? I.e., if we skipped the unwrapping step.
>> Hnmmm.... But I think for feature map entries we have wrappers, and they
>> need to behave the way we have currently. Maybe some improved factoring to
>> make it easy to skip the unwrapping would help...
>>
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Please, do not hesitate on the suggestion.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
|
|
|
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428633 is a reply to message #428630] |
Wed, 25 March 2009 15:37 |
maatari
Messages: 74
Registered: July 2009 |
Member |
|
|
Sorry for being a bit fuzzy at the end.
However, what I meant is just that both my ancestor and I
(TransactionalEditingDomain and OperaTransactional Editing domain) have a
private class called ResourceSetDomainLink
The problem is that in my case in the code of TransactionUtil, they make an
explicit call to OperaTransactional.getEditingDomain(resss)
Therefore what is expected is
Org.emf........TransactionalImpl.ResourceSetDomainLink
And not mine.
This indeed is related to what I doubt being able to do and that was the
confirmation :-) My OO implementation wasn't good.
The solution was to have something like in the folling in my
OperaTransactional.....
public static class FactoryImpl extends
TransactionalEditingDomainImpl.FactoryImpl implements
OperaTransactionalEditingDomain.Factory {
And here only implement the two method that makes reference to the creation
of the outerClass in this case OperaTransactionalEditingDomain.
}
This way the private member class is inherited silently :-).
I will now go forward to implement the first solution proposed by Ed
And let you know all at the how I did it for those who might be interest to
solve this issue one day :-)
Kind regards,
Daniel
On 3/25/09 4:10 PM, in article C5F007DE.8644%okouya_d@yahoo.fr, "Daniel
OKOUYA" <okouya_d@yahoo.fr> wrote:
> Hi,
>
> Yep I understand. Thanks, and I will try it right away. But still, I prefer
> the first solution you advised me , meaning the overriding which I think is
> more flexible. In the sense that, I just need to call super after my
> instructions in order to retrieve the original EMF version, which can evolve
> whenever I want in that case, it is just the code that invoke the delete
> that change finally. More elegant, powerful and whatever.... At my humble
> opinion :-)
>
> However on the other aspect of your explanation, although I know it is not
> your expertise but maybe you might be interested to know what I found.
> Because Unless I encounter again another tricky (I better be aware that this
> is C.Sc. and its buggy :-) as indeed it is a young field), Then it should
> work.
> I think after that one I will be able to implement your first solution.
>
> While I finally found the problem it doesn¹t mean that is solvable lol
> because this is an OO issue and has to do with the impl. At the end I both
> case I might end doing something close to your last proposal.
>
> Actually it is simple to be exposed: In the following method:
>
> public TransactionalEditingDomain getEditingDomain(ResourceSet rset) {
>
> TransactionalEditingDomain result = null;
> ResourceSetDomainLink link =
> (ResourceSetDomainLink)EcoreUtil.getAdapter(rset.eAdapters() ,
> ResourceSetDomainLink.class);
>
>
>
> if (link != null) {
>
> result = link.getDomain();
>
> }
> return result;
>
> }
>
>
> ResourceSetDomainLink.class is a private class defined in
> TransactionalEditingDomainImpl.
>
> I have the same private class and in the list of adapters, indeed you find:
> opera.domain.OperaTransactionalEditingDomainImpl$FactoryImpl $ResourceSetDoma
> inLink@bb381d
>
>
> So I just don't know if it is finally feasible. If indeed this
> class/Interface couple is extensible?
>
> But that question is more for Christian I think, anyways,
> If any one has a suggestion, you're welcome.
>
> Kind regards,
> Daniel
>
>
>
> On 3/25/09 3:13 PM, in article gqde67$l6j$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
>
>> Daniel,
>>
>> Note that the change I'm suggesting would be to the base implementation of
>> DeleteCommand directly in EMF. So if you imported that plugin with source
>> with the PDE's help and made that change directly to the base code, you could
>> test it... I think this would be a safe change for the base code because
>> it's
>> unlikely to change behavior in a bad way for existing clients who want the
>> full recursive delete behavior.
>>
>>
>> Daniel OKOUYA wrote:
>>> Re: Problem with Deletion : Managing Localy Shared global Object as
>>> Non-contained-Child Many Thanx for your reply and your time too, and I¹ll
>>> definitively take into account your remarks. But know that I have been
>>> testing and making some debugging already. Especially the first time I solve
>>> this issue ages ago as you said. And today I come back with the same issue
>>> because of some changes in the code. But in fact, if we think carrefully
>>> about this, this is precisely because I solve it partially with some
>>> debugging. Not understanding the all picture. If I had understood to the
>>> real
>>> meaning of DeleteCommand, or at least what it intend to do (wether it is
>>> still buggy or) I would have not implemented my code the way I did. So I¹m
>>> now spending time on something I should have spend time on long time ago.
>>> So, I definitively understand your remarks, but please, don¹t feel like I¹m
>>> not getting into the code, it is just that my engineering experience tells
>>> me
>>> that, Big picture is always important !!!!
>>>
>>> However, concering your last comment, I thought that it was impossible to
>>> change the delete command because it is already fixed in the
>>> AdapterFactoryEditingDomain so how can I change change it ?
>>>
>>> But indeed, it could be done there. But I¹m feeling like it is not the right
>>> place. I will have problem updating my code in the future when new version
>>> of
>>> EMF will appear I think, in any case I still consider it.
>>>
>>> Regards,
>>> Daniel
>>>
>>> Ps:
>>>
>>> Using a debugger is good but it should not be the only thing because at the
>>> end you still need to understand the engineering or architecture so that
>>> your
>>> code don¹t get broken every time and this takes much more time than the
>>> debugger only. To be more specific, If I did not have Your BOOK on EMF 2nd
>>> edition, It would have been more than impossible for me. So, I got the book,
>>> I debug, and now, I¹m just asking you questions :-)
>>>
>>> Regards,
>>> Daniel
>>>
>>> On 3/25/09 12:40 PM, in article gqd589$dbm$1@build.eclipse.org, "Ed Merks"
>>> <Ed.Merks@gmail.com> wrote:
>>>
>>>
>>>> Daniel,
>>>>
>>>> This is certainly a very long running thread and the formatting of this
>>>> posting effectively makes it impossible to consume. You have to stop and
>>>> figure too that there is a limit on how much time folks have to help with
>>>> the minutiae of someone's specific problems. Certainly helping with the
>>>> details of GMF's editors and how transactional editing domains are create
>>>> is
>>>> beyond what I personally have the skills to address... I often find that
>>>> people under utilize the debugger. Looking at source code statically is not
>>>> nearly as effective as setting and hitting a breakpoint and seeing a stack
>>>> illustrating how dynamic execution got to that point in the code. I know
>>>> these frameworks are very complex (they're solving hard problems so it's
>>>> inevitable) and that the layers of them just makes it more complex, but
>>>> there's only so much free time to help people...
>>>>
>>>> I still wonder if there isn't some good trick that could be employed right
>>>> in the DeleteCommand itself. Here's a completely untested change to
>>>> DeleteCommand's execute method:
>>>>
>>>>> @Override
>>>>> public void execute()
>>>>> {
>>>>> Collection<EObject> eObjects = new LinkedHashSet<EObject>();
>>>>> Map<Notifier, Collection<EObject>> childrenMap = new
>>>>> LinkedHashMap<Notifier, Collection<EObject>>();
>>>>> for (Object wrappedObject : collection)
>>>>> {
>>>>> Object object = AdapterFactoryEditingDomain.unwrap(wrappedObject);
>>>>> if (object instanceof EObject)
>>>>> {
>>>>> EObject eObject = (EObject)object;
>>>>> eObjects.add(eObject);
>>>>> Collection<EObject> all = new LinkedHashSet<EObject>();
>>>>> all.add(eObject);
>>>>> childrenMap.put(eObject, all);
>>>>> for (Iterator<EObject> j = eObject.eAllContents(); j.hasNext(); )
>>>>> {
>>>>> EObject child = j.next();
>>>>> eObjects.add(child);
>>>>> all.add(child);
>>>>> }
>>>>> }
>>>>> else if (object instanceof Resource)
>>>>> {
>>>>> Resource resource = (Resource)object;
>>>>> Collection<EObject> all = new LinkedHashSet<EObject>();
>>>>> childrenMap.put(resource, all);
>>>>> for (Iterator<EObject> j = resource.getAllContents();
>>>>> j.hasNext();
>>>>> )
>>>>> {
>>>>> EObject child = j.next();
>>>>> eObjects.add(child);
>>>>> all.add(child);
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> Map<EObject, Collection<EStructuralFeature.Setting>> usages =
>>>>> EcoreUtil.UsageCrossReferencer.findAll(eObjects, domain.getResourceSet());
>>>>>
>>>>> super.execute();
>>>>>
>>>>> for (Map.Entry<Notifier, Collection<EObject>> entry :
>>>>> childrenMap.entrySet())
>>>>> {
>>>>> Notifier root = entry.getKey();
>>>>> if (root instanceof EObject)
>>>>> {
>>>>> EObject eObject = (EObject)root;
>>>>> if (eObject.eContainer() != null || eObject.eResource() != null)
>>>>> {
>>>>> usages.keySet().removeAll(entry.getValue());
>>>>> }
>>>>> }
>>>>> else if (root instanceof Resource)
>>>>> {
>>>>> Resource resource = (Resource)root;
>>>>> if (resource.getResourceSet() != null)
>>>>> {
>>>>> usages.keySet().removeAll(entry.getValue());
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> for (Map.Entry<EObject, Collection<EStructuralFeature.Setting>> entry
>>>>> : usages.entrySet())
>>>>> {
>>>>> EObject eObject = entry.getKey();
>>>>> Collection<EStructuralFeature.Setting> settings = entry.getValue();
>>>>> for (EStructuralFeature.Setting setting : settings)
>>>>> {
>>>>> EObject referencingEObject = setting.getEObject();
>>>>> if (!eObjects.contains(referencingEObject))
>>>>> {
>>>>> EStructuralFeature eStructuralFeature =
>>>>> setting.getEStructuralFeature();
>>>>> if (eStructuralFeature.isChangeable())
>>>>> {
>>>>> if (eStructuralFeature.isMany())
>>>>> {
>>>>> appendAndExecute(RemoveCommand.create(domain,
>>>>> referencingEObject, eStructuralFeature, eObject));
>>>>> }
>>>>> else
>>>>> {
>>>>> appendAndExecute(SetCommand.create(domain,
>>>>> referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));
>>>>> }
>>>>> }
>>>>> }
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>> The idea being that we keep track of which roots each set of children
>>>> descends from and after executing the call to super, we check to see which
>>>> roots are still actually attached via containment to a parent. So if the
>>>> delete merely removed a wrapper from its parent, we'd detect that and not
>>>> clean up all references to it. You might want to give that a try...
>>>>
>>>>
>>>> Daniel OKOUYA wrote:
>>>>
>>>>> Re: Problem with Deletion : Managing Localy Shared global Object as
>>>>> Non-contained-Child Hey Christian,
>>>>>
>>>>> Thx for the comment in any case. But still, as I need to search in many
>>>>> direction, could you please at least have a look at my 2 class and let me
>>>>> know if what I¹m doing from an OO point of view is correct. The
>>>>> subclassing
>>>>> of the couple Interfacte/class with their respective nested class. Please,
>>>>> that would help in narrowing the research to resolve this issue.
>>>>> Eliminating the facto this aspect. If you can¹t download the file here are
>>>>> the sources code (I¹m not yet comfortable in formatting with my current
>>>>> news reader so sorry about that).
>>>>>
>>>>> public class OperaTransactionalEditingDomainImpl extends
>>>>> TransactionalEditingDomainImpl implements OperaTransactionalEditingDomain,
>>>>> InternalTransactionalEditingDomain, Adaptable,
>>>>> OperaTransactionalEditingDomain.DefaultOptions { public
>>>>> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory) {
>>>>> super(adapterFactory); } public
>>>>> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
>>>>> TransactionalCommandStack stack) { super(adapterFactory, stack);
>>>>> } public OperaTransactionalEditingDomainImpl(AdapterFactory
>>>>> adapterFactory, ResourceSet resourceSet) {
>>>>> super(adapterFactory, resourceSet); } public
>>>>> OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
>>>>> TransactionalCommandStack stack, ResourceSet resourceSet) {
>>>>> super(adapterFactory, stack, resourceSet); } /** * Default
>>>>> implementation of a transaction editing domain factory. This * class
>>>>> creates {@link TransactionalEditingDomainImpl}s and provides the mapping
>>>>> of
>>>>> * resource sets to editing domain instances. * <p> * Clients that
>>>>> implement their own factory can plug in to the mapping * of resource
>>>>> sets to editing domains using the static instance's * {@link
>>>>> #mapResourceSet(TransactionalEditingDomain)} and * {@link
>>>>> #unmapResourceSet(TransactionalEditingDomain)} methods by casting the
>>>>> *
>>>>> {@link TransactionalEditingDomain.Factory#INSTANCE} to the *
>>>>> <code>TransactionalEditingDomainImpl.FactoryImpl</code> type. * </p>
>>>>> * * @author Christian W. Damus (cdamus) */ public static class
>>>>> FactoryImpl implements OperaTransactionalEditingDomain.Factory { //
>>>>> Documentation copied from the inherited specification public
>>>>> synchronized TransactionalEditingDomain createEditingDomain() {
>>>>> TransactionalEditingDomain result = new
>>>>> OperaTransactionalEditingDomainImpl( new
>>>>>
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE >>>>>
)
>>>>> ); mapResourceSet(result); return
>>>>> result;
>>>>> } // Documentation copied from the inherited specification
>>>>> public synchronized TransactionalEditingDomain
>>>>> createEditingDomain(ResourceSet rset) {
>>>>> TransactionalEditingDomain result = new
>>>>> OperaTransactionalEditingDomainImpl( new
>>>>>
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE >>>>>
)
>>>>> , rset); mapResourceSet(result); return result;
>>>>> } // Documentation copied from the inherited specification
>>>>> public TransactionalEditingDomain getEditingDomain(ResourceSet rset) {
>>>>> TransactionalEditingDomain result = null;
>>>>> ResourceSetDomainLink link = (ResourceSetDomainLink) EcoreUtil.getAdapter(
>>>>> rset.eAdapters(), ResourceSetDomainLink.class);
>>>>> if (link != null) { result = link.getDomain(); }
>>>>> return result; } /** * Adds the specified editing
>>>>> domain to the global reverse mapping * of resource sets. *
>>>>> * @param domain the editing domain to add to the resource set mapping
>>>>> */ public synchronized void
>>>>> mapResourceSet(TransactionalEditingDomain domain) {
>>>>> domain.getResourceSet().eAdapters().add( new
>>>>> ResourceSetDomainLink(domain)); } /** * Removes the
>>>>> specified editing domain from the global reverse mapping * of
>>>>> resource sets. * * @param domain the editing domain to
>>>>> remove from the resource set mapping */ public synchronized
>>>>> void unmapResourceSet(TransactionalEditingDomain domain) { for
>>>>> (Iterator<Adapter> iter = domain.getResourceSet().eAdapters().iterator();
>>>>> iter.hasNext();) { Adapter next = iter.next();
>>>>> if (next.isAdapterForType(ResourceSetDomainLink.class)) {
>>>>> iter.remove(); // continue processing because maybe
>>>>> there are multiple // links to the same domain
>>>>> } } } /** * An adapter that
>>>>> attaches a weak reference to the editing domain * onto the
>>>>> resource
>>>>> set that it manages. * * @author Christian W. Damus
>>>>> (cdamus) */ private static class ResourceSetDomainLink
>>>>> extends AdapterImpl implements IEditingDomainProvider { private
>>>>> final WeakReference<TransactionalEditingDomain> domain;
>>>>> ResourceSetDomainLink(TransactionalEditingDomain domain2) {
>>>>> this.domain = new WeakReference<TransactionalEditingDomain>(domain2);
>>>>> } @Override public boolean isAdapterForType(Object
>>>>> type) { return (type == ResourceSetDomainLink.class) ||
>>>>> (type == IEditingDomainProvider.class); } final
>>>>> TransactionalEditingDomain getDomain() {
>>>>> TransactionalEditingDomain result = domain.get(); if
>>>>> (result
>>>>> == null) { // no longer need the adapter
>>>>> getTarget().eAdapters().remove(this); }
>>>>> return result; } public final EditingDomain
>>>>> getEditingDomain() { return getDomain(); }
>>>>> }//private } //Factory // @Override // public
>>>>> Command createCommand(Class<? extends Command> commandClass, //
>>>>> CommandParameter commandParameter) { // // if (commandClass
>>>>> == DeleteCommand.class) { // // if () { //
>>>>> // } // return new DeleteCommand(this,
>>>>> commandParameter.getCollection()); // } // return
>>>>> super.createCommand(commandClass, commandParameter); // } }
>>>>> And finally the interface:
>>>>>
>>>>> package opera.domain; import org.eclipse.emf.ecore.resource.ResourceSet;
>>>>> import org.eclipse.emf.transaction.TransactionalEditingDomain; import
>>>>> org.eclipse.emf.transaction.impl.InternalTransactionalEditin gDomain;
>>>>> public
>>>>> interface OperaTransactionalEditingDomain extends
>>>>> InternalTransactionalEditingDomain { /** * This is a copy/Paste
>>>>> from the Parent interface with one modification * to support our own
>>>>> TransactionalDomain Implementation. * Interface defining the protocol
>>>>> for creating transactional editing * domains. Non-shared editing
>>>>> domains can be created by accessing the * static factory {@link
>>>>> #INSTANCE}. Shared editing domains (registered * on the
>>>>> <code>org.eclipse.emf.transaction.editingDomains</code> * extension
>>>>> point are obtained via the {@link Registry}. * * @author Christian
>>>>> W. Damus (cdamus) */ interface Factory extends
>>>>> TransactionalEditingDomain.Factory { /** * Static factory
>>>>> instance that can create instances of the default * transactional
>>>>> editing domain implementation. */ Factory INSTANCE = new
>>>>> OperaTransactionalEditingDomainImpl.FactoryImpl(); /**
>>>>> * Creates an editing domain with a default resource set implementation.
>>>>> * * @return the new editing domain */
>>>>> TransactionalEditingDomain createEditingDomain(); /**
>>>>> * Creates a new transactional editing domain on the specified resource
>>>>> * set. Although it is possible to create multiple editing domains on
>>>>> * the same resource set, this would rarely be useful. * *
>>>>> @param rset the resource set * * @return a new editing
>>>>> domain on the supplied resource set */
>>>>> TransactionalEditingDomain createEditingDomain(ResourceSet rset);
>>>>> /** * Obtains the transactional editing domain (if any) that is
>>>>> currently * managing the specified resource set. *
>>>>> * @param rset a resource set * * @return its editing
>>>>> domain, or <code>null</code> if it is not managed * by any
>>>>> <code>TransactionalEditingDomain</code> */
>>>>> TransactionalEditingDomain getEditingDomain(ResourceSet rset); }
>>>>> }
>>>>> I think normally it should do the trick. However as I told you the
>>>>> integration of GMF and EMF editor works fine when I don¹t use my
>>>>> Transactional editing domain. It is only when I replace the simple line of
>>>>> instanciation which means just adding the prefix opera to the
>>>>> TransactionalEditingdomain.Factory.Instance, then the diagram Editor does
>>>>> work. For now on it pertains to magical phenomenon :-). I need some
>>>>> demystification here lol.
>>>>>
>>>>>
>>>>>
>>>>> On 3/24/09 9:33 PM, in article 1237926781.7244.28.camel@cdamus-laptop,
>>>>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi, Daniel,
>>>>>>
>>>>>> Sorry, as I mentioned, I don't know anything about the generation of
>>>>>> multi-page editors and how that differs from the simple diagram editor
>>>>>> generation which, the last time I used GMF, registered its editor on the
>>>>>> extension point.
>>>>>>
>>>>>> If this editor is responsible for creating the editing domain, and it
>>>>>> creates a basic TransactionalEditingDomainImpl (which is what the code
>>>>>> snippet that you quote below would do), then that isn't going to work
>>>>>> nicely with GMF diagram editors because it won't have the special
>>>>>> DiagramEventBroker handling. I suppose you could just change the
>>>>>> generated code to create your custom editing domain, instead (derived
>>>>>> from
>>>>>> the DiagramEditingDomain as I mentioned, already).
>>>>>>
>>>>>> Other than that, I really don't understand the context of your problem,
>>>>>> so
>>>>>> I would probably be more hindrance than help henceforward.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>>>>>>
>>>>>>
>>>>>>> Sorry the Real Line is this one:
>>>>>>>
>>>>>>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>>>>>>
>>>>>>>
>>>>>>> On 3/24/09 6:25 PM, in article 1237915526.7244.12.camel@cdamus-laptop,
>>>>>>> "Christian W. Damus" <give.a.damus@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi, Daniel,
>>>>>>>>
>>>>>>>> Your GMF-generated editor registers its editing domain on the
>>>>>>>> org.eclipse.emf.transaction.editingDomains extension point. This
>>>>>>>> extension indicates the domain's unique ID and the factory class used
>>>>>>>> to
>>>>>>>> create it (usually, this is the GMFEditingDomainFactory).
>>>>>>>>
>>>>>>>> You can change your editor's extension to specify a factory of your
>>>>>>>> own
>>>>>>>> devising, that extends the GMFEditingDomainFactory and creates your own
>>>>>>>> subclass of the GMF editing domain implementation.
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi I just try to follow your advise here, but I got stuck with the
>>>>>>>>> fact that because I¹m integrating with GMF I use a shared Editing
>>>>>>>>> Domain.
>>>>>>>>> Would you advise the same thing, subclassing and rewriting the
>>>>>>>>> transactional editing domain? However if I may it is susbtantially a
>>>>>>>>> more complicate class, indeed,
>>>>>>>>> Its intiation is as follow TransactionalEditingDomain domain =
>>>>>>>>> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>>>>>>>>>
>>>>>>>>> Therefore, please, it indeed a bit shamefull :-(, if you don¹t mind,
>>>>>>>>> could you give me an OO advise here, as I don¹t know how to subclass a
>>>>>>>>> class a class that as already nested class, that are static with
>>>>>>>>> static
>>>>>>>>> method etc..... Could help or maybe advise something else.
>>>>>>>>>
>>>>>>>>> Indeed, What I wanted to do following your advise was to check if
>>>>>>>>> the
>>>>>>>>> current element is instanceOf WrappedItem, and if yes calling remove
>>>>>>>>> instead of Delete.
>>>>>>>>> I have no problem overiding this method In the transactional editing
>>>>>>>>> domain, but just don¹t know how to deal with nested element, especial
>>>>>>>>> if their internal method must be change.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/23/09 3:01 PM, in article gq84o0$63b$1@build.eclipse.org, "Ed
>>>>>>>>> Merks" <Ed.Merks@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Daniel,
>>>>>>>>>
>>>>>>>>> Comments below.
>>>>>>>>>
>>>>>>>>> Daniel OKOUYA wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> Re: Problem with Deletion : Managing Localy Shared global Object as
>>> Non-contained-Child Sorry about the multiple post.
>>>
>>> Because, I like Things that are well engineer and well thought, and for
>>> the
>>> evolution of my application, I need to be sure my architecture and etc....
>>> So if you don¹t mind, I would like to do something, that is not going to
>>> be
>>> broken soon. Because, indeed, several month ago I contacted you about this
>>> problem and I¹m pretty sure that my code was working. I don¹t know when was
>>> the update done, but it did change the behavior of my application.
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think it was ages ago.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> But in any case, I think the all point is to have a good interpretation of
>>> what should be
>>> DeleteCommand Behavior.
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Of course different people might have different perceptions
>>>>>>>>> depending
>>>>>>>>> on how they've used things.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> So please, for clarity:
>>>
>>> 1-/ What will or should be the actual behavior of the DELETECOMMAND.
>>> Semanticaly what you desicribe here:
>>>
>>>>>>>
>>> There have certainly been quite set set of changes related to delete
>>> command and what should all be deleted, with children being overlooked at
>>> one
>>> point. I'm not entirely convinced looking at the code now that we should
>>> ever be unwrapping objects. Perhaps we should have only been checking
>>> instanceof EObject and only in that case do the delete all references
>>> part...
>>> That probably addresses your issue right? I.e., if we skipped the unwrapping
>>> step. Hnmmm.... But I think for feature map entries we have wrappers, and
>>> they need to behave the way we have currently. Maybe some improved
>>> factoring
>>> to make it easy to skip the unwrapping would help...
>>>>>>>
>>>
>>> Means a behavior such as The object is not identified as being the object
>>> but as the reference of a Parent. Is it the desired behavior that you would
>>> like to have?
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Other users might have a tree structure they induce with wrappers
>>>>>>>>> while still wanting a delete to do the normal thing. When we realized
>>>>>>>>> delete didn't properly delete references to children, we added support
>>>>>>>>> for walking the children. In any case, the CVS history of the file is
>>>>>>>>> public information you can inspect.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> 2-/ In the same line as what you said above concerning the refactoring
>>> you
>>> said in a preceding post I would like to ask :
>>>
>>>>>>>>
>>>
>>> 2-/ Then based on that, can anyone give me an advise about how to
>>> make sure that the delete only delete a wrapper and not the object
>>> everywhere
>>> else?
>>>
>>> You could specialize the editing domain's create command so
>>> that DeleteCommand is created only for non-wrappers and otherwise a remove
>>> command.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 3-/ Also, how can I check that the actual item being selected is a wrapper,
>>> how does it works?
>>>
>>> You can check if if the object implements IWrapperItemProvider.
>>>
>>>
>>>
>>>
>>>
>>>>>>>>
>>>
>>>
>>> How do you do the (2) what is the proper way to do that without breaking
>>> the code. I mean shall I change the AdapterFactoryEditingDomain ?
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Create a derived class and override the createCommand method to
>>>>>>>>> handle your case and then call super. I.e., the usual Java technique.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> If yes, is there any registration I should be aware of before doing that?
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The editing domain is created in the editor, so you can create your
>>>>>>>>> own version there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> 3-/More the same question than Same question for the (3)? Shall I change
>>> after subclassing it, where is the proper way to make the test. (I don¹t
>>> know
>>> AdapterFactoryEditingDomain yet)
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I suppose just testing that the UI is behaving correctly is the
>>>>>>>>> way...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> Regards,
>>> Maatari
>>>
>>> On 3/23/09 1:00 PM, in article gq7tlq$fca$1@build.eclipse.org, "Ed Merks"
>>> <Ed.Merks@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>> Daniel,
>>>
>>> Comments below.
>>>
>>> Daniel OKOUYA wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> Problem with Deletion : Managing Localy Shared global Object as
>>>>> Non-contained-Child Hi all,
>>>>>
>>>>> I have the following case:
>>>>>
>>>>> In my model I have On top a Social Structure which contains roles which
>>>>> in turn contains objectives. However, Because Objective are unique in the
>>>>> model, The real Container of the objective is the Social Structure.
>>>>> Objective are Non-Contained-Child of Roles and Contained child of the
>>>>> Social Structure. I already manage the addition of new objective using a
>>>>> compound command, which when called from the role, add it both to the
>>>>> Social structure and the Role, avoiding de facto the ³dangling Reference².
>>>>>
>>>>> My problem arises when I try to Delete this object and this is where
>>>>> please, I would require any advises: I want that when I delete an
>>>>> objective
>>>>> from a Role, if this Role or Non-Container Parent is the only one, then
>>>>> delete it both from the Role and its containing Parent which is the Social
>>>>> Structure. Otherwise, the object is removed only from the current
>>>>> Non-Containing-Parent.
>>>>>
>>>>> Please can any one give me some advise on how to implement it. The
>>>>> problem could be qualified as the general problem of managing shared
>>>>> global
>>>>> object locally as Non-contained-Child.
>>>>>
>>>>> To be more specific. I already tried implementing a version which as
>>>>> lead me to use ItemWrappers for the Non-contained-child. Those wrappers
>>>>> are created automatically in my RoleItemProvider. Meaning that
>>>>> IsWrappingNeeded always returns true.
>>>>>
>>>>>
>>>>> However I encountered problems when I tried to implement my own
>>>>> DeleteCommand called from my RoleItemProvider.
>>>>>
>>>>> It seams like The DeleteCommand in any case remove all Item even if the
>>>>> Item is a Warpper which is my problem. Indeed as I sated RemoveAll to true
>>>>> in The ActionBarContributor for the DeleteAction, It is the DeleteCommand
>>>>> which is used and is the general behavior I would like to have expect for
>>>>> Objective. However In its execution it does unwrap Item to find allUsage
>>>>> with a CrossReferencer. Meaning that, It does not focus on the Wrapper
>>>>> only
>>>>> but on what it represent. This situation has invalidate all the logic I
>>>>> have Implemented to check for the condition described above to comply to
>>>>> my
>>>>> the deletion criteria. Indeed with a wrapper, the getParent does not just
>>>>> yield the container. Using some crossReferencer I have been able to make
>>>>> the check discribed above.
>>>>> However I ended up with frustration as it was not working. After some
>>>>> debug, and looking into the the DeleteCommand I realize the behavior
>>>>> described earlier which in my opinion is the reason of my bug. Of course
>>>>> it
>>>>> might be anything else, that is why I¹m open to any idea in that sense.
>>>>> Does any one have a good idea on how to implement this functionality?
>>>>> The only one that I see for now is :
>>>>>
>>>>> Using the Remove version of the DeleteAction, Implementing my own
>>>>> RemoveCommand specific for Each object called from my Items Providers, and
>>>>> use the EcoreUtil.delete when necessary. While the ides sounds ok. It is
>>>>> customizing the remove instead of customizing the delete. It seams to
>>>>> heavy
>>>>> and ugly to me. Therefore I think there might be another way.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> There have certainly been quite set set of changes related to delete
>>> command
>>> and what should all be deleted, with children being overlooked at one point.
>>> I'm not entirely convinced looking at the code now that we should ever be
>>> unwrapping objects. Perhaps we should have only been checking instanceof
>>> EObject and only in that case do the delete all references part... That
>>> probably addresses your issue right? I.e., if we skipped the unwrapping
>>> step.
>>> Hnmmm.... But I think for feature map entries we have wrappers, and they
>>> need to behave the way we have currently. Maybe some improved factoring to
>>> make it easy to skip the unwrapping would help...
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Please, do not hesitate on the suggestion.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
|
|
| |
| Re: Problem with Deletion : Managing Localy Shared global Object as Non-contained-Child [message #428659 is a reply to message #428647] |
Wed, 25 March 2009 23:43 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050207080603090905000208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Daniel,
So maybe we should change the base code like this...
Daniel OKOUYA wrote:
> Hi Ed.,
>
> Thank you very much. It works. I have combined both of your solution
> to maximize the flexibility.
> I didn't fully test the delete yet but without changing anything it is
> working.
> In summary, below is what I did to manage "Shared Global object
> deletion" while supporting EMF GMF integration which impose the
> TransactionalEditingDomain:
>
> 1. Sub classing the couple TransactionalEditingDomain/
> TransactionalEditingDomainImpl
> 2. Creation of my own the EnhancedDeleteCommand. It the same class
> as the DeleteCommand expect for the execute code which is based
> on the one you provided below.
> 3. Overriding the CreateCommand method to introduce the
> EnhancedCommand mentioned above while calling the super. (
> introduce an if duplication but good to keep compatibility).
>
>
> Finally it is worth mentioning for those interested that I also
> previously did my custom EnhancedRemoveCommand which is called in my
> Containing ItemProvider when removing children( with wrapping needed
> always returning true).
>
> Many thanks,
> Maatari
>
>
>
>
> On 3/25/09 12:40 PM, in article gqd589$dbm$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
> Daniel,
>
> This is certainly a very long running thread and the formatting of
> this posting effectively makes it impossible to consume. You have
> to stop and figure too that there is a limit on how much time
> folks have to help with the minutiae of someone's specific
> problems. Certainly helping with the details of GMF's editors
> and how transactional editing domains are create is beyond what I
> personally have the skills to address... I often find that people
> under utilize the debugger. Looking at source code statically is
> not nearly as effective as setting and hitting a breakpoint and
> seeing a stack illustrating how dynamic execution got to that
> point in the code. I know these frameworks are very complex
> (they're solving hard problems so it's inevitable) and that the
> layers of them just makes it more complex, but there's only so
> much free time to help people...
>
> I still wonder if there isn't some good trick that could be
> employed right in the DeleteCommand itself. Here's a *completely
> untested* change to DeleteCommand's execute method:
>
> @Override
> public void execute()
> {
> Collection<EObject> eObjects = new LinkedHashSet<EObject>();
> Map<Notifier, Collection<EObject>> childrenMap = new
> LinkedHashMap<Notifier, Collection<EObject>>();
> for (Object wrappedObject : collection)
> {
> Object object =
> AdapterFactoryEditingDomain.unwrap(wrappedObject);
> if (object instanceof EObject)
> {
> EObject eObject = (EObject)object;
> eObjects.add(eObject);
> Collection<EObject> all = new LinkedHashSet<EObject>();
> all.add(eObject);
> childrenMap.put(eObject, all);
> for (Iterator<EObject> j = eObject.eAllContents();
> j.hasNext(); )
> {
> EObject child = j.next();
> eObjects.add(child);
> all.add(child);
> }
> }
> else if (object instanceof Resource)
> {
> Resource resource = (Resource)object;
> Collection<EObject> all = new LinkedHashSet<EObject>();
> childrenMap.put(resource, all);
> for (Iterator<EObject> j = resource.getAllContents();
> j.hasNext(); )
> {
> EObject child = j.next();
> eObjects.add(child);
> all.add(child);
> }
> }
> }
>
> Map<EObject, Collection<EStructuralFeature.Setting>>
> usages = EcoreUtil.UsageCrossReferencer.findAll(eObjects,
> domain.getResourceSet());
>
> super.execute();
>
> for (Map.Entry<Notifier, Collection<EObject>> entry :
> childrenMap.entrySet())
> {
> Notifier root = entry.getKey();
> if (root instanceof EObject)
> {
> EObject eObject = (EObject)root;
> if (eObject.eContainer() != null ||
> eObject.eResource() != null)
> {
> usages.keySet().removeAll(entry.getValue());
> }
> }
> else if (root instanceof Resource)
> {
> Resource resource = (Resource)root;
> if (resource.getResourceSet() != null)
> {
> usages.keySet().removeAll(entry.getValue());
> }
> }
> }
>
> for (Map.Entry<EObject,
> Collection<EStructuralFeature.Setting>> entry : usages.entrySet())
> {
> EObject eObject = entry.getKey();
> Collection<EStructuralFeature.Setting> settings =
> entry.getValue();
> for (EStructuralFeature.Setting setting : settings)
> {
> EObject referencingEObject = setting.getEObject();
> if (!eObjects.contains(referencingEObject))
> {
> EStructuralFeature eStructuralFeature =
> setting.getEStructuralFeature();
> if (eStructuralFeature.isChangeable())
> {
> if (eStructuralFeature.isMany())
> {
> appendAndExecute(RemoveCommand.create(domain,
> referencingEObject, eStructuralFeature, eObject));
> }
> else
> {
> appendAndExecute(SetCommand.create(domain,
> referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));
> }
> }
> }
> }
> }
> }
>
> The idea being that we keep track of which roots each set of
> children descends from and after executing the call to super, we
> check to see which roots are still actually attached via
> containment to a parent. So if the delete merely removed a
> wrapper from its parent, we'd detect that and not clean up all
> references to it. You might want to give that a try...
>
>
> Daniel OKOUYA wrote:
>
> Re: Problem with Deletion : Managing Localy Shared global
> Object as Non-contained-Child Hey Christian,
>
> Thx for the comment in any case. But still, as I need to
> search in many direction, could you please at least have a
> look at my 2 class and let me know if what I'm doing from an
> OO point of view is correct. The subclassing of the couple
> Interfacte/class with their respective nested class. Please,
> that would help in narrowing the research to resolve this
> issue. Eliminating the facto this aspect. If you can't
> download the file here are the sources code (I'm not yet
> comfortable in formatting with my current news reader so sorry
> about that).
>
> public class OperaTransactionalEditingDomainImpl extends
> TransactionalEditingDomainImpl implements
> OperaTransactionalEditingDomain,
> InternalTransactionalEditingDomain, Adaptable,
> OperaTransactionalEditingDomain.DefaultOptions {
> public OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory) { super(adapterFactory); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory, TransactionalCommandStack stack) {
> super(adapterFactory, stack); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory, ResourceSet resourceSet) {
> super(adapterFactory, resourceSet); } public
> OperaTransactionalEditingDomainImpl(AdapterFactory
> adapterFactory, TransactionalCommandStack stack,
> ResourceSet resourceSet) { super(adapterFactory, stack,
> resourceSet); } /** * Default implementation of
> a transaction editing domain factory. This * class
> creates {@link TransactionalEditingDomainImpl}s and provides
> the mapping of * resource sets to editing domain
> instances. * <p> * Clients that implement their own
> factory can plug in to the mapping * of resource sets to
> editing domains using the static instance's * {@link
> #mapResourceSet(TransactionalEditingDomain)} and * {@link
> #unmapResourceSet(TransactionalEditingDomain)} methods by
> casting the * {@link
> TransactionalEditingDomain.Factory#INSTANCE} to the *
> <code>TransactionalEditingDomainImpl.FactoryImpl</code> type.
> * </p> * * @author Christian W. Damus (cdamus)
> */ public static class FactoryImpl implements
> OperaTransactionalEditingDomain.Factory { //
> Documentation copied from the inherited specification
> public synchronized TransactionalEditingDomain
> createEditingDomain() { TransactionalEditingDomain
> result = new OperaTransactionalEditingDomainImpl(
> new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE));
> mapResourceSet(result);
> return result; } //
> Documentation copied from the inherited specification
> public synchronized TransactionalEditingDomain
> createEditingDomain(ResourceSet rset) {
> TransactionalEditingDomain result = new
> OperaTransactionalEditingDomainImpl( new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE),
> rset); mapResourceSet(result); return
> result; } // Documentation copied from the
> inherited specification public
> TransactionalEditingDomain getEditingDomain(ResourceSet rset)
> { TransactionalEditingDomain result =
> null; ResourceSetDomainLink link =
> (ResourceSetDomainLink) EcoreUtil.getAdapter(
> rset.eAdapters(),
> ResourceSetDomainLink.class); if
> (link != null) { result = link.getDomain();
> } return result; } /**
> * Adds the specified editing domain to the global
> reverse mapping * of resource sets. *
> * @param domain the editing domain to add to the
> resource set mapping */ public synchronized
> void mapResourceSet(TransactionalEditingDomain domain) {
> domain.getResourceSet().eAdapters().add(
> new ResourceSetDomainLink(domain));
> } /** * Removes the specified editing
> domain from the global reverse mapping * of resource
> sets. * * @param domain the editing domain to
> remove from the resource set mapping */ public
> synchronized void unmapResourceSet(TransactionalEditingDomain
> domain) { for (Iterator<Adapter> iter =
> domain.getResourceSet().eAdapters().iterator();
> iter.hasNext();) { Adapter next =
> iter.next(); if
> (next.isAdapterForType(ResourceSetDomainLink.class)) {
> iter.remove(); //
> continue processing because maybe there are multiple
> // links to the same domain
> } } } /**
> * An adapter that attaches a weak reference to the
> editing domain * onto the resource set that it
> manages. * * @author Christian W. Damus
> (cdamus) */ private static class
> ResourceSetDomainLink extends AdapterImpl implements
> IEditingDomainProvider { private final
> WeakReference<TransactionalEditingDomain> domain;
> ResourceSetDomainLink(TransactionalEditingDomain
> domain2) { this.domain = new
> WeakReference<TransactionalEditingDomain>(domain2);
> } @Override public boolean
> isAdapterForType(Object type) { return (type ==
> ResourceSetDomainLink.class) || (type ==
> IEditingDomainProvider.class); } final
> TransactionalEditingDomain getDomain() {
> TransactionalEditingDomain result =
> domain.get(); if (result == null) {
> // no longer need the adapter
> getTarget().eAdapters().remove(this);
> } return result; }
> public final EditingDomain getEditingDomain() {
> return getDomain(); }
> }//private } //Factory //
> @Override // public Command createCommand(Class<?
> extends Command> commandClass, // CommandParameter
> commandParameter) { // // if (commandClass ==
> DeleteCommand.class) { // // if () { //
> // } // return new
> DeleteCommand(this, commandParameter.getCollection()); //
> } // return super.createCommand(commandClass,
> commandParameter); // } }
> And finally the interface:
>
> package opera.domain; import
> org.eclipse.emf.ecore.resource.ResourceSet; import
> org.eclipse.emf.transaction.TransactionalEditingDomain; import
> org.eclipse.emf.transaction.impl.InternalTransactionalEditin gDomain;
> public interface OperaTransactionalEditingDomain extends
> InternalTransactionalEditingDomain { /** * This is
> a copy/Paste from the Parent interface with one modification
> * to support our own TransactionalDomain Implementation.
> * Interface defining the protocol for creating
> transactional editing * domains. Non-shared editing
> domains can be created by accessing the * static factory
> {@link #INSTANCE}. Shared editing domains (registered *
> on the <code>org.eclipse.emf.transaction.editingDomains</code>
> * extension point are obtained via the {@link Registry}.
> * * @author Christian W. Damus (cdamus) */
> interface Factory extends
> TransactionalEditingDomain.Factory { /** *
> Static factory instance that can create instances of the
> default * transactional editing domain implementation.
> */ Factory INSTANCE = new
> OperaTransactionalEditingDomainImpl.FactoryImpl();
> /** * Creates an editing domain with a
> default resource set implementation. * *
> @return the new editing domain */
> TransactionalEditingDomain createEditingDomain();
> /** * Creates a new transactional
> editing domain on the specified resource * set.
> Although it is possible to create multiple editing domains on
> * the same resource set, this would rarely be useful.
> * * @param rset the resource set *
> * @return a new editing domain on the supplied
> resource set */ TransactionalEditingDomain
> createEditingDomain(ResourceSet rset); /**
> * Obtains the transactional editing domain (if any)
> that is currently * managing the specified resource
> set. * * @param rset a resource set *
> * @return its editing domain, or <code>null</code> if
> it is not managed * by any
> <code>TransactionalEditingDomain</code> */
> TransactionalEditingDomain getEditingDomain(ResourceSet
> rset); }
> }
> I think normally it should do the trick. However as I told
> you the integration of GMF and EMF editor works fine when I
> don't use my Transactional editing domain. It is only when I
> replace the simple line of instanciation which means just
> adding the prefix opera to the
> TransactionalEditingdomain.Factory.Instance, then the diagram
> Editor does work. For now on it pertains to magical phenomenon
> :-). I need some demystification here lol.
>
>
>
> On 3/24/09 9:33 PM, in article
> 1237926781.7244.28.camel@cdamus-laptop, "Christian W. Damus"
> <give.a.damus@gmail.com> wrote:
>
>
>
> Hi, Daniel,
>
> Sorry, as I mentioned, I don't know anything about the
> generation of multi-page editors and how that differs from
> the simple diagram editor generation which, the last time
> I used GMF, registered its editor on the extension point.
>
> If this editor is responsible for creating the editing
> domain, and it creates a basic
> TransactionalEditingDomainImpl (which is what the code
> snippet that you quote below would do), then that isn't
> going to work nicely with GMF diagram editors because it
> won't have the special DiagramEventBroker handling. I
> suppose you could just change the generated code to create
> your custom editing domain, instead (derived from the
> DiagramEditingDomain as I mentioned, already).
>
> Other than that, I really don't understand the context of
> your problem, so I would probably be more hindrance than
> help henceforward.
>
> Cheers,
>
> Christian
>
>
> On Tue, 2009-03-24 at 21:18 +0100, Daniel OKOUYA wrote:
>
>
> Sorry the Real Line is this one:
>
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>
>
> On 3/24/09 6:25 PM, in article
> 1237915526.7244.12.camel@cdamus-laptop, "Christian W.
> Damus" <give.a.damus@gmail.com> wrote:
>
>
>
>
> Hi, Daniel,
>
> Your GMF-generated editor registers its editing
> domain on the
> org.eclipse.emf.transaction.editingDomains
> extension point. This extension indicates the
> domain's unique ID and the factory class used to
> create it (usually, this is the
> GMFEditingDomainFactory).
>
> You can change your editor's extension to specify
> a factory of your own devising, that extends the
> GMFEditingDomainFactory and creates your own
> subclass of the GMF editing domain implementation.
>
> HTH,
>
> Christian
>
> On Tue, 2009-03-24 at 18:12 +0100, Daniel OKOUYA
> wrote:
>
>
>
> Hi I just try to follow your advise here, but
> I got stuck with the fact that because I'm
> integrating with GMF I use a shared Editing
> Domain.
> Would you advise the same thing, subclassing
> and rewriting the transactional editing
> domain? However if I may it is susbtantially a
> more complicate class, indeed,
> Its intiation is as follow
> TransactionalEditingDomain domain =
> TransactionalEditingDomain.Factory.INSTANCE.createEditingDom ain();
>
>
> Therefore, please, it indeed a bit shamefull
> :-(, if you don't mind, could you give me an
> OO advise here, as I don't know how to
> subclass a class a class that as already
> nested class, that are static with static
> method etc..... Could help or maybe advise
> something else.
>
> Indeed, What I wanted to do following your
> advise was to check if the current element is
> instanceOf WrappedItem, and if yes calling
> remove instead of Delete.
> I have no problem overiding this method In
> the transactional editing domain, but just
> don't know how to deal with nested element,
> especial if their internal method must be change.
>
> Kind regards,
> Daniel
>
>
>
> On 3/23/09 3:01 PM, in article
> gq84o0$63b$1@build.eclipse.org, "Ed Merks"
> <Ed.Merks@gmail.com> wrote:
>
>
>
>
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
>
>
> Re: Problem with Deletion : Managing Localy Shared global Object as
> Non-contained-Child Sorry about the multiple post.
>
> Because, I like Things that are well engineer and well thought, and
> for the evolution of my application, I need to be sure my architecture
> and etc....
> So if you don't mind, I would like to do something, that is not
> going to be broken soon. Because, indeed, several month ago I
> contacted you about this problem and I'm pretty sure that my code was
> working. I don't know when was the update done, but it did change the
> behavior of my application.
>
>
>
>
>
> I think it was ages ago.
>
>
>
>
> But in any case, I think the all point is to have a good
> interpretation of what should be
> DeleteCommand Behavior.
>
>
>
>
>
> Of course different people might have
> different perceptions depending on how
> they've used things.
>
>
>
>
>
> So please, for clarity:
>
> 1-/ What will or should be the actual behavior of the DELETECOMMAND.
> Semanticaly what you desicribe here:
>
> >>>>
> There have certainly been quite set set of changes related to delete
> command and what should all be deleted, with children being overlooked
> at one point. I'm not entirely convinced looking at the code now that
> we should ever be unwrapping objects. Perhaps we should have only
> been checking instanceof EObject and only in that case do the delete
> all references part... That probably addresses your issue right?
> I.e., if we skipped the unwrapping step. Hnmmm.... But I think for
> feature map entries we have wrappers, and they need to behave the way
> we have currently. Maybe some improved factoring to make it easy to
> skip the unwrapping would help...
> >>>>
>
> Means a behavior such as The object is not identified as being the
> object but as the reference of a Parent. Is it the desired behavior
> that you would like to have?
>
>
>
>
>
> Other users might have a tree structure
> they induce with wrappers while still
> wanting a delete to do the normal thing.
> When we realized delete didn't properly
> delete references to children, we added
> support for walking the children. In any
> case, the CVS history of the file is
> public information you can inspect.
>
>
>
>
>
>
>
> 2-/ In the same line as what you said above concerning the
> refactoring you said in a preceding post I would like to ask :
>
> >>>>>
>
> 2-/ Then based on that, can anyone give me an advise about
> how to make sure that the delete only delete a wrapper and not the
> object everywhere else?
>
> You could specialize the editing domain's create
> command so that DeleteCommand is created only for non-wrappers and
> otherwise a remove command.
>
>
>
>
>
>
> 3-/ Also, how can I check that the actual item being selected is a
> wrapper, how does it works?
>
> You can check if if the object implements IWrapperItemProvider.
>
>
>
>
>
> >>>>>
>
>
> How do you do the (2) what is the proper way to do that without
> breaking the code. I mean shall I change the
> AdapterFactoryEditingDomain ?
>
>
>
>
> Create a derived class and override the
> createCommand method to handle your case
> and then call super. I.e., the usual Java
> technique.
>
>
>
>
> If yes, is there any registration I should be aware of before doing that?
>
>
>
>
>
> The editing domain is created in the
> editor, so you can create your own version
> there.
>
>
>
>
>
> 3-/More the same question than Same question for the (3)? Shall I
> change after subclassing it, where is the proper way to make the test.
> (I don't know AdapterFactoryEditingDomain yet)
>
>
>
>
>
> I suppose just testing that the UI is
> behaving correctly is the way...
>
>
>
>
>
>
>
> Regards,
> Maatari
>
> On 3/23/09 1:00 PM, in article gq7tlq$fca$1@build.eclipse.org, "Ed
> Merks" <Ed.Merks@gmail.com> wrote:
>
>
>
>
>
> Daniel,
>
> Comments below.
>
> Daniel OKOUYA wrote:
>
>
>
>
>
>
>
>
>
>
>
> Problem with Deletion : Managing Localy Shared global Object
> as Non-contained-Child Hi all,
>
> I have the following case:
>
> In my model I have On top a Social Structure which contains
> roles which in turn contains objectives. However, Because
> Objective are unique in the model, The real Container of the
> objective is the Social Structure. Objective are
> Non-Contained-Child of Roles and Contained child of the Social
> Structure. I already manage the addition of new objective
> using a compound command, which when called from the role,
> add it both to the Social structure and the Role, avoiding de
> facto the "dangling Reference".
>
> My problem arises when I try to Delete this object and this
> is where please, I would require any advises: I want that when
> I delete an objective from a Role, if this Role or
> Non-Container Parent is the only one, then delete it both from
> the Role and its containing Parent which is the Social
> Structure. Otherwise, the object is removed only from the
> current Non-Containing-Parent.
>
> Please can any one give me some advise on how to implement
> it. The problem could be qualified as the general problem of
> managing shared global object locally as Non-contained-Child.
>
> To be more specific. I already tried implementing a version
> which as lead me to use ItemWrappers for the
> Non-contained-child. Those wrappers are created automatically
> in my RoleItemProvider. Meaning that IsWrappingNeeded always
> returns true.
>
>
> However I encountered problems when I tried to implement my
> own DeleteCommand called from my RoleItemProvider.
>
> It seams like The DeleteCommand in any case remove all Item
> even if the Item is a Warpper which is my problem. Indeed as I
> sated RemoveAll to true in The ActionBarContributor for the
> DeleteAction, It is the DeleteCommand which is used and is
> the general behavior I would like to have expect for
> Objective. However In its execution it does unwrap Item to
> find allUsage with a CrossReferencer. Meaning that, It does
> not focus on the Wrapper only but on what it represent. This
> situation has invalidate all the logic I have Implemented to
> check for the condition described above to comply to my the
> deletion criteria. Indeed with a wrapper, the getParent does
> not just yield the container. Using some crossReferencer I
> have been able to make the check discribed above.
> However I ended up with frustration as it was not working.
> After some debug, and looking into the the DeleteCommand I
> realize the behavior described earlier which in my opinion is
> the reason of my bug. Of course it might be anything else,
> that is why I'm open to any idea in that sense.
> Does any one have a good idea on how to implement this
> functionality? The only one that I see for now is :
>
> Using the Remove version of the DeleteAction, Implementing
> my own RemoveCommand specific for Each object called from my
> Items Providers, and use the EcoreUtil.delete when necessary.
> While the ides sounds ok. It is customizing the remove
> instead of customizing the delete. It seams to heavy and ugly
> to me. Therefore I think there might be another way.
>
>
>
>
>
>
>
>
>
>
>
>
> There have certainly been quite set set of changes related to delete
> command and what should all be deleted, with children being overlooked
> at one point. I'm not entirely convinced looking at the code now that
> we should ever be unwrapping objects. Perhaps we should have only
> been checking instanceof EObject and only in that case do the delete
> all references part... That probably addresses your issue right?
> I.e., if we skipped the unwrapping step. Hnmmm.... But I think for
> feature map entries we have wrappers, and they need to behave the way
> we have currently. Maybe some improved factoring to make it easy to
> skip the unwrapping would help...
>
>
>
>
>
>
>
>
>
>
>
>
>
> Please, do not hesitate on the suggestion.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--------------050207080603090905000208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel,<br>
<br>
So maybe we should change the base code like this...<br>
<br>
<br>
Daniel OKOUYA wrote:
<blockquote cite="mid:C5F04FC2.8E8F%25okouya_d@yahoo.fr" type="cite">
<title>Re: Problem with Deletion : Managing Localy Shared global
Object as Non-contained-Child</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hi Ed., <br>
<br>
Thank you very much. It works. I have combined both of your solution to
maximize the flexibility.<br>
I didn’t fully test the delete yet but without changing anything it is
working. <br>
In summary, below is what I did to manage “Shared Global object
deletion” while supporting EMF GMF integration which impose the
TransactionalEditingDomain: <br>
<br>
</span></font>
<ol>
<li><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Sub classing the couple
TransactionalEditingDomain/ TransactionalEditingDomainImpl
</span></font></li>
<li><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Creation of my own the EnhancedDeleteCommand.
It the same class as the DeleteCommand expect for the execute code
which is based on the one you provided below.
</span></font></li>
<li><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Overriding the CreateCommand method to
introduce the EnhancedCommand mentioned above while calling the super.
( introduce an if duplication but good to keep compatibility).<br>
</span></font></li>
</ol>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
Finally it is worth mentioning for those interested that I also
previously did my custom EnhancedRemoveCommand which is called in my
Containing ItemProvider when removing children( with wrapping needed
always returning true).<br>
<br>
Many thanks,<br>
Maatari<br>
<br>
<br>
<br>
<br>
On 3/25/09 12:40 PM, in article <a moz-do-not-send="true"
href="gqd589$dbm$1@build.eclipse.org">gqd589$dbm$1@build.eclipse.org</a>,
"Ed Merks" <<a moz-do-not-send="true" href="Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>>
wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Daniel,<br>
<br>
This is certainly a very long running thread and the formatting of this
posting effectively makes it impossible to consume. You have to stop
and figure too that there is a limit on how much time folks have to
help with the minutiae of someone's specific problems. Certainly
helping with the details of GMF's editors and how transactional editing
domains are create is beyond what I personally have the skills to
address... I often find that people under utilize the debugger.
Looking at source code statically is not nearly as effective as setting
and hitting a breakpoint and seeing a stack illustrating how dynamic
execution got to that point in the code. I know these frameworks are
very complex (they're solving hard problems so it's inevitable) and
that the layers of them just makes it more complex, but there's only so
much free time to help people...<br>
<br>
I still wonder if there isn't some good trick that could be employed
right in the DeleteCommand itself. Here's a <b>completely untested</b>
change to DeleteCommand's execute method:<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> @Override<br>
public void execute()<br>
{<br>
Collection <EObject> eObjects = new
LinkedHashSet<EObject>();<br>
Map< ;Notifier, Collection<EObject>> childrenMap = new
LinkedHashMap<Notifier, Collection<EObject>>();<br>
for (Object wrappedObject : collection)<br>
{<br>
Object object =
AdapterFactoryEditingDomain.unwrap(wrappedObject);<br>
if (object instanceof EObject)<br>
{ <br>
EObject eObject = (EObject)object;<br>
eObjects.add(eObject); <br>
Collection<EObject& gt; all = new
LinkedHashSet<EObject>();<br>
all.add(eObject); <br>
childrenMap.put(eObject, all);<br>
for (Iterator<EObject> j = eObject.eAllContents();
j.hasNext(); )<br>
{ <br>
EObject child = j.next();<br>
eObjects.a dd(child); <br>
all.add(ch ild); <br>
} <br>
} <br>
else if (object instanceof Resource)<br>
{ <br>
Resource resource = (Resource)object;<br>
Collection<EObject& gt; all = new
LinkedHashSet<EObject>();<br>
childrenMap.put(resource, all);<br>
for (Iterator<EObject> j = resource.getAllContents();
j.hasNext(); )<br>
{ <br>
EObject child = j.next();<br>
eObjects.a dd(child); <br>
all.add(ch ild); <br>
} <br>
} <br>
}<br>
<br>
Map< ;EObject, Collection<EStructuralFeature.Setting>>
usages = EcoreUtil.UsageCrossReferencer.findAll(eObjects,
domain.getResourceSet());<br>
<br>
super.exec ute(); <br>
<br>
for (Map.Entry<Notifier, Collection<EObject>> entry :
childrenMap.entrySet())<br>
{<br>
Notifier root = entry.getKey();<br>
if (root instanceof EObject)<br>
{ <br>
EObject eObject = (EObject)root;<br>
if (eObject.eContainer() != null || eObject.eResource() !=
null)<br>
{ <br>
usages.keySet().removeAll(entry.getValue()); <br>
} <br>
} <br>
else if (root instanceof Resource)<br>
{ <br>
Resource resource = (Resource)root;<br>
if (resource.getResourceSet() != null)<br>
{ <br>
usages.keySet().removeAll(entry.getValue()); <br>
} <br>
} <br>
}<br>
<br>
for (Map.Entry<EObject,
Collection<EStructuralFeature.Setting>> entry :
usages.entrySet())<br>
{<br>
EObject eObject = entry.getKey();<br>
Collection<EStructuralFeature.Setting&g t; settings =
entry.getValue();<br>
for (EStructuralFeature.Setting setting : settings)<br>
{ <br>
EObject referencingEObject = setting.getEObject();<br>
if (!eObjects.contains(referencingEObject))<br>
{ <br>
EStructura lFeature eStructuralFeature =
setting.getEStructuralFeature();<br>
if (eStructuralFeature.isChangeable())<br>
{ <br>
if (eStructuralFeature.isMany())<br>
{ <br>
appendAndExecute(RemoveCommand .create(domain,
referencingEObject, eStructuralFeature, eObject));<br>
} <br>
else <br>
{ <br>
appendAndExecute(SetCommand.cr eate(domain,
referencingEObject, eStructuralFeature, SetCommand.UNSET_VALUE));<br>
} <br>
} <br>
} <br>
} <br>
}<br>
}<br>
</span></font></blockquote>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">The idea being that we keep track of which
roots each set of children descends from and after executing the call
to super, we check to see which roots are still actually attached via
containment to a parent. So if the delete merely removed a wrapper
from its parent, we'd detect that and not clean up all references to
it. You might want to give that a try...<br>
<br>
<br>
Daniel OKOUYA wrote: <br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"> Re: Problem with Deletion : Managing Localy
Shared global Object as Non-contained-Child Hey Christian, <br>
<br>
Thx for the comment in any case. But still, as I need to search in many
direction, could you please at least have a look at my 2 class and let
me know if what I’m doing from an OO point of view is correct. The
subclassing of the couple Interfacte/class with their respective nested
class. Please, that would help in narrowing the research to resolve
this issue. Eliminating the facto this aspect. If you can’t download
the file here are the sources code (I’m not yet comfortable in
formatting with my current news reader so sorry about that).<br>
<br>
public class OperaTransactionalEditingDomainImpl extends
TransactionalEditingDomainImpl implements
OperaTransactionalEditingDomain, InternalTransactionalEditingDomain,
Adaptable, OperaTransactionalEditingDomain.DefaultOptions {
public OperaTransactionalEditingDomainImpl(AdapterFactory
adapterFactory) { super(adapterFactory); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
Transactio nalCommandStack stack) {
super(adapterFactory, stack); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
ResourceSe t resourceSet) { super(adapterFactory,
resourceSet); } public
OperaTransactionalEditingDomainImpl(AdapterFactory adapterFactory,
Transactio nalCommandStack stack, ResourceSet resourceSet) {
super(adapterFactory, stack, resourceSet); } /** *
Default implementation of a transaction editing domain factory. This
* class creates {@link TransactionalEditingDomainImpl}s and
provides the mapping of * resource sets to editing domain
instances. * <p> * Clients that implement their own
factory can plug in to the mapping * of resource sets to editing
domains using the static instance's * {@link
#mapResourceSet(TransactionalEditingDomain)} and * {@link
#unmapResourceSet(TransactionalEditingDomain)} methods by casting the
* {@link TransactionalEditingDomain.Factory#INSTANCE} to the *
<code>TransactionalEditingDomainImpl.FactoryIm pl</code>
type. * </p> * * @author Christian W. Damus (cdamus)
*/ public static class FactoryImpl implements
OperaTransactionalEditingDomain.Factory { // Documentation
copied from the inherited specification public synchronized
TransactionalEditingDomain createEditingDomain() {
&nbs
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:03:05 GMT 2024
Powered by FUDForum. Page generated in 0.07294 seconds |
] 
Search
Help
Register
Login
Home
