Separation of concerns for the GLSPDiagramServer.
#900
Comments
tortmayr
added a commit
to eclipse-glsp/glsp-client
that referenced
this issue
Feb 5, 2023
- Deprecates the `GLSPDiagramServer` model source and introduces a new `GLSPModelSource`. In contrast to the `GLSPDiagramServer` the new model source is only responsible for sending actions to and receiving actions for the GLSP server. It no longer serves as dedicated action handler. In addition, to a cleaner separation of concerns this also enables using a gernic `ModelSource` for all platform integrations i.e. we no longer have the separation between `GLSPDiagramServer´ and `GLSPTheiaDiagramServer` - Deprecates the `SourceUriAware` interface - Introduce dedicated action handlers for `ExportSvgAction`, `ServerMessageAction` and `ServerStatusAction` - Add a fallback dirty state action handler for the standalone example - Extend the `createContainer` function of the workflowDiagram so that it takes additional customModules as rest parameter Part of eclipse-glsp/glsp#900
tortmayr
added a commit
to eclipse-glsp/glsp-client
that referenced
this issue
Feb 5, 2023
- Deprecates the `GLSPDiagramServer` model source and introduces a new `GLSPModelSource`. In contrast to the `GLSPDiagramServer` the new model source is only responsible for sending actions to and receiving actions for the GLSP server. It no longer serves as dedicated action handler. In addition, to a cleaner separation of concerns this also enables using a gernic `ModelSource` for all platform integrations i.e. we no longer have the separation between `GLSPDiagramServer´ and `GLSPTheiaDiagramServer` - Deprecates the `SourceUriAware` interface - Introduce dedicated action handlers for `ExportSvgAction`, `ServerMessageAction` and `ServerStatusAction` - Add a fallback dirty state action handler for the standalone example - Extend the `createContainer` function of the workflowDiagram so that it takes additional customModules as rest parameter Part of eclipse-glsp/glsp#900
tortmayr
added a commit
to eclipse-glsp/glsp-client
that referenced
this issue
Mar 4, 2023
- Deprecate the `GLSPDiagramServer` model source and introduce a new `GLSPModelSource`. In contrast to the `GLSPDiagramServer` the new model source is only responsible for sending actions to and receiving actions for the GLSP server. It no longer serves as dedicated action handler. In addition, to a cleaner separation of concerns this also enables using a generic `ModelSource` for all platform integrations i.e. we no longer have the separation between `GLSPDiagramServer´ and `GLSPTheiaDiagramServer` - Deprecate the `SourceUriAware` interface - Introduce dedicated action handlers for `ExportSvgAction`, `ServerMessageAction` and `ServerStatusAction` - Add a fallback dirty state action handler for the standalone example - Extend the `createContainer` function of the workflowDiagram so that it takes additional customModules as rest parameter Part of eclipse-glsp/glsp#900
tortmayr
added a commit
to eclipse-glsp/glsp-theia-integration
that referenced
this issue
Mar 16, 2023
Part of eclipse-glsp/glsp#900
tortmayr
added a commit
to eclipse-glsp/glsp-client
that referenced
this issue
Jul 7, 2023
- Deprecate the `GLSPDiagramServer` model source and introduce a new `GLSPModelSource`. In contrast to the `GLSPDiagramServer` the new model source is only responsible for sending actions to and receiving actions for the GLSP server. It no longer serves as dedicated action handler. In addition, to a cleaner separation of concerns this also enables using a generic `ModelSource` for all platform integrations i.e. we no longer have the separation between `GLSPDiagramServer´ and `GLSPTheiaDiagramServer` - Deprecate the `SourceUriAware` interface - Introduce dedicated action handlers for `ExportSvgAction`, `ServerMessageAction` and `ServerStatusAction` - Add a fallback dirty state action handler for the standalone example - Extend the `createContainer` function of the workflowDiagram so that it takes additional customModules as rest parameter Part of eclipse-glsp/glsp#900
tortmayr
added a commit
to eclipse-glsp/glsp-theia-integration
that referenced
this issue
Jul 30, 2023
Switch to new `GLSPModelSource` Instead of `TheiaGLSPDiagramServer´. With this migration we also remove the concept of the `TheiaGLSPConnector`. It is no longe needed since all diagram containers are child containers of the Theia main container and have direct access to all Theia services. Refactors theia specifc GLSP customiizations/extensions into feature modules similar to how we handle it for the standalone usecase. This appraoch is now possible because the diagram container is a real child container of the Theia main container which means we have access to all Theia services. This includes - Refactoring/Renaming of the `SaveableGLSPModelSource` to`GLSPSaveable`. The saveable implementation listens to the `onDirtyStateChanged` event from the diagram `EditorContextService` - Move Theia export svg functionality from connector to dedicated `theiaExportModule` - Move forwarding to Theia selection service into dedicated `theiaSelectModule` - Move the Theia source model changed handler into dediacted `theiaSourceModelWatcherModule` - Move handling of external navigation targets into dedicated `theiaNavigationModule` - Load the Theia default feature modules in the `GLSPTheiaDiagramConfiguration` - Move server message & process handling into dedicated `notificationModule` -- Remove `GlspNotificationManager` customization as its no longer needed Another advantage of moving those bindings directly into the child contain is the multi-editor support (i.e. multiple registered GLSP editors in one instance). Previously lots of the services (like TheiaSourceModelChangedHandler) would be shared between editor implementations. Now each implementation maintains its own set of services and can customize/rebind them as needed. Fixes eclipse-glsp/glsp#849 Part of eclipse-glsp/glsp#900 Part of eclipse-glsp/glsp/issues/850 Requires eclipse-glsp/glsp-client#272
tortmayr
added a commit
to eclipse-glsp/glsp-theia-integration
that referenced
this issue
Aug 8, 2023
* GLSP-849: Remove theia-glsp-connector Switch to new `GLSPModelSource` Instead of `TheiaGLSPDiagramServer´. With this migration we also remove the concept of the `TheiaGLSPConnector`. It is no longe needed since all diagram containers are child containers of the Theia main container and have direct access to all Theia services. Refactors theia specifc GLSP customiizations/extensions into feature modules similar to how we handle it for the standalone usecase. This appraoch is now possible because the diagram container is a real child container of the Theia main container which means we have access to all Theia services. This includes - Refactoring/Renaming of the `SaveableGLSPModelSource` to`GLSPSaveable`. The saveable implementation listens to the `onDirtyStateChanged` event from the diagram `EditorContextService` - Move Theia export svg functionality from connector to dedicated `theiaExportModule` - Move forwarding to Theia selection service into dedicated `theiaSelectModule` - Move the Theia source model changed handler into dediacted `theiaSourceModelWatcherModule` - Move handling of external navigation targets into dedicated `theiaNavigationModule` - Load the Theia default feature modules in the `GLSPTheiaDiagramConfiguration` - Move server message & process handling into dedicated `notificationModule` -- Remove `GlspNotificationManager` customization as its no longer needed Another advantage of moving those bindings directly into the child contain is the multi-editor support (i.e. multiple registered GLSP editors in one instance). Previously lots of the services (like TheiaSourceModelChangedHandler) would be shared between editor implementations. Now each implementation maintains its own set of services and can customize/rebind them as needed. Fixes eclipse-glsp/glsp#849 Part of eclipse-glsp/glsp#900 Part of eclipse-glsp/glsp/issues/850 Requires eclipse-glsp/glsp-client#272
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The main responsibility of the DiagramServer class is dispatching of action messages received from the server and sending action to the server. However, at the moment it is also used to intercept some of the dispatched actions and handles them locally. This means the
GLSPDiagramServeris currently also an action handler god class. In addition, it might break the action flow. e.g. the DiagramServer could intercept and action from the server and not forward it to the local action dispatcher. As a consequence any other registered handler would never receive this message.=> Move action handling into designated handlers.
GLSPDiagramServershould be like the counterpart of theClientActionsHandleron the server side and nothing more.The text was updated successfully, but these errors were encountered: