Coding Guideline » History » Revision 12
Revision 11 (Carsten Rose, 06.11.2022 19:57) → Revision 12/17 (Carsten Rose, 06.11.2022 19:58)
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. h3. 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@. h3. 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. 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. h3. QFQ Form * 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.