Coding Guideline » History » Version 15
Carsten Rose, 19.11.2022 14:58
1 | 14 | Carsten Rose | {{>toc}} |
---|---|---|---|
2 | 13 | Carsten Rose | |
3 | 1 | Carsten Rose | h1. Coding Guideline |
4 | |||
5 | 6 | Carsten Rose | h2. QFQ General |
6 | 1 | Carsten Rose | |
7 | 6 | Carsten Rose | * http://docs.qfq.io/en/master/CodingGuideline.html |
8 | |||
9 | h2. I-MATH |
||
10 | 1 | Carsten Rose | |
11 | 11 | Carsten Rose | h3. Tabelle |
12 | 1 | Carsten Rose | |
13 | 11 | Carsten Rose | * *Name*: Camel case, erster Buchstabe *gross*, kein Underscore. Bsp: @FormElement@ |
14 | * Im ERD sollte bei jeder Tabelle auch die zu verwendende Abkürzung genannt werden. Bsp: @FormElement - fe@ |
||
15 | * Sind in |
||
16 | 1 | Carsten Rose | |
17 | 12 | Carsten Rose | h4. Spalten |
18 | 1 | Carsten Rose | |
19 | 11 | Carsten Rose | * *Name*: Camel case, erster Buchstabe *klein*, kein Underscore. Bsp: @formId@ |
20 | * *Erste Spalte*: @id@, Primary Key. |
||
21 | * *Vorletzte Spalte*: @created@, datetime, default: current timestamp |
||
22 | * *Letzte Spalte*: @modified@, datetime, default: current timestamp, on update current timestamp |
||
23 | * Wird auf einen Primary Key einer anderen Tabelle verwiesen, ergibt sich der Name aus <Kuerzel><Id>. Bsp: @pId@. |
||
24 | 1 | Carsten Rose | |
25 | 11 | Carsten Rose | * 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_ . |
26 | 1 | Carsten Rose | |
27 | 12 | Carsten Rose | h4. Spalte 'reference' |
28 | |||
29 | * *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@ |
||
30 | |||
31 | 1 | Carsten Rose | h3. Formular |
32 | 11 | Carsten Rose | |
33 | 3 | Carsten Rose | * *Name*: Camel case, erster Buchstabe *klein*, kein Underscore. Bsp: @formElement@ |
34 | 11 | Carsten Rose | * Sind in einer Instanz mehrere Tools, sollten die Forms anhand eines Prefixes unterschieden werden. Bsp: @dissReview@, @maReview@. |
35 | 7 | Carsten Rose | |
36 | 11 | Carsten Rose | h3. Schemata |
37 | 7 | Carsten Rose | |
38 | 11 | Carsten Rose | * BPMN: Zeichnung via DrawIO |
39 | * ERD: Zeichnung via DrawIO |
||
40 | 1 | Carsten Rose | |
41 | 11 | Carsten Rose | h3. Constants |
42 | 6 | Carsten Rose | |
43 | 11 | Carsten Rose | * Define constants in @Extensions > QFQ > Custom > ...@ |
44 | * Dynamic values under @Extensions > QFQ > Dynamic > ...@ |
||
45 | 6 | Carsten Rose | |
46 | 11 | Carsten Rose | h3. QFQ content record |
47 | 6 | Carsten Rose | |
48 | 11 | Carsten Rose | * Name the record in the header field with: |
49 | 6 | Carsten Rose | |
50 | 11 | Carsten Rose | * Regular content: [QFQ] ... |
51 | * Content in the left column: [QFQ,L] ... |
||
52 | * Content in englisch: [QFQ,E] ... |
||
53 | 6 | Carsten Rose | |
54 | 11 | Carsten Rose | * 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> |
55 | 6 | Carsten Rose | # |
56 | 1 | Carsten Rose | # Shows list of Persons living in {{country:SE}} |
57 | # |
||
58 | 6 | Carsten Rose | # {{country:SE}} |
59 | # |
||
60 | 1 | Carsten Rose | </pre> |
61 | |||
62 | 11 | Carsten Rose | * 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> |
63 | 6 | Carsten Rose | 10 { |
64 | 1 | Carsten Rose | # Normalize variables |
65 | 8 | Carsten Rose | sql = SELECT '{{country:SE}}' AS _country |
66 | 6 | Carsten Rose | |
67 | 8 | Carsten Rose | # List selected persons per country |
68 | 20.sql = SELECT p.name FROM Person AS p WHERE p.country LIKE '{{country:R}}' |
||
69 | 1 | Carsten Rose | } |
70 | 8 | Carsten Rose | </pre> |
71 | |||
72 | 11 | Carsten Rose | * Always comment the queries like shown above. |
73 | * 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> |
||
74 | 1 | Carsten Rose | 10 { |
75 | # All persons |
||
76 | 9 | Carsten Rose | sql = SELECT p.name |
77 | 8 | Carsten Rose | , GROUP_CONCAT(adr.email) |
78 | FROM Person AS p |
||
79 | LEFT JOIN address AS adr |
||
80 | ON adr.pId=p.id |
||
81 | AND adr.type='email' |
||
82 | WHERE p.type='employee |
||
83 | AND CURDATE() < p.end |
||
84 | GROUP BY adr.pId |
||
85 | 20 { |
||
86 | sql = SELECT ... |
||
87 | } |
||
88 | 10 | Carsten Rose | } |
89 | </pre> |
||
90 | |||
91 | 11 | Carsten Rose | * 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. |
92 | * 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. |