Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-papyrus.dev] Important refactorings

Hi all,

 

 

In addition to the migration to UML 2.5, Papyrus Luna M6 is changing some APIs, and adds new (extended) support for Transactions and Read-only mode.

 

This introduces new best practices, constraints and possibilities that Papyrus developers and extenders should be aware of.

 

First of all, the Papyrus CommandStack now supports nested calls. This means that, in some cases, you don’t need to create compound commands anymore: a Command can create and execute another command during its own execution. This is especially useful when the second command needs results from the first one, or when you want to open a cancelable dialog during a command execution, or when you don’t know whether you are already inside the CommandStack.

 

402525: [Widgets / Transactions] Papyrus dialogs should be transactional

https://bugs.eclipse.org/bugs/show_bug.cgi?id=402525

 

Then, a true read-only mode has been implemented. All user interfaces should reflect the read-only state of an element (When relevant). Moreover, Commands should not try to modify read-only elements anymore (The editing domain would rollback the command). Note that the ReadOnlyManager will need to be refactored/extended again before M6, to support the difference between “Hard” read-only state (Defined by the FileSystem) and “Soft” read-only state (Defined by the logic in the model). See Comments 9 -> 11  in Bug  429239 for details: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429239 (A specific task for this issue has not yet opened)

 

323802: [General] Papyrus shall provide a read only mode

https://bugs.eclipse.org/bugs/show_bug.cgi?id=323802

 

Last, the *.di model is being refactored to remove all user-specific settings from the workspace/project (And avoid conflicts with team working). The *.di model used to contain two elements:

 

-          The PageList, which is not used anymore, as it is now computed dynamically

-          The SashWindowsManager, which contains the editor layout (Which diagrams are opened, and how they are organized)

 

The SashWindowsManager is now moved to the user preference store, in a *.sash resource. For legacy models (When the *.di model contains a SashWindowsManager), there is no change, but new models will be created with an empty *.di resource (Which will be reserved for future use).

 

429239: [Resource Management] Refactoring of the 3-files model and PageManager

https://bugs.eclipse.org/bugs/show_bug.cgi?id=429239

 

There are now three levels of transactions:

 

-          EditingDomain.getCommandStack().execute(Command)

o   The standard way for modifying the model

-          GMFUnsafe.write(EditingDomain, Command)

o   Unsafe transactions can bypass the read-only state of a Resource or EObject. Use only for canonical diagrams (Which need to create transient/volatile objects in the diagram to display it correctly)

-          TransactionHelper.run(EditingDomain, Runnable)

o   Executes a safe transaction which bypasses the CommandStack (i.e. doesn’t dirty the model and is not undoable, unless it is called from an active command which is already undoable)

 

All operations on the SashWindowsManager now use the TransactionHelper (And bypass the CommandStack).

 

Regarding the *.di model refactoring/TransactionHelper, this is still work in progress which is not available on master yet.

 

Please see the respective bugzilla tasks for details on each feature.

 

 

Regards,
Camille

__________________________

Camille Letavernier - camille.letavernier@xxxxxx

CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE)

Papyrus : http://www.eclipse.org/papyrus

 


Back to the top