We should provide an API to provide common customization of the detail form.
At least JsonForm's renderers should be configurable to allow easy usage of custom renderers.
The detail config should be configurable by dependency injection.

The TreeEditor.ModelService methods are currently synchronous with fixed type results.
As a consequence, it is currently impossible to implement it by relying on the @eclipse-emfcloud/modelserver-theia ModelServerClient which returns a Promise object to get type schema and the UI schema.

To allow asynchronous usage, it would be nice to change methods return types to MaybePromise (from @theia/core).
For example getSchemaForNode(node: TreeEditor.Node) : JsonSchema | undefined
would become getSchemaForNode(node: TreeEditor.Node) : MaybePromise<JsonSchema> | undefined

This way, previous implementations would still be compatible with the new interface, but implementations can also work in an asynchronous way.

The drawback is that all callers of these methods must then handle the asynchronous behavior.
So I'm not sure it is feasible everywhere... especially when looking at AddCommandHandler#isVisible(treeAnchor: TreeAnchor) method which use the modelService and itself implement the CommandHandler interface from @theia/core
(and we could legitimately expect getChildrenMapping to have and asynchronous implementation)

We should use "Eclipse emf.cloud Project" as the generic stand-in for all committers and contributors in all poms and package.jsons to avoid having to manually maintain it.
E-mail address: https://accounts.eclipse.org/mailing-list/emfcloud-dev
Web-site the project page: https://projects.eclipse.org/projects/ecd.emfcloud

For details see the discussion in eclipse-glsp/glsp#246

Hi,

the following issue appears if a tree contains two nodes with the same name provided by the corresponding label provider:
Of the two nodes, first select the one that is below the other one in the tree. Then change some property of this node in the details view. Notice that the other node is now being selected.

Root cause is that the node retrieval for the last selection is based on the name. Say if there are two nodes named 'Test', doing a modification of the first node leads to the selection of the other 'Test' node (as that was the name of the previously selected node).

Instead, maybe we could pass the name of something like a 'identity' property to the MasterTreeWidget (see select method for the node determination). Then adopters could e.g. ensure a stable ID is created (in their TreeEditor.NodeFactory, e.g. based on the '@id' property) such that the ID is used instead of the name. This would ensure selections are retained even if nodes with the same name are existing.

The behavior is reproducible with the coffee example. (E.g. rename the Push node to Drink and then adapt the duration in the details view - the selection will switch to the node above with the same name).

What do you think?

Greetings,
Alex

Currently, JSONForms is a hard dependency to a specific version.
We want to use it as a peer dependency to allow adopters choosing the version. E.g. this allows adopters to use the latest version without a new tree editor release.

Trying to run the tree editor using Yeoman. I've had success with the other Theia extension examples, but this one shows the following error in the console for both the web and electron. It seems to build fine oddly, but I only get the spinning progress indicator and this error in the console:

index.js:70 Error: Cannot find module '@jsonforms/react'
    at webpackMissingModule (detail-form-widget.tsx:12:1)
    at ../node_modules/@eclipse-emfcloud/theia-tree-editor/lib/browser/detail-form-widget.js (detail-form-widget.tsx:12:1)
    at __webpack_require__ (bootstrap:19:1)
    at ../node_modules/@eclipse-emfcloud/theia-tree-editor/lib/browser/index.js (index.ts:11:1)
    at __webpack_require__ (bootstrap:19:1)
    at ../tree-editor/lib/browser/tree/tree-editor-widget.js (tree-editor-widget.ts:6:1)
    at __webpack_require__ (bootstrap:19:1)
    at ../tree-editor/lib/browser/tree-contribution.js (tree-contribution.ts:6:1)
    at __webpack_require__ (bootstrap:19:1)
    at ../tree-editor/lib/browser/tree-editor-frontend-module.js (tree-editor-frontend-module.ts:9:1)

edit: the above issue is not happening when I clone this repo and run the example. Odd.

Also, I wanted to thank you for this repo - it's a great example of how to build an interesting editor that, frankly, I found to be a challenge in vscode. Unfortunately, until I came upon your brilliant documentation on creating a custom editor here in this repo, along with the example, I was really struggling. I was under the impression that what made Theia different and better than vscode was mostly about custom editors - yet I couldn't find one document on how to implement them.... so thanks again.

