-
|
Currently I try to integrate my Open-BPMN project - which is currently based on Theia - into VSCode. But so far I did not have success. By exploring the glsp-vscode-integration project I got the impression that it is recommanded to separte the VSCode-Integration into a isolated project. In the example/workflow there are two modules the extension and the webview. I did not understand the concept of the webview. It seems to be similar to the app module I already have in my main project which currently has the following structure So my first question to better understand the concept is: Is it correct/recommanded to separate the code with the vscode-webview in a extra project isolated from my main development? What if I would also separate the theia integration into a extra project to get something like this: I came to this question because currently I can't build the vscode-webview because of a missing peer-dependency regarding |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 3 replies
-
Theia extensions can freely contribute to both Theia's frontend and backend process so the entire glue code can be aggregated into one package ( For VS Code extensions the story is a little bit different. VS Code extensions are running as an isolated process in the VS Code backend and don't have direct access to the fronted. In the end, the webview package generates one bundled javascript file (
We cannot make a clear recommendation for either of the two approaches. Both a perfectly valid and have their pros and cons. Has the advantage that all components are interlinked e.g. you can just use the local version of Approach 2 (Splitting into dedicated sub projects): This approach is on paper the cleaner solution. All projects are clearly structured and decoupled. Unfortunately with this approach you have to take some manual action to properly link the different packages. For instance per default the Theia project is completely separated from the GLSP-client and does not know about its packages. You would need a custom process to share the packages e.g. using I personally would probably stick with approach 1.
You need an actual dependency to |
Beta Was this translation helpful? Give feedback.
-
|
@tortmayr Thanks a lot! This helps me to go further. I understand the problem now better and will first resolve my problem with the |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tortmayr, I now made some progress. After cleaning up the dependencies in my main project, things look now much better. Compiling my vscode extension is successful after I added the following additional dependencies: These were necessary because I use JsonForms with the vanilla renderer and this required at lease react ^18.2.0 But now I have still some trouble when I launch the Extension in VS-Code. My Server jar is resolved correctly (I think) but I get the following console output in VS-Code: And Diagrams can not be loaded.
I guess my problem is the file I took this from the original workflow-example vscode integration. Can you provide me some comments, so that I can better understand all the variables used here. Or is there some documentation I missed? // Wrap server with quickstart component
const workflowServer = new SocketGlspVscodeServer({
clientId: 'glsp.workflow',
clientName: 'workflow',
serverPort: JSON.parse(process.env.GLSP_SERVER_PORT || DEFAULT_SERVER_PORT)
});
// Initialize GLSP-VSCode connector with server wrapper
const glspVscodeConnector = new GlspVscodeConnector({
server: workflowServer,
logging: true
});
const customEditorProvider = vscode.window.registerCustomEditorProvider(
'workflow.glspDiagram',
new WorkflowEditorProvider(context, glspVscodeConnector),
{
webviewOptions: { retainContextWhenHidden: true },
supportsMultipleEditorsPerDocument: false
}
);
context.subscriptions.push(workflowServer, glspVscodeConnector, customEditorProvider);
workflowServer.start();
configureDefaultCommands({ extensionContext: context, connector: glspVscodeConnector, diagramPrefix: 'workflow' });
context.subscriptions.push(
vscode.commands.registerCommand('workflow.goToNextNode', () => {
glspVscodeConnector.sendActionToActiveClient(NavigateAction.create('next'));
}),
vscode.commands.registerCommand('workflow.goToPreviousNode', () => {
glspVscodeConnector.sendActionToActiveClient(NavigateAction.create('previous'));
}),
vscode.commands.registerCommand('workflow.showDocumentation', () => {
glspVscodeConnector.sendActionToActiveClient(NavigateAction.create('documentation'));
})
); |
Beta Was this translation helpful? Give feedback.
-
|
Hi @rsoika, Custom Editor ProviderThe main contribution point for GLSP is the Custom Editor API which enables us to define a custom webview-based editor a specific GLSP diagram language. SocketGlspVscodeServerThe server setup is split into two steps:
In case you missed it these concepts are also documented in the README of the
I agree, to me it looks like the server is resolved and started correctly. Unfortunatley, I have no idea what's going wrong here. |
Beta Was this translation helpful? Give feedback.
-
|
Ok thanks, I will investigate into this further... I have tested it with the GLSP Workflow example before, which of course worked. So I think it is something with my configuration. And I think |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tortmayr, I tried to read carefully all the documentation. I also checked all my configuration several times. I am also pretty sure that my I guess the parameter const customEditorProvider = vscode.window.registerCustomEditorProvider(
'bpmn-diagram',
new BPMNEditorProvider(context, glspVscodeConnector),
{
webviewOptions: { retainContextWhenHidden: true },
supportsMultipleEditorsPerDocument: false
}
);To me all looks correct so far. But I still get only a blank page in vs-code:
I can see that my Now I wonder if my export default class BPMNlowEditorProvider extends GlspEditorProvider {
diagramType = 'bpmn-diagram';
....
}(By the way, I still did not get the difference between Is it possible that in my case (no GLSP Json Model) I have to implement the methods I also published my code on github: https://github.com/imixs/open-bpmn-vscode-integration/tree/main/open-bpmn.vscode |
Beta Was this translation helpful? Give feedback.
-
|
I made again some progress. Currently the root package.json file looks like this: During compile time I see the following warning:
Can this be a possible root of my problems? |
Beta Was this translation helpful? Give feedback.
-
|
@tortmayr I need to do another debugging session first and try to solve the problem maybe by myself. Or at least I will be able to post my problem with more useful details... |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tortmayr,
And finally I needed to change the implementation of my I used the option Note the case sensitive name of |
Beta Was this translation helpful? Give feedback.
Theia extensions can freely contribute to both Theia's frontend and backend process so the entire glue code can be aggregated into one package (
open-bpmn-theiain your case).For VS Code extensions the story is a little bit different. VS Code extensions are running as an isolated process in the VS Code backend and don't have direct access to the fronted.
In order to contribute a Diagram Widget/View we have to use the VS Code Webview API. In a nutshell, a Webview is like an IFrame that is controlled by our extension and al…