Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let OperationHandlers return an optional command to control execution #187

Merged
merged 1 commit into from
Jan 27, 2023

Conversation

martin-fleck-at
Copy link
Contributor

  • Elevate concept of command to OperationHandler for more control
    -- Move command handling from EMF to general operation handler

  • Let abstract handlers use recording command for compatibility
    -- Add new 'preExecute' method to abort execution

  • Rewrite compound operation handler to create compound command

  • Minor fixes
    -- Convert ApplyTaskEditActionHandler from operation to action handler

Fixes eclipse-glsp/glsp#864

Copy link
Contributor

@tortmayr tortmayr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Martin! Create change and even nicer API refactoring that cleans up the convoluted OperationHandler type hierarchy without introducing too many API breaks.

Apart from a couple of inline suggestions I noticed the following:
Part of the example operation handlers still use the (now) deprecated handlers which results in a couple of warnings:
Screenshot from 2023-01-26 10-16-43ec6ac70cb0b6.png)

We should clean that up.

Also, since we are touching the Operationhandler API anyways, I was wondering wether we also should refactor and deprecate the CreateEdgeOperationHandler and CreateNodeOperationHandler sub interfaces and base implementations.
From what I can see, their only purpose right now is to enable code sharing of utility functions for the CreateNode use case. The CreateEdgeOperationHandler even is a completely empty marker interface. Maybe it would be better to move the utility functions in question into a util class and remove the unnecessary subtypes of CreateOperationHandler ?


private String taskId;
private String expression;

public ApplyTaskEditOperation() {
public ApplyTaskEditAction() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the client counterpart needs to be updated as well?

* @param operation operation
* @return the matching command for the given operation
*/
static Optional<Command> getExecutableCommand(final OperationHandlerRegistry registry, final Operation operation) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats the purpose of this utility method? Wouldn't it be better to implement this as a direct method of the OperationHandlerRegistry ?

CHANGELOG.md Outdated Show resolved Hide resolved
CHANGELOG.md Show resolved Hide resolved
Make OperationHandler take a generic type
- Deprecate Abstract base classes and provide Basic*, EMF*, GModel*
- Adapt handlers to use new base class

- Elevate concept of command to OperationHandler for more control
-- Move command handling from EMF to general operation handler

- Let abstract handlers use recording command for compatibility
-- Add new 'preExecute' method to abort execution

- Minor fixes
-- Convert ApplyTaskEditActionHandler from operation to action handler

Fixes eclipse-glsp/glsp#864
@tortmayr
Copy link
Contributor

Awesome! Changes look good to me. 👍🏼

@tortmayr tortmayr self-requested a review January 27, 2023 14:32
@martin-fleck-at martin-fleck-at merged commit ecf8fb4 into master Jan 27, 2023
@martin-fleck-at martin-fleck-at deleted the issue-864 branch January 27, 2023 14:53
ndoschek added a commit to eclipse-emfcloud/modelserver-glsp-integration that referenced this pull request Feb 15, 2023
- Refactoring of OperationHandler type hierarchy API, see also eclipse-glsp/glsp-server#187
  - Stay with executeOperation method as we manage command stack via Model Server
  - Merge interfaces and abstract operation handler classes
- Update GLSP and Model Server dependencies

Part of #47
ndoschek added a commit to eclipse-emfcloud/modelserver-glsp-integration that referenced this pull request Feb 15, 2023
…scribing (#49)

* #48 Fix unsubscription on closing/reloading application

Until now unsubscribe was only triggered if a diagram editor was closed but not on application close/refresh.

Fixes #48

* #47 Update to latest GLSP version due to API breaks

- Refactoring of OperationHandler type hierarchy API, see also eclipse-glsp/glsp-server#187
  - Stay with executeOperation method as we manage command stack via Model Server
  - Merge interfaces and abstract operation handler classes
- Update GLSP and Model Server dependencies

Part of #47

* #43 Follow-up: Update maven settings and Jenkinsbuild

- Remove maven config and only use custom maven settings if necessary (i.e. Jenkinsbuild)
- Remove maven config and settings from project template
- Update Jenkinsbuild (do not build project-template with base framework as we have a separate build job for this)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Operation handler should be allowed to reject model modification
2 participants