EDIT

The issue about the nameUsedInSource seems to be a problem of the parser, at the beginning of the parsing all elements are set to null (in makeEmpty(INonViralName name)), if the string can not be parsed, author and nomenclatural reference and nameUsedInSource are still empty and will be saved like this.

Katja Luther wrote in #note-2:

The issue about the nameUsedInSource seems to be a problem of the parser, at the beginning of the parsing all elements are set to null (in makeEmpty(INonViralName name)), if the string can not be parsed, author and nomenclatural reference and nameUsedInSource are still empty and will be saved like this.

No, this is not the issue here. Fully emptying the name before parsing is wanted behavior.

The problem is the way how the TaxEditor refreshes the DetailsView after changes in the freetext area. The details view is only updated after the freetext record lost focus. This is partly wanted as we do not want to run parsing after each text change as parsing (and related deduplication) is a costly serverside function.
However, what is needed here is to not allow editing the details view after changes have been done in the freetext area and the focus is still on the record that has been changed .

In concrete, what happened here is, that originally the name had a protected namecache and this information still existed in the details view representation. Therefore changing the nom.source+original name had no effect in the freetext area.

This is probably fixed but not yet commited.

this should be fixed, please review.

Can you please check this in detail.

Andreas Müller wrote in #note-16:

As far as I can see the event throwing not happens additionally to the event thrown by selection change. We need to check if this results in a duplicated details view building or if the second build is filtered out somehow. Additionally the REFRESH_DETAILS line seems to be called 2x so maybe alltogehter DetailsView is build 3x. This needs to be checked before going to production therefore I reverted this line (94fccb8a).

This problem appears if the selected view is for example the empty media view, but not if the selection changes to the details or supplemental data view.

This needs to be reverted or adapted. Currently the detail view very often refreshes. This happens also in many cases when it is not necessary.

E.g.

• changing focus to other synonym in TaxonEditor refreshes the DetailsView 2x(!), first with the old data, then with the new data
• changing to focus from synonym to details view or supplementalDataView refreshes the DetailsView if if no data has changed (no parsing) which is not necessary
• changing back from DetailsView or SupplementalDataView to Taxon Editor again refreshes the DetailsView although not necessary

This really slows the TaxEditor in its core functionality.
The reason for the behavior is the above mentioned conceptual mistake.
It does not make sense to refresh DetailsView for any data that looses the focus! You need to refresh the View once you know what the new focus is.

So the general rule should be:

• Keep everything as in previous versions
• ONLY if the details view gets the focus AND if a name in the TaxEditor had the focus before AND if the name has been parsed due to changes in freetext THEN refresh the DetailsView.

The new solution disables the details view after editing the name in name editor, editing the other names/taxon/synonyms still possible and after loosing the focus and get it back to the edited name, the details are enabled again because they are refreshed. Please have a look whether this is a better solution.

Katja Luther wrote in #note-21:

The new solution disables the details view after editing the name in name editor, editing the other names/taxon/synonyms still possible and after loosing the focus and get it back to the edited name, the details are enabled again because they are refreshed. Please have a look whether this is a better solution.

It is much better now. There are just a few improvements that could make work even more comfortable. Currently the disabling is not yet removed in many cases but it should. E.g. clicking on FactualData View, Media View or SupplementalData View and maybe others should also enable (and recompute) the DetailsView again. Also clicking on the DetailsView itself I would expect reenables the DetailsView and immediately recomputes it but I don't know how far this is easy to implement.

Andreas Müller wrote in #note-24:

Katja Luther wrote in #note-22:

I just tried out another implementation: now the detailsviewer just remember that there are changes in Name Editor and if it gets the focus the details view refreshes. If there are no changes, the details view is not updated.

This sounds like the best solution if it works as described.

I tested a bit and it works fully correct. There are only 3 minor issues that might be discussed.

1. If I go to the DetailsView (after freetext change) it updates which is correct, if I go back to the freetext it updates again which is not necessary - hmm, tested and this is also the case without freetext change. So maybe it is another ticket, but if it is easy to fix we may do it now

2. if clicking on the Fact, Media or SupplView the Details View does not refresh though there was change via freetext. One may discuss that this is wanted behavior as refresh slows down performance but IMO we should refresh as fast as possible once parsing was done.

3. I did like the disabling to indicate that data is not valid anymore so can we keep the disabling and simply do enabling when the view is refreshed.

All these 3 are minor issues and should be implemented in current version only if they are no-brainers and not dangerous to brake anything.

Katja Luther wrote in #note-26:

This is like it was before, I think there is already a ticket about it. (for example #6554, but this is not for this concrete issue)

OK, so if it is not straight forward to implement we leave it for later but we should check if there is really a ticket for it (#6554 is about something else). It is actually true for the supplemental data view, too, that it often reloads though the data to show is the same. I wonder about this because at other places we check if the input is the same and do not recompute. Do you know where in the code this happens?

1. if clicking on the Fact, Media or SupplView the Details View does not refresh though there was change via freetext. One may discuss that this is wanted behavior as refresh slows down performance but IMO we should refresh as fast as possible once parsing was done.

In most cases, clicking on the factual data view enables the details of the selected item, otherwise the change would be available if the user changes the focus again to the details view or the name editor.

Ok, so we leave it. I was mostly working in synonymies, there Facts and Media are always empty so clicking on them was an easy way to trigger reload (which actually happens for the SupplementalDataView where it is unwanted - Suppl Data don't change by parsing)

1. I did like the disabling to indicate that data is not valid anymore so can we keep the disabling and simply do enabling when the view is refreshed.

This can be enabled with one line, I added again.

Works fine

The disabling is added again and the issue about the focus of the factual data, media or supplemental data view can be handled in another ticket, so I would close this ticket. Do you want to have a final view?

So we can close this ticket but should open new tickets for the open issues if they do not exist yet.