EDIT

{{>toc}}

# Editor Strategies

Handling protected cache fields and atomized data, freetext areas and structure data input, objects that need to be updated but are related to other objcets, and other issues at the same time needs defined stratagies.

This page tries to point out the different strategies and to lay emphasis on the possible alternatives and considered rules.

## Strategies

Strategies to be considere are

1. Interaction of cache / atomized fields and protected /non protected states

1. Locking freetext area

1. Object change strategy

1. NameRelationships: Editing (in particular basionyms and replaced synonyms, parsing of homonyms)

## Interaction of cache / atomized fields and protected /non protected states

to be done

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

Just some text to move this all down

## Locking freetext area

### Attributes that will lead to a lock independent of the object change strategy

|Attribute| Reasoning |Example(s)|Actions needed| Notes |

|name.appendedPhrase|a change in name.appededPhrase is shown in the fullTitleCache and therefore in the freetext, but name.appended phrase can not be parsed  |  | |  |

|NOT: taxon.appendedPhrase| a change in taxon.appededPhrase is not shown in the freetext area| | | | |

|All protected caches like | a change in one of the cache fields is reflected in the fullTitleCache and the freetext. Generally the parser may not be able to set the same protected caches as the details view (either it may unprotect parts that are protected on purpose or more often it will protect other caches that do not need to be protected  | _Areca calisoA Becc., Leafl. Philipp. Bot.  8: 2998 (1919)_ may have a protected namecache because the name part is not parsable. Ones you edit this in the freetext the whole string will not be parsable resulting in a protected full title cache  | | |

|name.fullTitleCache |  |  | | |

|name.titleCache |  |  | | |

|name.nameCache|  |  | |  |

|name.authorshipCache|  |  | | |

|name.combinationAuthorTeam.nomenclaturalCache (and other teams)|  |  | | |

### Attributes that will lead to a lock dependent of the object change strategy

* to be done

## Object Change Strategy

### Intentions

In general a user may have three main intentions to change an object:

1. Correct a typo / minor corrections

1. Change the representation of an existing object

1. Change the object itself

A user may also change a name unintentionally. 

1. Unintended change of data 

Examples:

1. Askellia elegans (Hook.) W. A. Weber in Phytol*go*ia 55: 6. 1984 -> Askellia elegans (Hook.) W. A. Weber in Phytol*og*ia 55: 6. 1984

1. **Askellia *elegans (Hook.) W. A. Weber in Phytologia 55*: 6. 1984** -> **A. *elegans (Hook.) W. A. Weber in Phytologia 55** (1984): 6.*

1. Askellia elegans (Hook.) W. A. Weber in **Phytologia 55: 6. 1984** -> Askellia elegans (Hook.) W. A. Weber in **Trans. Amer. Philos. Soc. 23: tab 7. 1999.** 

1. Unintended hit of key or unintended drag&drop 

The four types of object changes differ in the most probable intended object change strategy.

1. For typos / minor corrections the most probable intended change strategy is to change the object itself because also in other contexts the corrected version of the object will be the preferred one.

1. For representation changes it depends on further conditions what the preferred strategy is. 

  a. In a single-user environment or an environment that agrees on sharing the same objects and the same representation for an object the most probable intended change strategy is to keep the object and save it updated.

  b. In an environment that shares objects but may want to use different representations for objects (due to personal preferences or due to some other demands, e.g. the need to show historical representations) the most probable intended change strategy is to create a new object / find a matching object

1. For changing the object itself the most probable intended change strategy is to create a new object / find a matching object.

1. For unintended changes the most probable intended change strategy is to create a new object (to reduce the damage to a minimum)

Unfortunately we often do not know if a change is intended to be a change of type 1, 2, 3 or 4. However there are different ways to guess what type was intended. You may guess via 

1. compare functions like Levenshtein distance or others

1. the way how the user entered the change

 ... in work ...

Object change stragies may have two extremes. The first resulting in almost no new objects when you change any data. The second resulting in only new objects with even objects created new because they relate to a changed object, e.g. a TaxonName may be created new because its nomenclatural reference has been changed.

In the following these two strategies are described and some rules are extracted.

The objects we talk about are: 

* taxon

* taxon name

* all author teams

* all author team members

* nomenclatural reference

* nomeclatural inreference

* nomenclatural status (set)

* name relationships (set)

* type designations

* (homotypical groups) 

 | taxon

* taxon name

* all author teams

* all author team members

* nomenclatural reference

* nomeclatural inreference

* nomenclatural status (set)

* name relationships (set)

* type designations

* (homotypical groups) 

### Strategy 1: Do not create any new objects: all objects will be changed and saved, no new objects are created if not necessary