Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdht-dev] Edit Actions
Sean,

Much of the code style in 'core' was written 10 years ago and evolved.  we need to commit time to upgrading to current Eclipse APIs, for example, all of the command contributions in mdht.uml.ui need to be rewritten as handlers.  Ideally, we would have project funding to support hiring Christian Damus part-time to assist with some of the refactoring like you are asking about for delete/remove, to leverage current EMF capabilities.  I believe he modified at least one of the commands you are looking at.  Not sure about current EMF best practice for this, but expect that the adapter pattern is the way to go.

Looking at the Papyrus docs today, I see that they are working on a major refactoring of API for their 2.0 release, part of Eclipse Neon release in June 2016.  Similarly, we need to plan a major refactoring of MDHT UI to enable Papyrus integration, and to leverage their recent work.  See:

https://wiki.eclipse.org/Papyrus/Migration_Guide/Neon

Dave

On Tue, Feb 2, 2016 at 10:25 AM, sean.muir@xxxxxxxxxxxxxxx <sean.muir@xxxxxxxxxxxxxxx> wrote:
I was in the process of adding some logic to remove stereotype references for terminology constraints

It seems we have two hooks being leveraged to support the actions - i wanted to confirm the way forward 

We have the org.openhealthtools.mdht.uml.ui.navigator.actions.DeleteUMLAction - which supplies a command that manages all the associations during delete

We have org.openhealthtools.mdht.uml.edit.command.RemoveCommandWrapper which supports managing stereotypes and some properties

while the both leverage commands - they are using to different “hooking” mechanisms 

the DeleteUMLAction uses org.eclipse.uml2.common.edit.command.ChangeCommand.ChangeCommand by overwriting the
org.eclipse.emf.edit.ui.action.CommandActionHandler in the org.openhealthtools.mdht.uml.ui.navigator.actions.EditCommandsFactory 


org.openhealthtools.mdht.uml.edit.command.RemoveCommandWrapper uses the adapter pattern by modifying the org.openhealthtools.mdht.uml.edit.provider.UMLEditingDomainAdapterFactory implementation 


I assume we want to leverage the adapter “pattern”  but wanted to confirm 


currently we only have adapters for a handful of the commands

result.put(AddCommand.class, new AddCommandWrapper());
result.put(CreateCopyCommand.class, new CreateCopyCommandWrapper());
result.put(InitializeCopyCommand.class, new InitializeCopyCommandWrapper());
result.put(RemoveCommand.class, new RemoveCommandWrapper());



We do not have a clean mechanism to allow for domains (CDA but i suppose FHIR will need this as well) to have specialized commands - in this case making sure that deleting an enumeration that is referenced in a constraints does not result in an invalid uml model instances 

Dave - have you looked a papyrus recently to see if they built such extensions ?

thanks

Sean











_______________________________________________
mdht-dev mailing list
mdht-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdht-dev


Back to the top