More element types on server side

[tavoda]

If I understand workflow example right, on client side I have to register 'view' part for worflow components (Task, Fork, ...). Is it recommended approach?
I expected that server can have more generic component like 'Shape' send it to client and client (Eclipse, Theia, 3rd party generic GLSP client) will render it. I see some HTML support but maybe to have some generic polygon component we can achieve same with more 'pure/generic' GLSP client.
Existing approach require specific client implementation of specific grammar on client side, which break from my standpoint LSP protocol because I would like to implement standard GLSP client which will be able to cooperate with any GLSP server.
Is it planned feature or what is approach about generic GLSP client?

[planger]

Hey there!

you are right, the workflow example partly uses custom node types. But this is optional.

You can also stick to the default types. These default types are also bound by default to default view implementations, see base view module. A good overview of those default views is available in the view documentation.

As long as the server only sticks to those types, the GLSP client can be generic. And those default types and views may probably support a good part of usual diagramming needs.

However, many diagram language implementations tend to require custom view implementations to accurately represent their specific diagramming needs. For better clarity in the GModel, they also introduce custom element type IDs (instead of re-using and rebinding the default ones, line "node", "edge"), as they would clash with the default nodes (DefaultTypes.NODE) that they may also use in the same diagram.
Introducing entire custom GModel elements (like is done partly in the workflow, see TaskNode) is a rather rare case though, as the default GNode, GEdge, etc is usually sufficient, and if you need to transfer additional attributes to the client, it is easier to resort to adding generic args and take those into account in the view implementation.

The ability to customize view implementations is a key difference between GLSP and LSP, reflecting the unique requirements of graphical versus textual representations. This is because, unlike in the LSP (Language Server Protocol) where the text remains consistent across languages with only minor changes like syntax highlighting, diagramming involves more complex visual representations that vary significantly between use cases (see the gallery as an example). And even in LSP, static syntax highlighting, indentation rules, etc. are actually a client concern.

In the past years, we've discussed the possibility of a generic GLSP client from time to time, but over time didn't really pursue the idea, because it is either too limiting considering the various needs of typical modeling languages when it comes to rendering, or we would end up modeling SVG in the GModel where the server would need to compute all tiny little details, which is simpler to compute on the client based on SVG rendering available in the client anyway. Thus, it felt more practical to just make it as easy as possible to introduce custom view implementations and ship the specific servers alongside a customized client. This way, the server can focus on the diagram structure, model formats, validation rules, editing operations and other modeling logic; and the client can focus on rendering, client-side layouting (like adapting the size of an element based on its children) and other UI needed for a diagram editor.

Could you share more about what you’re aiming to achieve with your generic GLSP client implementation? Knowing more could help in providing more tailored feedback!

[tavoda]

Thanks for response. I expect that client will implement generic GLSP like LSP and will be shipped with that support. Than when you open new file type or open GLSP view over you DSL, tool will start or connect to some GLSP server and that's it. Can tools like Theia or VSCode 'plug' all necessary components (custom views) without 'recompilation' (I'm not expert on this tools)?
I don't want to build separate Theia for each DSL or GLSP server. I would like to have one tool which can support all GLSP languages and I will only install them as plugins (like Java support).
I see that default types contains also 'SVG' as type. Can I transfer SVG from server to client? That will be sufficient.

[tortmayr]

For your use case you should look at the glsp vscode integration.
This allows you to implement a GLSP editor as vscode extension. Theia's plugin support is fully compatiable with vscode extensions so you can then install those extensions in Theia as well ( like the plugin for Java support).

[tavoda]

When you can run VSCode extension inside Theia why do you have special Theia integration?

[rsoika]

Hi @tavoda , in our project Open-BPMN we implemented something in that direction.
BPMN is a kind of standard. And our client is providing the different generic detail views and property panels to model. But on the other side BPMN allows also an extension mechanism to extend elements with additional information. With the Open-BPMN Extensions we provide a way to connect the same client with different BPMN-Diagram Servers providing different capabilities.

For example a standard Task Element shows only a view properties in the properties view:

The Client is connected to the default Open-BPMN Server written in Java.

But when I start the client with a different Open-BPMN Server (like the Imixs-Open-BPMN Server written in Java) the standard elements can be extended and show now new capabilities:

And all this new properties are provided only from the server - the client did not know about this. But of course the client view need to be implemented in a very generic way, as @planger explained. For example to show custom details like the 'id' in the bottom of the task. If you need complete new elements you need a new client code that is able to visualize them. This is because of the concept behind GLSP

• the server provides only a macro-view (position, size, child elements, css classes)
• and the client knows how to render an element within the micro-view part detail

[tavoda]

Hello, I checked gallery and immediately found your project. I'm already investigating your tool. Thanks.
I see that you was able to pack it as VSCode/Theia extension. That is very interesting. As side information we are doing a lot of BPMN with Activiti engine. I will check your BPMN tools together with Imixs.