Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 481906

Summary:	Introduce (abstract) base classes for transaction and interaction policies.
Product:	[Tools] GEF	Reporter:	Alexander Nyßen <nyssen>
Component:	GEF MVC	Assignee:	Alexander Nyßen <nyssen>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	0.2.0
Target Milestone:	4.0.0 / 3.11.0 (Neon) M4
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:	482333
Bug Blocks:	481810

Description Alexander Nyßen

2015-11-11 02:41:00 EST

As outlined in bug #481810, we should introduce explicit base classes for transaction and interaction policies. This is not only because this can help to solve the issues outlined in #481810, but it will also help to achieve that a lot of duplicate code within the transaction policies is removed (e.g. the check for initialization, which may be pulled up), and that:

- preventing that operations have to be exposed as protected fields by providing an abstract factory method and an accessor in the abstract base class already (see bug #478901)

- ensure that transaction policies do not duplicate the information kept in their operations by enforcing the existing of an operation that can be executed at any time (see bug #439705)

Comment 1 Alexander Nyßen

2015-11-17 03:26:26 EST

I have applied the necessary refactorings in the bug_481906 topic branch. We should investigate the regression documented in bug #482333 first, and retest the refactorings before applying the branch to master.

Comment 2 Alexander Nyßen

2015-11-17 03:41:30 EST

(In reply to Alexander Nyßen from comment #1)
> I have applied the necessary refactorings in the bug_481906 topic branch. We
> should investigate the regression documented in bug #482333 first, and
> retest the refactorings before applying the branch to master.

As the behavior is exactly identical in the topic branch (compared to current master), its probably safe to apply the topic branch. However, we should not resolve this as fixed before the regression has been fixed and correct behavior can be confirmed with the changes of the topic branch involved.

Comment 3 Alexander Nyßen

2015-11-17 05:24:56 EST

Pushed the following changes to origin/master:

- Introduced abstract AbstractTransactionPolicy base class as the common superclass of all transaction policies, replacing the ITransactional interface. It enforces an init(), commit(), rollback() lifecycle and guards its subclasses against re-initialization and re-commit (which was tolerated up to now) and is based on an transactional operation it locally executes in all working operations.
- Introduced abstract AbstractInteractionPolicy base class as the common superclass of all interaction policies. Moved over init(IPolicy) and  commit(IPolicy) and augmented with rollback(IPolicy).
- Ensured that all transactional operations capture their initial state upon initialization and compute their isNoop() based on that initial state alone. Ensured they are capable of repeated execute() and undo() calls.
- Split ChangeSelectionOperation into SelectOperation and DeselectOperation.
- Removed (unused) ChangeHoverOperation.

After bug #482333 has been resolved, this may be closed as well.

Comment 4 Alexander Nyßen

2015-11-19 12:31:36 EST

As bug #482333 has been resolved, resolving this one as fixed in 3.11.0 M4 as well.