UI for editing Concepts

Development
1

In the legacy UI we have a concept edit page, which allows to add/remove/edit concept names and then save all changes. On the server side we need to iterate though all concept names and compare them with those stored in database to determine, which ones were modified/added/removed by the user and persist changes.

In the new UI, which uses REST, we cannot simply update a concept resource by sending a concept with names. We must do separate REST calls to update each name if modified by the user.

The question is how to best handle updating names via REST. I see 3 options:

  1. We add a feature to the REST api, which allows to update a collection of names passed with a concept. -OR-
  2. We change the edit concepts page so that each edited name is confirmed by the user and is sent right away to the server in a separate ajax call. -OR-
  3. Javascript tracks which names have been added/removed/edited and sends multiple REST requests to the server when the user saves the concept.

I’d choose 1). What is your preference?

2

I like 3) but with a single REST after each inserted/updated/deleted name (a mix of 2 and 3).

I don’t like 1) because it doesn’t fit well in the current REST API architecture. Think about all the UIs yet to be developed, it will lead to an explosion of REST API methods. IMHO the REST API must be equivalent (o very similar) to the Service Layer, and NOT a facade for the UI. But still, I think a facade is needed (don’t know if in JS or in a Controller).

3

If 2) does not complicate the interface for the end user, i would go for it. :smile:

4

I choose 1) because I think editing names should be thought of as a single transaction (may be not a big deal in this case but I like to imagine one would want to specify full & short names at one go)

5

I agree that you may need to edit multiple names at once to end up in a valid and desired state.

Another thought is whether we should add a REST endpoint that lets you include multiple changes and makes them in a single transaction.

-Darius (by phone)

6

I agree that (1) has the advantage of a single transaction, but I doubt is relevant in this context.

7

By the way using a single request fits well with current REST API because concept names are sub resources of Concepts which means you can POST an array of names in a payload using a concept endpoint as shown below.

POST /ws/rest/v1/concept/{conceptUuid}

{
     "names":[ {
        "name": "some name",
        "uuid": "uuid of the name"
     }, {
      // Some other name
    }
 ]
}

I haven’t tested this but I think it should work because I have been doing a similar thing with person and person attributes.

8

2.) would be ideal, if it does not complicate user behavior and it seems confirmation prompt for each name will make things tedious. So I vote for 3.)