analysis of carmel editor functionality

[adriatic]

• how much support for undo
• creation of a hidden state / per user, to be used for the recovery from someone who blew things apart.
• ...

[Thanood]

Undo is very easy if we use something like redux.

[adriatic]

I never had even a peek into redux - until now. It looks quite interesting and I would like to learn more about it from the pure curiosity standpoint. Can you say some more about the the store in the context carmel-ef? Is the store local (I guess so)? Since the overall state of the carmel is maintained in the database via carmel-api instance, how can that be resolved?

[Thanood]

The principle of redux can also be applied server side. If we implement a store pattern (a repository pattern is already very close) we can send an undo command to t the server.

The question remains how much undo we want to provide? If it's session based, it should be easy. Just store the state in memory. If it should live longer, we have to provide a store in database, too.

[adriatic]

I do believe that we need to implement a very specific version of undo - which really is a cousin of GitHub's PR. The user edits the tags for a specific sample for a given component (autocomplete - greeen marker 1) represented by it's state information shown below

The component itself has an array of tags, initialized to the component name (yellow marker 2), and then each sample (highlighting in this situation depicted above) has an empty array sample tags (yellow marker 3)

I believe that the application should allow each authenticated user to edit / create all any data, using a two step cascading workflow, which leaves the user who clicked on save with the impression that he changed the tags set. Actually, carmel stores user's edits in the form similar and a lot simpler that GitHub's PR - and it is up to carmel admin to do the merge and update the actual data.

This article is a repeat of already written information; I wrote this to ensure that we should not do the real undo for the users. Their edits are simple enough that could be cancelled in the case of a mistake, without a big loss. I am only suggesting that we protect the database content and integrity with this two level updates.

[adriatic]

In order to restore focus to the title of this issue, let's go back to the carmel editor editing surface proposed to look like this

GitHub has just added the support for repository content taging which is identical to what I proposed then

Click on Add topics button results with

We would choose the second item from the pull-down combo (aurelia-plugins), add the kendo-ui tag next and when reaching the proposed es6-javascript, instead of clicking on that item, keep adding the string -components, this creating the new tag (new meaning tag not existing in the dropdown combo initial data set)

Click on the Done button closes the tagging session:

A new session could be initiated by a click on the Manage topics link:

[adriatic]

Clearly, tag editor being really one-dimensional will look shabby as the only content inside the green frame (aka carmel editor surface). Luckily, we also need to support the task of adding new samples (to the existing collection of components), task that has yet to be defined.