Add JSON UI and optional sort for metadata widget

[ajbozarth]

Fixes #851

Adds a default JSON viewer to the MetadataWidget and adds an optional sort which default to alphabetical by display name.

Developer's Certificate of Origin 1.1

   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

[ajbozarth]

[ajbozarth]

I moved the new react component into the ui-components package and cleaned it up a bit. This should be ready for review now

[ptitzler]

I guess I'm missing something. The tab doesn't show up after I ran make clean install on your branch. Is it supposed to be there?

[ajbozarth]

You have to open it via the Command Palette tab, it is not enabled by default

[ptitzler]

• Command/Ctrl Shift C
• Elyra > Show Runtime Images

So I don't have to look it up again (:

[ptitzler]

Very convenient to have as an interim solution for generic metadata!

Three thoughts (I realize the last two might be not specific to this PR but since you are already touching the metadata widget ...):

• Is there a need to display the metadata node? If it doesn't serve an purpose and we would only ever display child properties of metadata (which seems to be the case for runtime images) there shouldn't be a need for it.
  

• Could the widget automatically sort the metadata entries by name? As the list of entries grows it gets harder and harder to find the entry ...
  

• We distinguish between user-defined and system-defined metadata. In above screen capture only the last one is user-defined metadata. As a user I can only delete user-defined metadata. Trying to delete a system-defined metadata an error is raised. Could we hide the delete icon for system-defined entries that cannot be deleted?

[ajbozarth]

• Is there a need to display the metadata node? If it doesn't serve an purpose and we would only ever display child properties of metadata (which seems to be the case for runtime images) there shouldn't be a need for it.

This was a side effect of how the JSON Component was written. I can play with it some and see if I can show only the contents of a node without showing a parent. (should be possible)

• Could the widget automatically sort the metadata entries by name? As the list of entries grows it gets harder and harder to find the entry ...

Actually having an optional sort that defaults to alpha when enable and can be overridden would be a good feature, I can tack it in here if it seems straight forward to add (otherwise I'll open another issue and pr to do it).

We distinguish between user-defined and system-defined metadata. In above screen capture only the last one is user-defined metadata. As a user I can only delete user-defined metadata. Trying to delete a system-defined metadata an error is raised. Could we hide the delete icon for system-defined entries that cannot be deleted?

I actually discussed this some with @kevin-bates a while ago and currently the api doesn't distinguish whether metadata is user-defined or system-defined until you call the delete api. I believe a "fix" for this on either the front or back ends would be overly complicated and messy for little benefit. Especially because you can "edit" a default to override it, at which point you could delete that edited version.

[kevin-bates]

We distinguish between user-defined and system-defined metadata. In above screen capture only the last one is user-defined metadata. As a user I can only delete user-defined metadata. Trying to delete a system-defined metadata an error is raised. Could we hide the delete icon for system-defined entries that cannot be deleted?

Only the server distinguishes between user and system-define metadata instances. We would need to add a meta-property to indicate this - probably something like a boolean-valued system_owned would be sufficient.

However, because we allow system-owned instances to be modified and essentially become user-defined instances - which can be deleted - then things get very confusing. For example, if we were to set the system_owned meta-property to False when a user "updates" a system-owned instance, then the UI would show a delete icon and allow its deletion. But, upon its deletion, the actual system-owned instance - of the same name - reappears and, this time, without a delete icon.

As a result, I'd be inclined to a) add a system-owned meta-property where necessary (i.e., schemas that can span the user/system domain), and b) disallow updates to system-owned instances. This would mean that a user wishing to "update" a system-owned instance would be required to create a new instance with a different name containing the updated properties.

[ptitzler]

then things get very confusing.

Yep, I noticed that:

• edit a system-defined metadata entry (OK)
• delete the same entry (which is now a user-defined entry, OK)
• but an entry is still visible, which is (again) a system-defined, which cannot be deleted (FAIL)

This would mean that a user wishing to "update" a system-owned instance would be required to create a new instance with a different name containing the updated properties.

For the sake of simplicity that's the option I would favor, even though a case could be made to not restrict editing/deletion of system-defined metadata at all. (Ignoring for now that a user can already do that by manually accessing the file system with the appropriate permissions.)

[ajbozarth]

I pushed a couple commits addressing @ptitzler commit's. I updated the display to not show the "root" node and just the json contents. I also added an optional default alphabetical sorting based on display_name for MetadataWidget, which I disabled in CodeSnippetWidget but enabled for RuntimesWidget. Is alphabetical sorting something we would like for the Runtimes tab? Would we want to add it to Code Snippets?

New screenshot:

[ptitzler]

Thank you Alex!

I do believe all lists should be sorted by default using a criteria that enables the user to quickly find relevant information for the majority of use case scenarios. A system-sorted order (whatever that means specifically as to how the sort order is implemented explicitly) shouldn't be used unless it provides a clear advantage. Let's assume (dunno if that is the case) the current system-sort order for the metadata widgets is "by change date [of the underlying file], descending". Does the user derive any benefits from having the list presented in that order? How would the criteria help the user find the appropriate entry faster compared to an alphabetically sorted list?

Example: You are looking for an entry uvw
You see a partial list and need to scroll/page down multiple times to see all the entries.

• abc
• def
• ghi

Most likely you would assume that this list is ordered alphabetically (given the implicit hint) and jump to the bottom of the list instead (or close to it) instead of moving lower just a little bit to view the next couple entries. With system sorted order you can't do that without having explicit knowledge about that order. You also have to know the "actual sort value" or at least how it compares to the value of other entries. ("The runtime image definition I am looking for was changed 12 days ago, but where does that put the entry in the list if I don't know when other definitions were last updated?")

[ptitzler]

Not sure why but when you create a metadata entry or open an existing one for editing the first input field is no longer selected by default. I remember you had this fixed in another PR ...
Other than that this PR works for me as expected.

[kevin-bates]

Regarding sorting, I agree that we should have a consistent message regarding sorting - with the default being that items are sorted by display_name. Code snippets, however, should be grouped by language, then sorted by display_name, with the groupings sorted by language.

I don't know what the implementation of the Code Snippets list widget (not sure that's the correct term) is, but we could probably introduce a meta-property to the schemas named something like group_by. This would be an optional string-valued meta-property (i.e., resides outside the metadata stanza). For Code Snippets, it would have a value of language. Applications processing these instances would know to first group Code Snippets instances by language, then sort them by display_name within a grouping. Schemas that do not use group_by, always sort by display_name.

The same rules should apply to the CLI tooling as well.

[ajbozarth]

Based on the conversation above I updated to also sort code snippets using the method Kevin described

[karlaspuldaro]

Tested this locally and looks good :)

[marthacryan]

Just tested locally and LGTM!

[lresende]

I have updated the license to reflect the info above.

[lresende]

LGTM