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