General Question about Property Editor integration

[rsoika]

Hi,
I have a more general conceptual question about Property editing. Currently I try to adapt the JSONForms property-view to provide additional editor section for graphical elements. I run into some trouble with dependencies conflicts which brings me to a new thought:

If I do things like integrating the @eclipse-emfcloud/jsonforms-property-view which depends on theia or even if I extend the @theia/getting-started module, then I will loose the possibility to run my modeller in VS-Code or Eclipse - is this right?
The platform independence is for me one of the biggest advantages of GLSP.

From this point I ask myself if it would not be better and easier to integrate an extended editor panel into the modelling panel similar to the ToolPalette? Than I expect my modeller will work identically in VS-Code and in Theia? In some examples I have seen that property editing was realized in pop-ups which seems a similar concept.

The only problem will be that in my case - BPMN modelling - an element can have many properties which results in complex editor panels.......

What are your thoughts about integrating property editing completely into the modelling pane and avoiding to much dependencies to 'proprietary' concepts from Theia?

[planger]

Hi,

If I do things like integrating the @eclipse-emfcloud/jsonforms-property-view which depends on theia or even if I extend the @theia/getting-started module, then I will loose the possibility to run my modeller in VS-Code or Eclipse - is this right?
The platform independence is for me one of the biggest advantages of GLSP.

Yes, sort of... those parts are specific to Theia, so you won't be able to use them in VS Code or Eclipse. However, the diagram implementation itself -- ie your implementations that only depend on glsp-client -- will of course still be usable in VS Code and Eclipse, independently of whether you added additional things for Theia, if your packages are structured accordingly.
The typical structure is to separate your diagram implementation in a platform-independent GLSP client package (e.g. minimal-glsp) and separate packages that deal with the respective platform integrations.

From this point I ask myself if it would not be better and easier to integrate an extended editor panel into the modelling panel similar to the ToolPalette?

Sure, this is a very valid consideration but there is no generic answer, as this really depends on the requirements and what you want to achieve. To keep the effort to a minimum and equally support all platforms, you can avoid using external views and do everything with UI extensions in the diagram pane itself. This way it'll be usable with minimal extra effort in VS Code, Theia and Eclipse. Of course, this may have downsides with respect to the user experience and you'll not be able to use the benefits of the respective platform integrations, such as external property views or synced tree views.

Than I expect my modeller will work identically in VS-Code and in Theia? In some examples I have seen that property editing was realized in pop-ups which seems a similar concept.

Correct.

What are your thoughts about integrating property editing completely into the modelling pane and avoiding to much dependencies to 'proprietary' concepts from Theia?

As mentioned above, this really depends on your requirements and target audience. Eventually it is a compromise between user experience and development effort. Several adopters of GLSP have one main target tool platform and optimize the user experience for that target platform, but make sure that the platform-independent diagram implementation can be used on other platforms as well, so that later if another platform support is required, the platform-independent diagram implementation can be reused 100% and only the platform-specific integration can be added with reasonable effort.

I think, user experience is really the main driver here, because on different platforms users may also expect a different UX (compare for instance Eclipse and VS Code)... if the diagram editor has UI elements in the diagram pane for property editing that look like and behave like VSCode, it might be unexpected for an Eclipse user within Eclipse and vice versa.
Also users may expect certain platform integrations, such as that commands for your diagram show up in the quick command palette (Ctrl-P in VS Code or Ctrl-3 in Eclipse), which requires platform-specific integration code.

Anyway, if you treat all target platforms equally and don't want to spend the additional effort, it is imho still a valid choice to try maximize the common code, also if it comes with limitations for the user experience.