Home » Modeling » EMF » Understanding Adapters
| Understanding Adapters [message #479639] |
Tue, 11 August 2009 20:09  |
 Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Hi all,
i've some really understanding problems with EMF Adapter mechanism. As
the EMF Bible says, Adapters are Observer, and every EObject has the
capability to act as an "Observable" (Notifier).
But for what purpose should an adapter be used? IMHO, they should
register an EObject as an "Observer" in another EObject, shouldn't they?
I was wondering, that the book let the Adapters act as an single Object,
which is not inherited by any other EObject (In contrst to the
Observer-Pattern, where each subject is a special class of an Observer).
In my scenario, i want to notify a MessageEnd object, that a Message
object corelated to it, when the MessageEnd was added to the message's
receiving/sending end. Therefore, i thought i had to implement the
MessageEnd adapter and register it at each the Message during creation
process in the corresponding Efactory create() method.
As mentioned, i was wondering, that the book didn't show any scenario
like this. But may be, i missunderstand the mechanism completely...
Thanks
/Timothy
|
|
|
| Re: Understanding Adapters [message #479651 is a reply to message #479639] |
Tue, 11 August 2009 20:52  |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Timothy,
Comments below.
Timothy Marc wrote:
> Hi all,
>
> i've some really understanding problems with EMF Adapter mechanism.
Oh really?
> As the EMF Bible
Hehehe.
> says, Adapters are Observer, and every EObject has the capability to
> act as an "Observable" (Notifier).
If the Bible says it, it must be a fact, clearly!
>
> But for what purpose should an adapter be used?
For listening. For adding behavioral extensions. For something we
might not even have imagined?
> IMHO, they should register an EObject as an "Observer" in another
> EObject, shouldn't they?
How humble is that? They register an Adapter, which generally won't be
an EObject...
> I was wondering, that the book let the Adapters act as an single
> Object, which is not inherited by any other EObject (In contrst to the
> Observer-Pattern, where each subject is a special class of an Observer).
I'm not sure why you decided that Observer == EObject. Observer ==
Adapter is more accurate... You're not expecting generally that an
Observer is an Observable are you?
>
>
> In my scenario, i want to notify a MessageEnd object, that a Message
> object corelated to it, when the MessageEnd was added to the message's
> receiving/sending end. Therefore, i thought i had to implement the
> MessageEnd adapter and register it at each the Message during creation
> process in the corresponding Efactory create() method.
That hurts my brain a little bit. Generally if you have a bidirectional
reference, both objects at each end of the reference will be notified of
their association with the other...
>
> As mentioned, i was wondering, that the book didn't show any scenario
> like this. But may be, i missunderstand the mechanism completely...
Maybe, but I'm a little confused at this point. If you have a Message
and a MessageEnd, and they have a bidirectional reference between them,
when you set that reference, both the Message and the MessageEnd will be
notified via their Adapter that they've been changed...
>
>
> Thanks
> /Timothy
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Understanding Adapters [message #479705 is a reply to message #479651] |
Wed, 12 August 2009 06:32 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Ed,
well, if the reference is bidrectional, i didn't have a problem, but in
my scenario, each Message has two unidirectional references two
MessageEnd (one for sending and one for receiving) and each MessageEnd
has a derived, read-only unidirectional reference to Message. The
message reference will be set, when a MessageEnd was set as either the
receiving or sending end of the Message. It is read-only and derived to
forbid a scenario, in which a Message has some MessageEnds but the
MessageEnd::message points to completely different message...
To realize the derived reference, i thought the best way is by observing
the setReceive/SendEnd() methods, intercept the the notifier within the
observer (the MessageEnd) and set the message reference within the
notifyChanged() method. As mentioned, i thought the adapter scneraio is
quite similar to the observer pattern...
May be, this figures my question, respectively problem, out better.
Timothy
Ed Merks schrieb:
> Timothy,
>
> Comments below.
>
> Timothy Marc wrote:
>> Hi all,
>>
>> i've some really understanding problems with EMF Adapter mechanism.
> Oh really?
>> As the EMF Bible
> Hehehe.
>> says, Adapters are Observer, and every EObject has the capability to
>> act as an "Observable" (Notifier).
> If the Bible says it, it must be a fact, clearly!
>>
>> But for what purpose should an adapter be used?
> For listening. For adding behavioral extensions. For something we
> might not even have imagined?
>> IMHO, they should register an EObject as an "Observer" in another
>> EObject, shouldn't they?
> How humble is that? They register an Adapter, which generally won't be
> an EObject...
>> I was wondering, that the book let the Adapters act as an single
>> Object, which is not inherited by any other EObject (In contrst to the
>> Observer-Pattern, where each subject is a special class of an Observer).
> I'm not sure why you decided that Observer == EObject. Observer ==
> Adapter is more accurate... You're not expecting generally that an
> Observer is an Observable are you?
>>
>>
>> In my scenario, i want to notify a MessageEnd object, that a Message
>> object corelated to it, when the MessageEnd was added to the message's
>> receiving/sending end. Therefore, i thought i had to implement the
>> MessageEnd adapter and register it at each the Message during creation
>> process in the corresponding Efactory create() method.
> That hurts my brain a little bit. Generally if you have a bidirectional
> reference, both objects at each end of the reference will be notified of
> their association with the other...
>>
>> As mentioned, i was wondering, that the book didn't show any scenario
>> like this. But may be, i missunderstand the mechanism completely...
> Maybe, but I'm a little confused at this point. If you have a Message
> and a MessageEnd, and they have a bidirectional reference between them,
> when you set that reference, both the Message and the MessageEnd will be
> notified via their Adapter that they've been changed...
>>
>>
>> Thanks
>> /Timothy
|
|
|
| Re: Understanding Adapters [message #479722 is a reply to message #479705] |
Wed, 12 August 2009 07:57 |
|
Timothy,
Comments inline...
Timothy Marc schrieb:
> Ed,
>
> well, if the reference is bidrectional, i didn't have a problem, but
> in my scenario, each Message has two unidirectional references two
> MessageEnd (one for sending and one for receiving) and each MessageEnd
> has a derived, read-only unidirectional reference to Message. The
> message reference will be set, when a MessageEnd was set as either the
> receiving or sending end of the Message. It is read-only and derived
> to forbid a scenario, in which a Message has some MessageEnds but the
> MessageEnd::message points to completely different message...
If I understand your design correctly you'd just need to model the
references between Message and MessageEnd so that they're bidirectional.
Then the EMF runtime cares for consistent instances. Why are you trying
to achieve the same thing with complicated own code?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> To realize the derived reference, i thought the best way is by
> observing the setReceive/SendEnd() methods, intercept the the notifier
> within the observer (the MessageEnd) and set the message reference
> within the notifyChanged() method. As mentioned, i thought the adapter
> scneraio is quite similar to the observer pattern...
>
> May be, this figures my question, respectively problem, out better.
>
> Timothy
>
> Ed Merks schrieb:
>> Timothy,
>>
>> Comments below.
>>
>> Timothy Marc wrote:
>>> Hi all,
>>>
>>> i've some really understanding problems with EMF Adapter mechanism.
>> Oh really?
>>> As the EMF Bible
>> Hehehe.
>>> says, Adapters are Observer, and every EObject has the capability to
>>> act as an "Observable" (Notifier).
>> If the Bible says it, it must be a fact, clearly!
>>>
>>> But for what purpose should an adapter be used?
>> For listening. For adding behavioral extensions. For something we
>> might not even have imagined?
>>> IMHO, they should register an EObject as an "Observer" in another
>>> EObject, shouldn't they?
>> How humble is that? They register an Adapter, which generally won't
>> be an EObject...
>>> I was wondering, that the book let the Adapters act as an single
>>> Object, which is not inherited by any other EObject (In contrst to
>>> the Observer-Pattern, where each subject is a special class of an
>>> Observer).
>> I'm not sure why you decided that Observer == EObject. Observer ==
>> Adapter is more accurate... You're not expecting generally that an
>> Observer is an Observable are you?
>>>
>>>
>>> In my scenario, i want to notify a MessageEnd object, that a Message
>>> object corelated to it, when the MessageEnd was added to the
>>> message's receiving/sending end. Therefore, i thought i had to
>>> implement the MessageEnd adapter and register it at each the Message
>>> during creation process in the corresponding Efactory create() method.
>> That hurts my brain a little bit. Generally if you have a
>> bidirectional reference, both objects at each end of the reference
>> will be notified of their association with the other...
>>>
>>> As mentioned, i was wondering, that the book didn't show any
>>> scenario like this. But may be, i missunderstand the mechanism
>>> completely...
>> Maybe, but I'm a little confused at this point. If you have a
>> Message and a MessageEnd, and they have a bidirectional reference
>> between them, when you set that reference, both the Message and the
>> MessageEnd will be notified via their Adapter that they've been
>> changed...
>>>
>>>
>>> Thanks
>>> /Timothy
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding Adapters [message #479729 is a reply to message #479722] |
Wed, 12 August 2009 08:30 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Eike,
no, if it would be so simple, i wouldn't spent so many time for it. As i
mentioned, Message has 2 references to MessageEnd.
Message
+sendMessgeEnd:MessageEnd
+receiveMessageEnd:MessageEnd
MessageEnd
+/message 1 {read-only}
If these references had been made bidirectional, each message end would
contain two message references. But this is not, what i want.
Cheers Timothy
Eike Stepper schrieb:
> Timothy,
>
> Comments inline...
>
>
>
> Timothy Marc schrieb:
>> Ed,
>>
>> well, if the reference is bidrectional, i didn't have a problem, but
>> in my scenario, each Message has two unidirectional references two
>> MessageEnd (one for sending and one for receiving) and each MessageEnd
>> has a derived, read-only unidirectional reference to Message. The
>> message reference will be set, when a MessageEnd was set as either the
>> receiving or sending end of the Message. It is read-only and derived
>> to forbid a scenario, in which a Message has some MessageEnds but the
>> MessageEnd::message points to completely different message...
> If I understand your design correctly you'd just need to model the
> references between Message and MessageEnd so that they're bidirectional.
> Then the EMF runtime cares for consistent instances. Why are you trying
> to achieve the same thing with complicated own code?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> To realize the derived reference, i thought the best way is by
>> observing the setReceive/SendEnd() methods, intercept the the notifier
>> within the observer (the MessageEnd) and set the message reference
>> within the notifyChanged() method. As mentioned, i thought the adapter
>> scneraio is quite similar to the observer pattern...
>>
>> May be, this figures my question, respectively problem, out better.
>>
>> Timothy
>>
>> Ed Merks schrieb:
>>> Timothy,
>>>
>>> Comments below.
>>>
>>> Timothy Marc wrote:
>>>> Hi all,
>>>>
>>>> i've some really understanding problems with EMF Adapter mechanism.
>>> Oh really?
>>>> As the EMF Bible
>>> Hehehe.
>>>> says, Adapters are Observer, and every EObject has the capability to
>>>> act as an "Observable" (Notifier).
>>> If the Bible says it, it must be a fact, clearly!
>>>> But for what purpose should an adapter be used?
>>> For listening. For adding behavioral extensions. For something we
>>> might not even have imagined?
>>>> IMHO, they should register an EObject as an "Observer" in another
>>>> EObject, shouldn't they?
>>> How humble is that? They register an Adapter, which generally won't
>>> be an EObject...
>>>> I was wondering, that the book let the Adapters act as an single
>>>> Object, which is not inherited by any other EObject (In contrst to
>>>> the Observer-Pattern, where each subject is a special class of an
>>>> Observer).
>>> I'm not sure why you decided that Observer == EObject. Observer ==
>>> Adapter is more accurate... You're not expecting generally that an
>>> Observer is an Observable are you?
>>>>
>>>> In my scenario, i want to notify a MessageEnd object, that a Message
>>>> object corelated to it, when the MessageEnd was added to the
>>>> message's receiving/sending end. Therefore, i thought i had to
>>>> implement the MessageEnd adapter and register it at each the Message
>>>> during creation process in the corresponding Efactory create() method.
>>> That hurts my brain a little bit. Generally if you have a
>>> bidirectional reference, both objects at each end of the reference
>>> will be notified of their association with the other...
>>>> As mentioned, i was wondering, that the book didn't show any
>>>> scenario like this. But may be, i missunderstand the mechanism
>>>> completely...
>>> Maybe, but I'm a little confused at this point. If you have a
>>> Message and a MessageEnd, and they have a bidirectional reference
>>> between them, when you set that reference, both the Message and the
>>> MessageEnd will be notified via their Adapter that they've been
>>> changed...
>>>>
>>>> Thanks
>>>> /Timothy
|
|
|
| Re: Understanding Adapters [message #479730 is a reply to message #479729] |
Wed, 12 August 2009 08:50 |
|
This is a multi-part message in MIME format.
--------------090403090704030302050006
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Timothy Marc schrieb:
> Eike,
>
> no, if it would be so simple, i wouldn't spent so many time for it. As
> i mentioned, Message has 2 references to MessageEnd.
>
> Message
> +sendMessgeEnd:MessageEnd
> +receiveMessageEnd:MessageEnd
>
> MessageEnd
> +/message 1 {read-only}
>
> If these references had been made bidirectional, each message end
> would contain two message references.
Not necessarily. Often it's possible to find a nice model design that
ensures these kinds of consistency issues:
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> But this is not, what i want.
>
> Cheers Timothy
>
> Eike Stepper schrieb:
>> Timothy,
>>
>> Comments inline...
>>
>>
>>
>> Timothy Marc schrieb:
>>> Ed,
>>>
>>> well, if the reference is bidrectional, i didn't have a problem, but
>>> in my scenario, each Message has two unidirectional references two
>>> MessageEnd (one for sending and one for receiving) and each MessageEnd
>>> has a derived, read-only unidirectional reference to Message. The
>>> message reference will be set, when a MessageEnd was set as either the
>>> receiving or sending end of the Message. It is read-only and derived
>>> to forbid a scenario, in which a Message has some MessageEnds but the
>>> MessageEnd::message points to completely different message...
>> If I understand your design correctly you'd just need to model the
>> references between Message and MessageEnd so that they're bidirectional.
>> Then the EMF runtime cares for consistent instances. Why are you trying
>> to achieve the same thing with complicated own code?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>> To realize the derived reference, i thought the best way is by
>>> observing the setReceive/SendEnd() methods, intercept the the notifier
>>> within the observer (the MessageEnd) and set the message reference
>>> within the notifyChanged() method. As mentioned, i thought the adapter
>>> scneraio is quite similar to the observer pattern...
>>>
>>> May be, this figures my question, respectively problem, out better.
>>>
>>> Timothy
>>>
>>> Ed Merks schrieb:
>>>> Timothy,
>>>>
>>>> Comments below.
>>>>
>>>> Timothy Marc wrote:
>>>>> Hi all,
>>>>>
>>>>> i've some really understanding problems with EMF Adapter mechanism.
>>>> Oh really?
>>>>> As the EMF Bible
>>>> Hehehe.
>>>>> says, Adapters are Observer, and every EObject has the capability to
>>>>> act as an "Observable" (Notifier).
>>>> If the Bible says it, it must be a fact, clearly!
>>>>> But for what purpose should an adapter be used?
>>>> For listening. For adding behavioral extensions. For something we
>>>> might not even have imagined?
>>>>> IMHO, they should register an EObject as an "Observer" in another
>>>>> EObject, shouldn't they?
>>>> How humble is that? They register an Adapter, which generally won't
>>>> be an EObject...
>>>>> I was wondering, that the book let the Adapters act as an single
>>>>> Object, which is not inherited by any other EObject (In contrst to
>>>>> the Observer-Pattern, where each subject is a special class of an
>>>>> Observer).
>>>> I'm not sure why you decided that Observer == EObject. Observer ==
>>>> Adapter is more accurate... You're not expecting generally that an
>>>> Observer is an Observable are you?
>>>>>
>>>>> In my scenario, i want to notify a MessageEnd object, that a Message
>>>>> object corelated to it, when the MessageEnd was added to the
>>>>> message's receiving/sending end. Therefore, i thought i had to
>>>>> implement the MessageEnd adapter and register it at each the Message
>>>>> during creation process in the corresponding Efactory create()
>>>>> method.
>>>> That hurts my brain a little bit. Generally if you have a
>>>> bidirectional reference, both objects at each end of the reference
>>>> will be notified of their association with the other...
>>>>> As mentioned, i was wondering, that the book didn't show any
>>>>> scenario like this. But may be, i missunderstand the mechanism
>>>>> completely...
>>>> Maybe, but I'm a little confused at this point. If you have a
>>>> Message and a MessageEnd, and they have a bidirectional reference
>>>> between them, when you set that reference, both the Message and the
>>>> MessageEnd will be notified via their Adapter that they've been
>>>> changed...
>>>>>
>>>>> Thanks
>>>>> /Timothy
--------------090403090704030302050006
Content-Type: multipart/related;
boundary="------------050608070508050306080702"
--------------050608070508050306080702
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Timothy Marc schrieb:
<blockquote cite="mid:h5tujf$sj2$1@build.eclipse.org" type="cite">Eike,
<br>
<br>
no, if it would be so simple, i wouldn't spent so many time for it. As
i
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding Adapters [message #479731 is a reply to message #479729] |
Wed, 12 August 2009 08:51 |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Timothy,
I'd suggest making the references bidirectional as Eike pointed out.
Sure you'll have two message references, but if you feel so compelled,
you could hide them from the generated API. The point being that now
you'll have exactly the right features from which to derive your one
message reference. Although I wonder if the same message can be both
part of a sendMessageEnd and a receiveMessageEnd? If so, don't you need
two references because the could be different Messages? If not, what
prevents that? I don't suppose these are containment references are
they? (Then you could just derive from eContainer().)
Timothy Marc wrote:
> Eike,
>
> no, if it would be so simple, i wouldn't spent so many time for it. As
> i mentioned, Message has 2 references to MessageEnd.
>
> Message
> +sendMessgeEnd:MessageEnd
> +receiveMessageEnd:MessageEnd
>
> MessageEnd
> +/message 1 {read-only}
>
> If these references had been made bidirectional, each message end
> would contain two message references. But this is not, what i want.
>
> Cheers Timothy
>
> Eike Stepper schrieb:
>> Timothy,
>>
>> Comments inline...
>>
>>
>>
>> Timothy Marc schrieb:
>>> Ed,
>>>
>>> well, if the reference is bidrectional, i didn't have a problem, but
>>> in my scenario, each Message has two unidirectional references two
>>> MessageEnd (one for sending and one for receiving) and each MessageEnd
>>> has a derived, read-only unidirectional reference to Message. The
>>> message reference will be set, when a MessageEnd was set as either the
>>> receiving or sending end of the Message. It is read-only and derived
>>> to forbid a scenario, in which a Message has some MessageEnds but the
>>> MessageEnd::message points to completely different message...
>> If I understand your design correctly you'd just need to model the
>> references between Message and MessageEnd so that they're bidirectional.
>> Then the EMF runtime cares for consistent instances. Why are you trying
>> to achieve the same thing with complicated own code?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>> To realize the derived reference, i thought the best way is by
>>> observing the setReceive/SendEnd() methods, intercept the the notifier
>>> within the observer (the MessageEnd) and set the message reference
>>> within the notifyChanged() method. As mentioned, i thought the adapter
>>> scneraio is quite similar to the observer pattern...
>>>
>>> May be, this figures my question, respectively problem, out better.
>>>
>>> Timothy
>>>
>>> Ed Merks schrieb:
>>>> Timothy,
>>>>
>>>> Comments below.
>>>>
>>>> Timothy Marc wrote:
>>>>> Hi all,
>>>>>
>>>>> i've some really understanding problems with EMF Adapter mechanism.
>>>> Oh really?
>>>>> As the EMF Bible
>>>> Hehehe.
>>>>> says, Adapters are Observer, and every EObject has the capability to
>>>>> act as an "Observable" (Notifier).
>>>> If the Bible says it, it must be a fact, clearly!
>>>>> But for what purpose should an adapter be used?
>>>> For listening. For adding behavioral extensions. For something we
>>>> might not even have imagined?
>>>>> IMHO, they should register an EObject as an "Observer" in another
>>>>> EObject, shouldn't they?
>>>> How humble is that? They register an Adapter, which generally won't
>>>> be an EObject...
>>>>> I was wondering, that the book let the Adapters act as an single
>>>>> Object, which is not inherited by any other EObject (In contrst to
>>>>> the Observer-Pattern, where each subject is a special class of an
>>>>> Observer).
>>>> I'm not sure why you decided that Observer == EObject. Observer ==
>>>> Adapter is more accurate... You're not expecting generally that an
>>>> Observer is an Observable are you?
>>>>>
>>>>> In my scenario, i want to notify a MessageEnd object, that a Message
>>>>> object corelated to it, when the MessageEnd was added to the
>>>>> message's receiving/sending end. Therefore, i thought i had to
>>>>> implement the MessageEnd adapter and register it at each the Message
>>>>> during creation process in the corresponding Efactory create()
>>>>> method.
>>>> That hurts my brain a little bit. Generally if you have a
>>>> bidirectional reference, both objects at each end of the reference
>>>> will be notified of their association with the other...
>>>>> As mentioned, i was wondering, that the book didn't show any
>>>>> scenario like this. But may be, i missunderstand the mechanism
>>>>> completely...
>>>> Maybe, but I'm a little confused at this point. If you have a
>>>> Message and a MessageEnd, and they have a bidirectional reference
>>>> between them, when you set that reference, both the Message and the
>>>> MessageEnd will be notified via their Adapter that they've been
>>>> changed...
>>>>>
>>>>> Thanks
>>>>> /Timothy
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Understanding Adapters [message #479758 is a reply to message #479731] |
Wed, 12 August 2009 11:12 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Ed,
no, these are no containments. To make it moe clear, why chosing this
kind of structure. It depends on the UML2 superstructure for
interactions. In UML2 the message reference is not derived, but this
allows, that a modeler can reference a message from a message end, for
which this message end is neither the sending nor receiving message end.
And the same message acts of course as message for both
receiving/sending message end, since a message is framed by exactly two
message ends (in UML2).
So, i had the idea to make the message reference in a MessageEnd derived
and read-only and let each instance of MessageEnd acting as an adapter,
registered by each message instance. Inside the notifyChanged() method,
i have access to all the structural features of a MessageEnd and can set
the variable, whic is returned by getMessage(), with the notifying object.
Well, Eike's idea is another possible solution, but this introduces two
new, from my point of view, unnecessary and functionally redundant
metaclasses.
Timothy
Ed Merks schrieb:
> Timothy,
>
> I'd suggest making the references bidirectional as Eike pointed out.
> Sure you'll have two message references, but if you feel so compelled,
> you could hide them from the generated API. The point being that now
> you'll have exactly the right features from which to derive your one
> message reference. Although I wonder if the same message can be both
> part of a sendMessageEnd and a receiveMessageEnd? If so, don't you need
> two references because the could be different Messages? If not, what
> prevents that? I don't suppose these are containment references are
> they? (Then you could just derive from eContainer().)
>
>
> Timothy Marc wrote:
>> Eike,
>>
>> no, if it would be so simple, i wouldn't spent so many time for it. As
>> i mentioned, Message has 2 references to MessageEnd.
>>
>> Message
>> +sendMessgeEnd:MessageEnd
>> +receiveMessageEnd:MessageEnd
>>
>> MessageEnd
>> +/message 1 {read-only}
>>
>> If these references had been made bidirectional, each message end
>> would contain two message references. But this is not, what i want.
>>
>> Cheers Timothy
>>
>> Eike Stepper schrieb:
>>> Timothy,
>>>
>>> Comments inline...
>>>
>>>
>>>
>>> Timothy Marc schrieb:
>>>> Ed,
>>>>
>>>> well, if the reference is bidrectional, i didn't have a problem, but
>>>> in my scenario, each Message has two unidirectional references two
>>>> MessageEnd (one for sending and one for receiving) and each MessageEnd
>>>> has a derived, read-only unidirectional reference to Message. The
>>>> message reference will be set, when a MessageEnd was set as either the
>>>> receiving or sending end of the Message. It is read-only and derived
>>>> to forbid a scenario, in which a Message has some MessageEnds but the
>>>> MessageEnd::message points to completely different message...
>>> If I understand your design correctly you'd just need to model the
>>> references between Message and MessageEnd so that they're bidirectional.
>>> Then the EMF runtime cares for consistent instances. Why are you trying
>>> to achieve the same thing with complicated own code?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>> To realize the derived reference, i thought the best way is by
>>>> observing the setReceive/SendEnd() methods, intercept the the notifier
>>>> within the observer (the MessageEnd) and set the message reference
>>>> within the notifyChanged() method. As mentioned, i thought the adapter
>>>> scneraio is quite similar to the observer pattern...
>>>>
>>>> May be, this figures my question, respectively problem, out better.
>>>>
>>>> Timothy
>>>>
>>>> Ed Merks schrieb:
>>>>> Timothy,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Timothy Marc wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> i've some really understanding problems with EMF Adapter mechanism.
>>>>> Oh really?
>>>>>> As the EMF Bible
>>>>> Hehehe.
>>>>>> says, Adapters are Observer, and every EObject has the capability to
>>>>>> act as an "Observable" (Notifier).
>>>>> If the Bible says it, it must be a fact, clearly!
>>>>>> But for what purpose should an adapter be used?
>>>>> For listening. For adding behavioral extensions. For something we
>>>>> might not even have imagined?
>>>>>> IMHO, they should register an EObject as an "Observer" in another
>>>>>> EObject, shouldn't they?
>>>>> How humble is that? They register an Adapter, which generally won't
>>>>> be an EObject...
>>>>>> I was wondering, that the book let the Adapters act as an single
>>>>>> Object, which is not inherited by any other EObject (In contrst to
>>>>>> the Observer-Pattern, where each subject is a special class of an
>>>>>> Observer).
>>>>> I'm not sure why you decided that Observer == EObject. Observer ==
>>>>> Adapter is more accurate... You're not expecting generally that an
>>>>> Observer is an Observable are you?
>>>>>>
>>>>>> In my scenario, i want to notify a MessageEnd object, that a Message
>>>>>> object corelated to it, when the MessageEnd was added to the
>>>>>> message's receiving/sending end. Therefore, i thought i had to
>>>>>> implement the MessageEnd adapter and register it at each the Message
>>>>>> during creation process in the corresponding Efactory create()
>>>>>> method.
>>>>> That hurts my brain a little bit. Generally if you have a
>>>>> bidirectional reference, both objects at each end of the reference
>>>>> will be notified of their association with the other...
>>>>>> As mentioned, i was wondering, that the book didn't show any
>>>>>> scenario like this. But may be, i missunderstand the mechanism
>>>>>> completely...
>>>>> Maybe, but I'm a little confused at this point. If you have a
>>>>> Message and a MessageEnd, and they have a bidirectional reference
>>>>> between them, when you set that reference, both the Message and the
>>>>> MessageEnd will be notified via their Adapter that they've been
>>>>> changed...
>>>>>>
>>>>>> Thanks
>>>>>> /Timothy
|
|
|
| Re: Understanding Adapters [message #479763 is a reply to message #479758] |
Wed, 12 August 2009 12:59 |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040101060509080607040401
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Timothy,
Comments below.
Timothy Marc wrote:
> Ed,
>
> no, these are no containments. To make it moe clear, why chosing this
> kind of structure. It depends on the UML2 superstructure for
> interactions. In UML2 the message reference is not derived, but this
> allows, that a modeler can reference a message from a message end, for
> which this message end is neither the sending nor receiving message end.
> And the same message acts of course as message for both
> receiving/sending message end, since a message is framed by exactly
> two message ends (in UML2).
>
> So, i had the idea to make the message reference in a MessageEnd
> derived and read-only and let each instance of MessageEnd acting as an
> adapter, registered by each message instance. Inside the
> notifyChanged() method, i have access to all the structural features
> of a MessageEnd and can set the variable, whic is returned by
> getMessage(), with the notifying object.
As Eike said, you're basically trying to implement a bidirectional
reference. I notice that you didn't answer my question though so let me
repeat it:
Can a given message be in both a sendMessageEnd and a
receiveMessageEnd reference?
>
> Well, Eike's idea is another possible solution, but this introduces
> two new, from my point of view, unnecessary and functionally redundant
> metaclasses.
My suggestion was to introduce two actual bidirectional references,
i.e., define opposites for sendMessageEnd and receiveMessageEnd without
introducing any new classes, and then derive your other reference from
those two. That still leaves the above question begging for an answer
because nothing prevents both the new references from being set and in
fact if you don't make them bidirectional, nothing prevents the same
MessageEnd from being used in an arbitrary number of sendMessageEnds and
receiveMessageEnds, which I assume definitely isn't sensible or you'd
not be trying to derive a single Message reference.
>
> Timothy
>
>
> Ed Merks schrieb:
>> Timothy,
>>
>> I'd suggest making the references bidirectional as Eike pointed out.
>> Sure you'll have two message references, but if you feel so
>> compelled, you could hide them from the generated API. The point
>> being that now you'll have exactly the right features from which to
>> derive your one message reference. Although I wonder if the same
>> message can be both part of a sendMessageEnd and a
>> receiveMessageEnd? If so, don't you need two references because the
>> could be different Messages? If not, what prevents that? I don't
>> suppose these are containment references are they? (Then you could
>> just derive from eContainer().)
>>
>>
>> Timothy Marc wrote:
>>> Eike,
>>>
>>> no, if it would be so simple, i wouldn't spent so many time for it.
>>> As i mentioned, Message has 2 references to MessageEnd.
>>>
>>> Message
>>> +sendMessgeEnd:MessageEnd
>>> +receiveMessageEnd:MessageEnd
>>>
>>> MessageEnd
>>> +/message 1 {read-only}
>>>
>>> If these references had been made bidirectional, each message end
>>> would contain two message references. But this is not, what i want.
>>>
>>> Cheers Timothy
>>>
>>> Eike Stepper schrieb:
>>>> Timothy,
>>>>
>>>> Comments inline...
>>>>
>>>>
>>>>
>>>> Timothy Marc schrieb:
>>>>> Ed,
>>>>>
>>>>> well, if the reference is bidrectional, i didn't have a problem, but
>>>>> in my scenario, each Message has two unidirectional references two
>>>>> MessageEnd (one for sending and one for receiving) and each
>>>>> MessageEnd
>>>>> has a derived, read-only unidirectional reference to Message. The
>>>>> message reference will be set, when a MessageEnd was set as either
>>>>> the
>>>>> receiving or sending end of the Message. It is read-only and derived
>>>>> to forbid a scenario, in which a Message has some MessageEnds but the
>>>>> MessageEnd::message points to completely different message...
>>>> If I understand your design correctly you'd just need to model the
>>>> references between Message and MessageEnd so that they're
>>>> bidirectional.
>>>> Then the EMF runtime cares for consistent instances. Why are you
>>>> trying
>>>> to achieve the same thing with complicated own code?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>> To realize the derived reference, i thought the best way is by
>>>>> observing the setReceive/SendEnd() methods, intercept the the
>>>>> notifier
>>>>> within the observer (the MessageEnd) and set the message reference
>>>>> within the notifyChanged() method. As mentioned, i thought the
>>>>> adapter
>>>>> scneraio is quite similar to the observer pattern...
>>>>>
>>>>> May be, this figures my question, respectively problem, out better.
>>>>>
>>>>> Timothy
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Timothy,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Timothy Marc wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> i've some really understanding problems with EMF Adapter mechanism.
>>>>>> Oh really?
>>>>>>> As the EMF Bible
>>>>>> Hehehe.
>>>>>>> says, Adapters are Observer, and every EObject has the
>>>>>>> capability to
>>>>>>> act as an "Observable" (Notifier).
>>>>>> If the Bible says it, it must be a fact, clearly!
>>>>>>> But for what purpose should an adapter be used?
>>>>>> For listening. For adding behavioral extensions. For something we
>>>>>> might not even have imagined?
>>>>>>> IMHO, they should register an EObject as an "Observer" in another
>>>>>>> EObject, shouldn't they?
>>>>>> How humble is that? They register an Adapter, which generally won't
>>>>>> be an EObject...
>>>>>>> I was wondering, that the book let the Adapters act as an single
>>>>>>> Object, which is not inherited by any other EObject (In contrst to
>>>>>>> the Observer-Pattern, where each subject is a special class of an
>>>>>>> Observer).
>>>>>> I'm not sure why you decided that Observer == EObject. Observer ==
>>>>>> Adapter is more accurate... You're not expecting generally that an
>>>>>> Observer is an Observable are you?
>>>>>>>
>>>>>>> In my scenario, i want to notify a MessageEnd object, that a
>>>>>>> Message
>>>>>>> object corelated to it, when the MessageEnd was added to the
>>>>>>> message's receiving/sending end. Therefore, i thought i had to
>>>>>>> implement the MessageEnd adapter and register it at each the
>>>>>>> Message
>>>>>>> during creation process in the corresponding Efactory create()
>>>>>>> method.
>>>>>> That hurts my brain a little bit. Generally if you have a
>>>>>> bidirectional reference, both objects at each end of the reference
>>>>>> will be notified of their association with the other...
>>>>>>> As mentioned, i was wondering, that the book didn't show any
>>>>>>> scenario like this. But may be, i missunderstand the mechanism
>>>>>>> completely...
>>>>>> Maybe, but I'm a little confused at this point. If you have a
>>>>>> Message and a MessageEnd, and they have a bidirectional reference
>>>>>> between them, when you set that reference, both the Message and the
>>>>>> MessageEnd will be notified via their Adapter that they've been
>>>>>> changed...
>>>>>>>
>>>>>>> Thanks
>>>>>>> /Timothy
--------------040101060509080607040401
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Timothy,<br>
<br>
Comments below.<br>
<br>
Timothy Marc wrote:
<blockquote cite="mid:h5u81u$t0k$1@build.eclipse.org" type="cite">Ed,
<br>
<br>
no, these are no containments. To make it moe clear, why chosing this
kind of structure. It depends on the UML2 superstructure for
interactions. In UML2 the message reference is not derived, but this
allows, that a modeler can reference a message from a message end, for
which this message end is neither the sending nor receiving message
end.
<br>
And the same message acts of course as message for both
receiving/sending message end, since a message is framed by exactly two
message ends (in UML2).
<br>
<br>
So, i had the idea to make the message reference in a MessageEnd
derived and read-only and let each instance of MessageEnd acting as an
adapter, registered by each message instance. Inside the
notifyChanged() method, i have access to all the structural features of
a MessageEnd and can set
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Understanding Adapters [message #479793 is a reply to message #479763] |
Wed, 12 August 2009 14:16 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Ed,
> Can a given message be in both a sendMessageEnd and a
> receiveMessageEnd reference?
In case both referenced would have been made bidirectional, a given
message would only participate in one of them. Because one message end
can only represent the sending or receiving of one particular message.
> in fact if you don't make them bidirectional, nothing prevents the same
> MessageEnd from being used in an arbitrary number of sendMessageEnds
Well, these referenced had the multiplicity 0..1. So, it would be
removed from a message send/receive end, if another message sets this
message to one of each ends.
But to shorten this, may be i will redesign my model, even it is not
convenient in my opinion. The idea, that the message end acts as an
observer is much pretty...
Timothy
Ed Merks schrieb:
> Timothy,
>
> Comments below.
>
> Timothy Marc wrote:
>> Ed,
>>
>> no, these are no containments. To make it moe clear, why chosing this
>> kind of structure. It depends on the UML2 superstructure for
>> interactions. In UML2 the message reference is not derived, but this
>> allows, that a modeler can reference a message from a message end, for
>> which this message end is neither the sending nor receiving message end.
>> And the same message acts of course as message for both
>> receiving/sending message end, since a message is framed by exactly
>> two message ends (in UML2).
>>
>> So, i had the idea to make the message reference in a MessageEnd
>> derived and read-only and let each instance of MessageEnd acting as an
>> adapter, registered by each message instance. Inside the
>> notifyChanged() method, i have access to all the structural features
>> of a MessageEnd and can set the variable, whic is returned by
>> getMessage(), with the notifying object.
> As Eike said, you're basically trying to implement a bidirectional
> reference. I notice that you didn't answer my question though so let me
> repeat it:
>
> Can a given message be in both a sendMessageEnd and a
> receiveMessageEnd reference?
>
>>
>> Well, Eike's idea is another possible solution, but this introduces
>> two new, from my point of view, unnecessary and functionally redundant
>> metaclasses.
> My suggestion was to introduce two actual bidirectional references,
> i.e., define opposites for sendMessageEnd and receiveMessageEnd without
> introducing any new classes, and then derive your other reference from
> those two. That still leaves the above question begging for an answer
> because nothing prevents both the new references from being set and in
> fact if you don't make them bidirectional, nothing prevents the same
> MessageEnd from being used in an arbitrary number of sendMessageEnds and
> receiveMessageEnds, which I assume definitely isn't sensible or you'd
> not be trying to derive a single Message reference.
>>
>> Timothy
>>
>>
>> Ed Merks schrieb:
>>> Timothy,
>>>
>>> I'd suggest making the references bidirectional as Eike pointed out.
>>> Sure you'll have two message references, but if you feel so
>>> compelled, you could hide them from the generated API. The point
>>> being that now you'll have exactly the right features from which to
>>> derive your one message reference. Although I wonder if the same
>>> message can be both part of a sendMessageEnd and a
>>> receiveMessageEnd? If so, don't you need two references because the
>>> could be different Messages? If not, what prevents that? I don't
>>> suppose these are containment references are they? (Then you could
>>> just derive from eContainer().)
>>>
>>>
>>> Timothy Marc wrote:
>>>> Eike,
>>>>
>>>> no, if it would be so simple, i wouldn't spent so many time for it.
>>>> As i mentioned, Message has 2 references to MessageEnd.
>>>>
>>>> Message
>>>> +sendMessgeEnd:MessageEnd
>>>> +receiveMessageEnd:MessageEnd
>>>>
>>>> MessageEnd
>>>> +/message 1 {read-only}
>>>>
>>>> If these references had been made bidirectional, each message end
>>>> would contain two message references. But this is not, what i want.
>>>>
>>>> Cheers Timothy
>>>>
>>>> Eike Stepper schrieb:
>>>>> Timothy,
>>>>>
>>>>> Comments inline...
>>>>>
>>>>>
>>>>>
>>>>> Timothy Marc schrieb:
>>>>>> Ed,
>>>>>>
>>>>>> well, if the reference is bidrectional, i didn't have a problem, but
>>>>>> in my scenario, each Message has two unidirectional references two
>>>>>> MessageEnd (one for sending and one for receiving) and each
>>>>>> MessageEnd
>>>>>> has a derived, read-only unidirectional reference to Message. The
>>>>>> message reference will be set, when a MessageEnd was set as either
>>>>>> the
>>>>>> receiving or sending end of the Message. It is read-only and derived
>>>>>> to forbid a scenario, in which a Message has some MessageEnds but the
>>>>>> MessageEnd::message points to completely different message...
>>>>> If I understand your design correctly you'd just need to model the
>>>>> references between Message and MessageEnd so that they're
>>>>> bidirectional.
>>>>> Then the EMF runtime cares for consistent instances. Why are you
>>>>> trying
>>>>> to achieve the same thing with complicated own code?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>>> To realize the derived reference, i thought the best way is by
>>>>>> observing the setReceive/SendEnd() methods, intercept the the
>>>>>> notifier
>>>>>> within the observer (the MessageEnd) and set the message reference
>>>>>> within the notifyChanged() method. As mentioned, i thought the
>>>>>> adapter
>>>>>> scneraio is quite similar to the observer pattern...
>>>>>>
>>>>>> May be, this figures my question, respectively problem, out better.
>>>>>>
>>>>>> Timothy
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Timothy,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>> Timothy Marc wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> i've some really understanding problems with EMF Adapter mechanism.
>>>>>>> Oh really?
>>>>>>>> As the EMF Bible
>>>>>>> Hehehe.
>>>>>>>> says, Adapters are Observer, and every EObject has the
>>>>>>>> capability to
>>>>>>>> act as an "Observable" (Notifier).
>>>>>>> If the Bible says it, it must be a fact, clearly!
>>>>>>>> But for what purpose should an adapter be used?
>>>>>>> For listening. For adding behavioral extensions. For something we
>>>>>>> might not even have imagined?
>>>>>>>> IMHO, they should register an EObject as an "Observer" in another
>>>>>>>> EObject, shouldn't they?
>>>>>>> How humble is that? They register an Adapter, which generally won't
>>>>>>> be an EObject...
>>>>>>>> I was wondering, that the book let the Adapters act as an single
>>>>>>>> Object, which is not inherited by any other EObject (In contrst to
>>>>>>>> the Observer-Pattern, where each subject is a special class of an
>>>>>>>> Observer).
>>>>>>> I'm not sure why you decided that Observer == EObject. Observer ==
>>>>>>> Adapter is more accurate... You're not expecting generally that an
>>>>>>> Observer is an Observable are you?
>>>>>>>>
>>>>>>>> In my scenario, i want to notify a MessageEnd object, that a
>>>>>>>> Message
>>>>>>>> object corelated to it, when the MessageEnd was added to the
>>>>>>>> message's receiving/sending end. Therefore, i thought i had to
>>>>>>>> implement the MessageEnd adapter and register it at each the
>>>>>>>> Message
>>>>>>>> during creation process in the corresponding Efactory create()
>>>>>>>> method.
>>>>>>> That hurts my brain a little bit. Generally if you have a
>>>>>>> bidirectional reference, both objects at each end of the reference
>>>>>>> will be notified of their association with the other...
>>>>>>>> As mentioned, i was wondering, that the book didn't show any
>>>>>>>> scenario like this. But may be, i missunderstand the mechanism
>>>>>>>> completely...
>>>>>>> Maybe, but I'm a little confused at this point. If you have a
>>>>>>> Message and a MessageEnd, and they have a bidirectional reference
>>>>>>> between them, when you set that reference, both the Message and the
>>>>>>> MessageEnd will be notified via their Adapter that they've been
>>>>>>> changed...
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> /Timothy
|
|
|
| Re: Understanding Adapters [message #479800 is a reply to message #479793] |
Wed, 12 August 2009 14:36 |
Ed Merks
Messages: 33217
Registered: July 2009 |
Senior Member |
|
|
Timothy,
Comments below.
Timothy Marc wrote:
> Ed,
>
> > Can a given message be in both a sendMessageEnd and a
> > receiveMessageEnd reference?
>
> In case both referenced would have been made bidirectional, a given
> message would only participate in one of them. Because one message end
> can only represent the sending or receiving of one particular message.
You'd have to model that as a constraint that only one of these two
features on MessageEnd can be set...
>
> > in fact if you don't make them bidirectional, nothing prevents the same
> > MessageEnd from being used in an arbitrary number of sendMessageEnds
>
> Well, these referenced had the multiplicity 0..1.
Yes, but only in one direction...
> So, it would be removed from a message send/receive end, if another
> message sets this message to one of each ends.
Not unless you make it bidirectional.
>
> But to shorten this, may be i will redesign my model, even it is not
> convenient in my opinion.
The approach you were trying to take is even less convenient.
> The idea, that the message end acts as an observer is much pretty...
No, it's a really bad idea, in my opinion, and one I'm sure you'll
discover should you go down that route.
>
> Timothy
>
>
> Ed Merks schrieb:
>> Timothy,
>>
>> Comments below.
>>
>> Timothy Marc wrote:
>>> Ed,
>>>
>>> no, these are no containments. To make it moe clear, why chosing
>>> this kind of structure. It depends on the UML2 superstructure for
>>> interactions. In UML2 the message reference is not derived, but this
>>> allows, that a modeler can reference a message from a message end,
>>> for which this message end is neither the sending nor receiving
>>> message end.
>>> And the same message acts of course as message for both
>>> receiving/sending message end, since a message is framed by exactly
>>> two message ends (in UML2).
>>>
>>> So, i had the idea to make the message reference in a MessageEnd
>>> derived and read-only and let each instance of MessageEnd acting as
>>> an adapter, registered by each message instance. Inside the
>>> notifyChanged() method, i have access to all the structural features
>>> of a MessageEnd and can set the variable, whic is returned by
>>> getMessage(), with the notifying object.
>> As Eike said, you're basically trying to implement a bidirectional
>> reference. I notice that you didn't answer my question though so let
>> me repeat it:
>>
>> Can a given message be in both a sendMessageEnd and a
>> receiveMessageEnd reference?
>>>
>>> Well, Eike's idea is another possible solution, but this introduces
>>> two new, from my point of view, unnecessary and functionally
>>> redundant metaclasses.
>> My suggestion was to introduce two actual bidirectional references,
>> i.e., define opposites for sendMessageEnd and receiveMessageEnd
>> without introducing any new classes, and then derive your other
>> reference from those two. That still leaves the above question
>> begging for an answer because nothing prevents both the new
>> references from being set and in fact if you don't make them
>> bidirectional, nothing prevents the same MessageEnd from being used
>> in an arbitrary number of sendMessageEnds and receiveMessageEnds,
>> which I assume definitely isn't sensible or you'd not be trying to
>> derive a single Message reference.
>>>
>>> Timothy
>>>
>>>
>>> Ed Merks schrieb:
>>>> Timothy,
>>>>
>>>> I'd suggest making the references bidirectional as Eike pointed
>>>> out. Sure you'll have two message references, but if you feel so
>>>> compelled, you could hide them from the generated API. The point
>>>> being that now you'll have exactly the right features from which to
>>>> derive your one message reference. Although I wonder if the same
>>>> message can be both part of a sendMessageEnd and a
>>>> receiveMessageEnd? If so, don't you need two references because
>>>> the could be different Messages? If not, what prevents that? I
>>>> don't suppose these are containment references are they? (Then you
>>>> could just derive from eContainer().)
>>>>
>>>>
>>>> Timothy Marc wrote:
>>>>> Eike,
>>>>>
>>>>> no, if it would be so simple, i wouldn't spent so many time for
>>>>> it. As i mentioned, Message has 2 references to MessageEnd.
>>>>>
>>>>> Message
>>>>> +sendMessgeEnd:MessageEnd
>>>>> +receiveMessageEnd:MessageEnd
>>>>>
>>>>> MessageEnd
>>>>> +/message 1 {read-only}
>>>>>
>>>>> If these references had been made bidirectional, each message end
>>>>> would contain two message references. But this is not, what i want.
>>>>>
>>>>> Cheers Timothy
>>>>>
>>>>> Eike Stepper schrieb:
>>>>>> Timothy,
>>>>>>
>>>>>> Comments inline...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Timothy Marc schrieb:
>>>>>>> Ed,
>>>>>>>
>>>>>>> well, if the reference is bidrectional, i didn't have a problem,
>>>>>>> but
>>>>>>> in my scenario, each Message has two unidirectional references two
>>>>>>> MessageEnd (one for sending and one for receiving) and each
>>>>>>> MessageEnd
>>>>>>> has a derived, read-only unidirectional reference to Message. The
>>>>>>> message reference will be set, when a MessageEnd was set as
>>>>>>> either the
>>>>>>> receiving or sending end of the Message. It is read-only and
>>>>>>> derived
>>>>>>> to forbid a scenario, in which a Message has some MessageEnds
>>>>>>> but the
>>>>>>> MessageEnd::message points to completely different message...
>>>>>> If I understand your design correctly you'd just need to model the
>>>>>> references between Message and MessageEnd so that they're
>>>>>> bidirectional.
>>>>>> Then the EMF runtime cares for consistent instances. Why are you
>>>>>> trying
>>>>>> to achieve the same thing with complicated own code?
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>> ----
>>>>>> http://thegordian.blogspot.com
>>>>>> http://twitter.com/eikestepper
>>>>>>
>>>>>>
>>>>>>> To realize the derived reference, i thought the best way is by
>>>>>>> observing the setReceive/SendEnd() methods, intercept the the
>>>>>>> notifier
>>>>>>> within the observer (the MessageEnd) and set the message reference
>>>>>>> within the notifyChanged() method. As mentioned, i thought the
>>>>>>> adapter
>>>>>>> scneraio is quite similar to the observer pattern...
>>>>>>>
>>>>>>> May be, this figures my question, respectively problem, out better.
>>>>>>>
>>>>>>> Timothy
>>>>>>>
>>>>>>> Ed Merks schrieb:
>>>>>>>> Timothy,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>> Timothy Marc wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> i've some really understanding problems with EMF Adapter
>>>>>>>>> mechanism.
>>>>>>>> Oh really?
>>>>>>>>> As the EMF Bible
>>>>>>>> Hehehe.
>>>>>>>>> says, Adapters are Observer, and every EObject has the
>>>>>>>>> capability to
>>>>>>>>> act as an "Observable" (Notifier).
>>>>>>>> If the Bible says it, it must be a fact, clearly!
>>>>>>>>> But for what purpose should an adapter be used?
>>>>>>>> For listening. For adding behavioral extensions. For
>>>>>>>> something we
>>>>>>>> might not even have imagined?
>>>>>>>>> IMHO, they should register an EObject as an "Observer" in another
>>>>>>>>> EObject, shouldn't they?
>>>>>>>> How humble is that? They register an Adapter, which generally
>>>>>>>> won't
>>>>>>>> be an EObject...
>>>>>>>>> I was wondering, that the book let the Adapters act as an single
>>>>>>>>> Object, which is not inherited by any other EObject (In
>>>>>>>>> contrst to
>>>>>>>>> the Observer-Pattern, where each subject is a special class of an
>>>>>>>>> Observer).
>>>>>>>> I'm not sure why you decided that Observer == EObject.
>>>>>>>> Observer ==
>>>>>>>> Adapter is more accurate... You're not expecting generally
>>>>>>>> that an
>>>>>>>> Observer is an Observable are you?
>>>>>>>>>
>>>>>>>>> In my scenario, i want to notify a MessageEnd object, that a
>>>>>>>>> Message
>>>>>>>>> object corelated to it, when the MessageEnd was added to the
>>>>>>>>> message's receiving/sending end. Therefore, i thought i had to
>>>>>>>>> implement the MessageEnd adapter and register it at each the
>>>>>>>>> Message
>>>>>>>>> during creation process in the corresponding Efactory create()
>>>>>>>>> method.
>>>>>>>> That hurts my brain a little bit. Generally if you have a
>>>>>>>> bidirectional reference, both objects at each end of the reference
>>>>>>>> will be notified of their association with the other...
>>>>>>>>> As mentioned, i was wondering, that the book didn't show any
>>>>>>>>> scenario like this. But may be, i missunderstand the mechanism
>>>>>>>>> completely...
>>>>>>>> Maybe, but I'm a little confused at this point. If you have a
>>>>>>>> Message and a MessageEnd, and they have a bidirectional reference
>>>>>>>> between them, when you set that reference, both the Message and
>>>>>>>> the
>>>>>>>> MessageEnd will be notified via their Adapter that they've been
>>>>>>>> changed...
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> /Timothy
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Mon Sep 23 08:58:32 GMT 2024
Powered by FUDForum. Page generated in 0.04177 seconds |
] 
Search
Help
Register
Login
Home
