diff --git a/data/doc/documentation.xml b/data/doc/documentation.xml
index 8ca268a9..dcaad69c 100644
--- a/data/doc/documentation.xml
+++ b/data/doc/documentation.xml
@@ -7296,7 +7296,8 @@ import module namespace docbook-nav="http://www.tei-c.org/tei-simple/navigation/
Editing a personSay, we would like to add a variant name for our Ambrosius Leibnütz entry,
- and also translate the content into English. From the annotation editor we can use the pencil icon
+ and also translate the German content which was pulled in from GND into English. From the annotation editor we can use the
+ pencil icon
to open the editing form. It will appear in the right hand panel and presents form controls for
the information stored in the register. We can edit these fields and just press the save icon when we're done.
At this point new data will be stored in the local register. NB: saving obviously only works for logged in users.
@@ -7309,52 +7310,52 @@ import module namespace docbook-nav="http://www.tei-c.org/tei-simple/navigation/
-
- Customizing local registers
- Each project may have particular needs in terms what kinds of registers it needs and what kind of
- microstructure the registry entries need to have. Therefore TEI Publisher proposes a modular approach
- to the subject which allows for customizations. Nevertheless we have several distinct conceptual blocks
- which need careful orchestration to smoothly work together. Namely, we need a place to store the register,
- the data model for individual entry, the model and layout template for the form and the api endpoints
- and corresponding functions for all CRUD (create, read, update, delete) operations on the register entry.
- The API endpoints for registers customization start with /api/register and call a set of functions from
- modules/registers.xql, which can be customized to reflect differences in the data
- coming from external authority and local entry structures.
- As mentioned before, location of the registers is determined via $config:register-root variable in config.xqm.
- In the same module we will find further customization options related to registers: location of the models for the input forms
- (in $config:register-forms) and dedicated configuration for each of the editable register types.
- The actual forms themselves are located in templates/pagesannotations as they are effectively
- HTML files with embedded Fore form webcomponents.
-
- The $config:register-map allows to determine the following information for each registry:
-
-
- id: identifier by which the registry can be reached in the database, either to access
- information about existing entry or to determine the insertion point for a new one; e.g. for
- the person registry it is by default set to pb-person which is the @xml:id attribute of the TEI element in
- data/registers/persons.xml
- <TEI xmlns="http://www.tei-c.org/ns/1.0" xml:id="pb-persons">
- this identifier is always resolved in the context of the $config:register-root variable
- to avoid potential conflicts
-
-
- default: identifier by which the default data model for an entry can be accessed; this identifier is always resolved in the context of the $config:register-forms
-
-
- prefix: a prefix for the newly created entries, e.g. a new person will be given an id
- like person-00015 or similar, depending how many have been created locally earlier.
-
-
-
-
+
+ Customizing local registers
+ Each project may have particular needs in terms what kinds of registers it needs and what kind of
+ microstructure the registry entries need to have. Therefore TEI Publisher proposes a modular approach
+ to the subject which allows for customizations. Nevertheless there are several distinct conceptual blocks
+ which need careful orchestration to smoothly work together. Namely, a place to store the register,
+ the data model for individual entry, the model and layout template for the form and the api endpoints
+ and corresponding functions for all CRUD (create, read, update, delete) operations on the register entry.
+ The API endpoints for registers customization start with /api/register and call a set of functions from
+ modules/registers.xql, which can be customized to reflect differences in the data
+ coming from external authority and local entry structures.
+ As mentioned before, location of the registers is determined via $config:register-root variable in config.xqm.
+ In the same module there are further customization options related to registers: location of the models for the input forms
+ (in $config:register-forms) and dedicated configuration for each of the editable register types.
+ The actual forms themselves are located in templates/pagesannotations as they are effectively
+ HTML files with embedded Fore form webcomponents. Please consult Fore documentation how to customize these.
+
+ The $config:register-map allows to determine the following information for each registry:
+
+
+ id: identifier by which the registry can be reached in the database, either to access
+ information about existing entry or to determine the insertion point for a new one; e.g. for
+ the person registry it is by default set to pb-person which is the @xml:id attribute of the TEI element in
+ data/registers/persons.xml
+ <TEI xmlns="http://www.tei-c.org/ns/1.0" xml:id="pb-persons">
+ this identifier is always resolved in the context of the $config:register-root variable
+ to avoid potential conflicts
+
+
+ default: identifier by which the default data model for an entry can be accessed; this identifier is always resolved in the context of the $config:register-forms
+
+
+ prefix: a prefix for the newly created entries, e.g. a new person will be given an id
+ like person-00015 or similar, depending how many have been created locally earlier.
+
+
+
+
TEI Publisher in production