Migrate to injectable commands and views

[planger]

The API for creating commands and views has been improved in Sprotty with https://github.com/eclipse/sprotty/issues/45. This issue is to track the modifications needed in GLSP to take advantage of this new API enabling injectable commands and views.

• [X] Diagram UI extension
• [X] Tool palette
• [X] Tool manager action handler
• [ ] Model update observer registry
• [ ] TypeHintsActionHandler
• [ ] Maybe we can get rid of the self initializing action handler
• [ ] Maybe there are more (essentially we should look through all action handler initializers)

[planger]

Currently we have a bunch of action handler in GLSP that handle all sorts of actions, mostly "control"-like actions, such as showing and hiding the UI extensions, handling actions sent from the server, etc. Looking at the code a bit more and having migrated a few of them, I'm wondering whether we should actually migrate them to injectable commands after all rather than handling them in dedicated action handlers as we have now.

What do you think @tortmayr?

Having them as commands seems a bit more lightweight. However, they are also not really typical commands, as commands are sort-of designed to modify the SModel in some way, which most of our action handlers don't.

I currently tend to keep them and establish as a design guideline:

• If they modify the SModel in the widest sense, use commands
• If they just control some component in GLSP (e.g. enabling or disabling tools, showing or hiding controls, ...), have dedicated action handlers.

This way we have a clear distinction and also avoid having those commands as system commands on the command stack, etc. Let me know what you think?

[tortmayr]

As you already mentioned, most of these action handlers are not really representing a typical sprotty command ( undo-/ redoable modification of the SModel). IMHO keeping them as is and use your proposed design guidelines seems like the best option.

• Most of our actions are serving as some control concept or are used to initialize services. These actions should either be handled by the diagram server or dedicated action handlers. We introduced the SelfInitializingActionHandler class recently to simplify this process.
• In the context of GLSP the only actions that can trigger a model modifcation are actions related to visual feedback. So we could introduce a FeedbackCommand class that can be used for these actions. A feeback command should be a system command with no-op undo/redo functions

[planger]

Agreed, let's close this issue then.