I don't know the purpose of the event but I suspect it is something generic like enabling the save button or an undo button.
The reason I don't think this is a good idea is that it makes the assumption that everything affecting the model will go through our model facade. That we would be expected to be the case at the moment but what if in future we decide to integrate with some 3rd party lib that talks directly to the model. Then we would not be getting our events at all. I'm not saying that we will ever need to do this but I don't think we should design so that we can't. Especially where we have something that is working fine except for one anomoly. Bob. On 12 February 2011 17:20, Thomas Neustupny <[email protected]> wrote: > Bob, > > it's not just the stereotype that is involved. ChangeCommand is used 44 > times, and in all these cases notifyChanged(...) is called with the same > event type, and because the used event type is currently ignored, all these > calls are in vain. > > So, I was thinking about using the current mechanism not only for the already > working add/remove cases, but also for the mentioned 44 cases. All this could > go through notifyChanged(...), and setting the right event type would be in > our hand. > > Thomas > > -------- Original-Nachricht -------- >> Datum: Sat, 12 Feb 2011 12:02:45 +0000 >> Von: Bob Tarling <[email protected]> >> An: [email protected] >> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for tagged >> values? > >> With the existing mechanism we already get add and remove events from >> most model elements. It is peculiar that stereotypes act differently >> but I don't think we should reinvent everything for one peculiarity. >> >> I think we should keep the existing mechanism of propogating events >> and only handle these peculiarites in some other way until we can find >> a better solution. >> >> There may be some pseudo element that represents the container for all >> the models and the stereotypes that we can listen to. If we can build >> a solution using that it would be better but in the menatime I think >> the solution I have proposed is workable. >> >> Bob >> >> On 12 February 2011 11:43, Thomas Neustupny <[email protected]> wrote: >> > Hi Tom, >> > >> > and here is the sample model from the OMG model interchange working >> group (MIWG), the elements are outside the model node too: >> > >> http://www.omgwiki.org/model-interchange/doku.php?id=test_case_3_revision_1 >> > >> > Regarding the original topic, I'd like to ask for review of the >> following approach: >> > >> > notifyChanged(notification) in ModelEventPumpEUMLImpl needs to >> distinguish between the various event notifications, where the event type >> attribute >> seems to be the main criteria. When using our own ChangeCommand >> implementation, the passed event type is always >> ModelEventPumpEUMLImpl.COMMAND_STACK_UPDATE. A solution would be to create a >> set of individual command classes >> (AddCommand, RemoveCommand, MoveCommand etc.) and use them to pass different >> event types, so that we do whatever is needed, and we can let ArgoUML >> behave like it does with MDR. >> > >> > Is that ok? >> > >> > Thomas >> > >> > -------- Original-Nachricht -------- >> >> Datum: Fri, 11 Feb 2011 19:33:27 +0000 >> >> Von: Bob Tarling <[email protected]> >> >> An: [email protected] >> >> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for >> tagged values? >> > >> >> Tom said: >> >> > This sounds a little suspicious to me too. Has anyone compared with >> >> > the serialization produced by Papyrus or UML2 Tools (or any other >> >> > Eclipse UML tool for that matter) to see if they look the same? >> >> >> >> I tried Papyrus - the XMI is similar - the examples below are a class >> >> with no stereotype followed by a class with a stereotype >> >> >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <uml:Model xmi:version="2.1" >> >> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"; >> >> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"; >> >> xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"; >> >> xmi:id="_CPCeIDYIEeChMNP70uFNOw" name="myUMLModel"> >> >> <packageImport xmi:id="_CPCeITYIEeChMNP70uFNOw"> >> >> <importedPackage xmi:type="uml:Model" >> >> href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/> >> >> </packageImport> >> >> <packagedElement xmi:type="uml:Class" >> >> xmi:id="_xaIkQDYMEeCnH6uDrWOpMg" name="Class_0"/> >> >> <profileApplication xmi:id="_CPCeIjYIEeChMNP70uFNOw"> >> >> <eAnnotations xmi:id="_CPCeIzYIEeChMNP70uFNOw" >> >> source="http://www.eclipse.org/uml2/2.0.0/UML";> >> >> <references xmi:type="ecore:EPackage" >> >> href="http://www.eclipse.org/uml2/schemas/Standard/1#/"/> >> >> </eAnnotations> >> >> <appliedProfile >> >> href="pathmap://UML_PROFILES/Standard.profile.uml#_0"/> >> >> </profileApplication> >> >> </uml:Model> >> >> >> >> >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <xmi:XMI xmi:version="2.1" >> >> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"; >> >> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"; >> >> xmlns:standard="http://www.eclipse.org/uml2/schemas/Standard/1"; >> >> xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML";> >> >> <uml:Model xmi:id="_CPCeIDYIEeChMNP70uFNOw" name="myUMLModel"> >> >> <packageImport xmi:id="_CPCeITYIEeChMNP70uFNOw"> >> >> <importedPackage xmi:type="uml:Model" >> >> href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/> >> >> </packageImport> >> >> <packagedElement xmi:type="uml:Class" >> >> xmi:id="_xaIkQDYMEeCnH6uDrWOpMg" name="Class_0"/> >> >> <profileApplication xmi:id="_CPCeIjYIEeChMNP70uFNOw"> >> >> <eAnnotations xmi:id="_CPCeIzYIEeChMNP70uFNOw" >> >> source="http://www.eclipse.org/uml2/2.0.0/UML";> >> >> <references xmi:type="ecore:EPackage" >> >> href="http://www.eclipse.org/uml2/schemas/Standard/1#/"/> >> >> </eAnnotations> >> >> <appliedProfile >> >> href="pathmap://UML_PROFILES/Standard.profile.uml#_0"/> >> >> </profileApplication> >> >> </uml:Model> >> >> <standard:Auxiliary xmi:id="_04DcoDYMEeCnH6uDrWOpMg" >> >> base_Class="_xaIkQDYMEeCnH6uDrWOpMg"/> >> >> </xmi:XMI> >> >> >> >> ------------------------------------------------------ >> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703462 >> >> >> >> To unsubscribe from this discussion, e-mail: >> >> [[email protected]]. >> >> To be allowed to post to the list contact the mailing list moderator, >> >> email: [[email protected]] >> > >> > -- >> > Schon gehört? GMX hat einen genialen Phishing-Filter in die >> > Toolbar eingebaut! http://www.gmx.net/de/go/toolbar >> > >> > ------------------------------------------------------ >> > >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703548 >> > >> > To unsubscribe from this discussion, e-mail: >> [[email protected]]. >> > To be allowed to post to the list contact the mailing list moderator, >> email: [[email protected]] >> > >> >> ------------------------------------------------------ >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703552 >> >> To unsubscribe from this discussion, e-mail: >> [[email protected]]. >> To be allowed to post to the list contact the mailing list moderator, >> email: [[email protected]] > > -- > Schon gehört? GMX hat einen genialen Phishing-Filter in die > Toolbar eingebaut! http://www.gmx.net/de/go/toolbar > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703576 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > To be allowed to post to the list contact the mailing list moderator, email: > [[email protected]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703582 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