Currently, there are some use cases that should be generalized if the tree editor is used in combination with emfcloud-modelserver (e.g. creating json diff commands, see also eclipse-emfcloud/emfcloud-modelserver-theia#51).

As example, the jsonforms-property-view also provides such a dedicated Model Server aware package already.

Goal

Add drag and drop support to the tree editor. Drag and drop should allow to move tree nodes to other suitable positions in the tree.

Initial investigation

There is no Theia API for drag and drop in tree widgets. This means D&D needs to be implemented from scratch using the HTML5 API or any react dnd framework. For instance, Theia's FileTreeWidget uses native HTML5 D&D.

With this come all kinds of cases that we'd need to handle:

Tree nodes can can be draggables, containers for dropped nodes and siblings of dropped nodes at the same time
How to differentiate whether we want to drop a node A next to a node B (sibling) or inside B (container) if both is possible?
How to handle a target container having two properties which can take the dropped node? Open dialog?
Need to determine whether a node can be dropped into a target node -> With the model service we shoud have all required information to determine this.
How to handle re-ordering nodes in a parent if there are multiple properties containing children?
Need to implement the actual move of the node and its data in the tree or tree model. This is not provided by Theia's default TreeWidget or TreeModel. The file tree implements this in FileTreeModel.
In conclusion, implementing full fledged drag and drop for moving nodes (and the associated data) in the tree, is not a trivial endeavor. My rough estimation is this will take around 3 to 5 days to implement.

If using react-dnd, first starting points for an implementation can be gotten from https://github.com/eclipsesource/jsonforms-react-material-tree-renderer/blob/master/src/tree/ObjectListItem.tsx.
However, this likely still needs significant adaption to be properly integrated into Theia and fix potential short comings of the past implementation.

I'm trying to build the tree viewer based on schema and ui-schema that are on the filesystem, but I seem to have to define the children and typeIds in code

allow for getChildrenMapping to be called when the model service is constructed

I'm not really sure how to solve this problem

Support Theia Community Release 1.29.x (see https://theia-ide.org/releases/)
Ensure compatibility and publish a tested version
Add to Compatible Technologies section on Theia website

If the tree's data is changed in another editor while the tree editor is open and then the tree editor is focused again, it doesn't automatically refresh it's content.
The question is whether this should be generally handled in the tree editor or framework or should be handled by client implementations if it is possible there.

The problem with a general implementation is that we don't know how exactly the data is loaded and how it might be changed in the background.

• Update to Theia 1.18.0 and ES2017
  • With this version, FontAwesome icons were replaced with @vscode/codicons
  • Replace custom/FontAwesome icons with Codicons (e.g. fa fa-project-diagram with codicon codicon-type-hierarchy-sub)
  • Replace FontAwesome CSS classes

We should add a simple small theia application which we can use for developing and testing

In detail-form-widget.tsx, the redux variant of JsonForms is still used. This should be changed to use the redux-free version.

The tree widget should be properly usable without the rest of the editor (i.e. the detail view).

• Tree widget needs to be exported (likely already the case but needs to be verified)
• Tree widget needs to be configurable without the rest of the editor
• Tree widget needs to be configurable to not try to show something in the detail
• Potentially new utility method to create tree widget DI container without editor and detail.

Description

The typo Containter should be fixed in the extension:

Documentation Update

The fix would be to update Containter to Container.

Additional Information:

• I noticed the issue when reviewing the tree-editor example from the generator-theia-extension#tree-editor template.

Observation: Flash is re-coloring of the editor's title tab. The tab's title color is changed from white to grey as long as a context menu is open.

Theory: Right-click tries to open a context menu that is closed immediately again because it is empty. In the mean time between trying to show the context menu and realizing that it'll be empty, the tab header changes color. Hence, it seems like a "flash".

• Understandability
• Correct description of all necessary services to implement and register
• Import of stylesheets
• Potentially more

I suggest the following two improvements to increase usability for the tree-editor:

• The split panel handle between tree and form editor should be visible by styling one editor panel with a different background color to indicate the existence of the split panel handle (as it is commonly used in the whole Theia application).
• Input fields in the form editor using the light theme are not visible, this should be styled similar to the Theia base styling for input fields.

Missing input field visibility in light theme:

Compared to dark theme:

Currently the vanilla renderers are used by the tree, this might not always be what the user wants.
In order to minimize the size and not have conflicting renderers the vanilla set must be made optional.

Currently, Theia's autosave preference is ignored by the tree editor widgets. The ResourceTreeEditorWidget should respect this flag. More abstract tree editor widgets don't need to handle this as they are used for more custom implementations that might want to use different behavior.

Currently, simply an empty tree is shown with no possibility to add any nodes. This could be handled by showing an error message instead.

Currently we depend on React 16 but Theia is already using React 18. We should thus update

I'm coming from here.

The save operation was easy to implement since my widget implements NavigatableTreeEditorWidget and hence the Saveable interface.

I would expect to have a similar mechanism in my widget to implement the logic for undo/redo, However I could not find any reference to undo or redo on the @eclipse-emfcloud/theia-tree-editor module.

Kind regards