Coding Guideline » History » Revision 16
Revision 15 (Carsten Rose, 19.11.2022 14:58) → Revision 16/17 (Carsten Rose, 19.11.2022 14:59)
{{>toc}}
h1. Coding Guideline
h2. QFQ General
* http://docs.qfq.io/en/master/CodingGuideline.html
h2. I-MATH
h3. Tabelle
* *Name*: Camel case, erster Buchstabe *gross*, kein Underscore. Bsp: @FormElement@
* Im ERD sollte bei jeder Tabelle auch die zu verwendende Abkürzung genannt werden. Bsp: @FormElement - fe@
* Sind in
h4. Spalten
* *Name*: Camel case, erster Buchstabe *klein*, kein Underscore. Bsp: @formId@
* *Erste Spalte*: @id@, Primary Key.
* *Vorletzte Spalte*: @created@, datetime, default: current timestamp
* *Letzte Spalte*: @modified@, datetime, default: current timestamp, on update current timestamp
* Wird auf einen Primary Key einer anderen Tabelle verwiesen, ergibt sich der Name aus <Kuerzel><Id>. Bsp: @pId@.
* Gibt es in einer Tabelle a) mehrere Spalten auf die gleiche Fremdtabelle (und muessen daher unterschiedlich sein) oder b) soll der Spaltenamen klarer beschreiben, kann eine Spezifizierung angehängt werden. Bsp: @pIdApplicant@, @pIdHead@. _Auf jeden Fall steht das @pId@ am Anfang_ .
h4. Spalte 'reference'
* *Name*: Als Vorbereitung um unterschiedliche Tools aus verschiedenen Instanzen mergen zu koennen, wird empfohlen die Referenz Records mit einem eindeutigen Prefix zu versehen. Bsp: @my_exercise_group@
h3. Formular
* *Name*: Camel case, erster Buchstabe *klein*, kein Underscore. Bsp: @formElement@
* Sind in einer Instanz mehrere Tools, sollten die Forms anhand eines Prefixes unterschieden werden. Bsp: @dissReview@, @maReview@.
* Mandatory SIP parameter should to be mentioned in @Form.requiredNew@ and/or @Form.requiredEdit@.
* If the title of a FormElement isn’t descriptive enough, use _tooltip_ , note or _extraButtonInfo_ to explain to a user.
* Every Form should show a descriptive title to identify the task and current record. E.g. *Not* ‘Person’ *but* ‘Person: John Doe’.
* Often the length of a pill title if not sufficient, use a tooltip to give a more descriptive hint.
h3. Schemata
* BPMN: Zeichnung via DrawIO
* ERD: Zeichnung via DrawIO
h3. Constants
* Define constants in @Extensions > QFQ > Custom > ...@
* Dynamic values under @Extensions > QFQ > Dynamic > ...@
h3. QFQ content record
* Name the record in the header field with:
* Regular content: [QFQ] ...
* Content in the left column: [QFQ,L] ...
* Content in englisch: [QFQ,E] ...
* The first lines should be comments, explaining what the record does and list *all* passed variables (STORE_SIP, STORE_USER). Optional variables are indicated by using STORE_EMPTY or STORE_ZERO: <pre>
#
# Shows list of Persons living in {{country:SE}}
#
# {{country:SE}}
#
</pre>
* Normalize variables: A good practice is to define all possible STORE_SIP Parameter in a SQL at the beginning and copy them to STORE_RECORD: <pre>
10 {
# Normalize variables
sql = SELECT '{{country:SE}}' AS _country
# List selected persons per country
20.sql = SELECT p.name FROM Person AS p WHERE p.country LIKE '{{country:R}}'
}
</pre>
* Always comment the queries like shown above.
* Indention are two spaces and reflect child parent relation. Example: A _WHERE_ clause is a child of a _SELECT_ , an _AND_ statement is a child of a _SELECT_ or _LEFT JOIN ... ON ..._. <pre>
10 {
# All persons
sql = SELECT p.name
, GROUP_CONCAT(adr.email)
FROM Person AS p
LEFT JOIN address AS adr
ON adr.pId=p.id
AND adr.type='email'
WHERE p.type='employee
AND CURDATE() < p.end
GROUP BY adr.pId
20 {
sql = SELECT ...
}
}
</pre>
* Multi Use Records: If identical QFQ records used multiple times in an installation, use tt-content type 'insert records' to do the definition once, and than link all places.
* Multi Language: best is to define all languages on one tt-content record and the use tt-contetn type 'insert records' to link from different languages.