eclipse-glsp/glsp-server

Java-based server framework of the graphical language server platform

glsp-server's Issues

Add GModelIdAdapter

Add a reusable Adapter implementation that attaches an generated (GModelId) to an EObject.
We already use a similar approach in a couple of projects so extracting a common reusable component should be easy

Revise ActionProcessor /ActionHandlerAPI

https://spectrum.chat/glsp/general/custom-actions-in-glsp~d87a08b3-c94b-467e-802a-601e2f6ae2ef?m=MTU3NDE2NTQ3Nzk3Nw==

Setup initial Jenkins CI Integration

Should build every PR and report back to Github.
Deploy step should only be initiated on master (can be mocked for now, actual deploy will be handled in a follow up issue)

Find a better mechanism to define the dirty-state of the model

In the fix for #36 we mark a model as dirty as soon as an executeOperation_* is sent to the server. However, this is not a very reliable mechanism. Without having thought this through entirely, imho, the server needs to decide whether a model is dirty or not; eventually, the server decides which action is actually performed or not, isn't it?

[migrated from https://github.com/eclipsesource/graphical-lsp/issues/62]

OperationActionHandler makes it hard to add custom operation action handlers

Currently, the OperationActionHandler handles operation actions in the following way:

@Override
public Optional<Action> execute(Action action, GraphicalModelState modelState) {
	switch (action.getKind()) {
	case Action.Kind.CREATE_NODE_OPERATION:
	case Action.Kind.CREATE_CONNECTION_OPERATION:
	case Action.Kind.RECONNECT_CONNECTION_OPERATION:
	case Action.Kind.REROUTE_CONNECTION_OPERATION:
	case Action.Kind.DELETE_ELEMENT_OPERATION:
	case Action.Kind.CHANGE_BOUNDS_OPERATION:
	case Action.Kind.APPLY_LABEL_EDIT_OPERATION:
		return doHandle((AbstractOperationAction) action, modelState);
	default:
		return Optional.empty();
	}
}

That means, if users would like to add custom operation actions, they'll have to overwrite the OperationActionHandler and add their new action kind in the check above. This is unexpected and also unnecessary. We could do the following instead:

@Override
public Optional<Action> execute(final Action action, final GraphicalModelState modelState)  {
  if (action instanceof AbstractOperationAction && operationHandlerProvider.isHandled((AbstractOperationAction)action)) {
      return doHandle((AbstractOperationAction)action, modelState);
  }
  return Optional.empty();
}

Order of command palette entries can't be controlled from the server

Since we are using hash sets, the order of items in the command palette sent from the server to the client is random, which not only prevents the server from defining a certain order, but also lets the order be different everytime the client requests a new set of elements.

Improve registration of action provider

I'd find it more convenient to register actions as a collection of classes instead of injecting a provider class, similar to how we register action handlers. If an implementer wants to customize the available actions, it needs to copy the entire list of actions instead of being able to get the default ones and remove the ones it needs and adding the additional ones.

For handlers, we can do it as follows:

final Collection<Class<? extends ActionHandler>> defaultHandlers = super.bindActionHandlers();
// remove bindings that we are about to overwrite or don't need
defaultHandlers.remove(OperationActionHandler.class);
defaultHandlers.remove(SaveModelActionHandler.class);
defaultHandlers.remove(UndoRedoActionHandler.class);
// custom handlers
defaultHandlers.add(MyOperationActionHandler.class);

For actions, we need to create a class that returns a list instead.

Add CI snapshot deployment