| Summary: | Editor API: Listener Optimizations | ||
|---|---|---|---|
| Product: | [Modeling] Graphiti | Reporter: | Michael Wenz <michael.wenz> |
| Component: | Core | Assignee: | Project Inbox <graphiti-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | matthias.gorning |
| Version: | 0.8.0 | Flags: | michael.wenz:
juno+
|
| Target Milestone: | 0.9.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | Juno M5 Theme_round_offs | ||
| Bug Depends on: | |||
| Bug Blocks: | 336488 | ||
|
Description
Michael Wenz
2 findings: 1) cmdStackListener: CommandStackEventListener (GEF) fwListener: FWCommandStackListener -> CommandStackListener (EMF) Do we really need both listeners? Both update the dirty state, the GEF listener also the contributed actions. Proposal: remove the EMF listener; all executed commands shall be GEF commands running on the GEF command stack 2) domainModelListener: DomainModelChangeListener -> ResourceSetListener diagramChangeListener: DiagramChangeListener -> ResourceSetListener I wonder if unifying would again be a better approach here? Having one listener that does the following: a) Loop over all changed domain objects and try to identify the according pictogram elements (as done in DomainModelChangeListener) b) Loop over all changed pictogram elements and all pictogram elements from step a to identify the edit parts that need an update (as done in DiagramChangeListener) b) Do a selective refresh of these edit parts not the global one from the DomainModelChangeListener (as it is done in DiagramChangeListener) I also wonder if we might get duplictate refreshs with the current approach? (In reply to comment #1) > 2) > domainModelListener: DomainModelChangeListener -> ResourceSetListener > diagramChangeListener: DiagramChangeListener -> ResourceSetListener > I wonder if unifying would again be a better approach here? Having one listener > that does the following: > a) Loop over all changed domain objects and try to identify the according > pictogram elements (as done in DomainModelChangeListener) > b) Loop over all changed pictogram elements and all pictogram elements from > step a to identify the edit parts that need an update (as done in > DiagramChangeListener) > b) Do a selective refresh of these edit parts not the global one from the > DomainModelChangeListener (as it is done in DiagramChangeListener) > I also wonder if we might get duplictate refreshs with the current approach? Rethinking 2) it's probably a bad idea: having two distinct listeners has the benefit that clients can easily disable one (e.g. the EMF domain listener in case of a non-EMF domain model) while letting the other one (diagram listener) operating. Besides it will make the coding easier to understand. 1) is done, checked in to the branch bug336488 and pushed to Eclipse: commit c3d5c0ad1519f6b5e235c81db255b192c8cc0ade Author: mwenz <michael.wenz@sap.com> 2011-11-29 15:14:13 Committer: mwenz <michael.wenz@sap.com> 2011-11-29 17:03:51 Parent: 713cc97c132150305430fb35d8db2ff514017d46 (.) Child: 156d48d94da5ed0ab5561e0c311a47cdf5d70922 (Fixed failing test) Branches: origin/bug336488, bug336488 Has been integrated back into master and pushed to Eclipse. Bookkeeping: Set target release Part of Graphiti 0.9.0 (Eclipse Juno) |