Newer
Older
.. ==================================================
.. ==================================================
.. ==================================================
.. Header hierarchy
.. ==
.. --
.. ^^
.. ""
.. ;;
.. ,,
..
.. --------------------------------------------used to the update the records specified ------
.. Best Practice T3 reST: https://docs.typo3.org/m/typo3/docs-how-to-document/master/en-us/WritingReST/CheatSheet.html
.. Reference: https://docs.typo3.org/m/typo3/docs-how-to-document/master/en-us/WritingReST/Index.html
.. Italic *italic*
.. Bold **bold**
.. Code ``text``
.. External Links: `Bootstrap <http://getbootstrap.com/>`_
.. Internal Link: :ref:`downloadButton` (default url text) or :ref:`download Button<downloadButton>` (explicit url text)
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
..
..
.. Admonitions
.. .. note:: .. important:: .. tip:: .. warning::
.. Color: (blue) (orange) (green) (red)
..
.. Definition:
.. some text becomes strong (only one line)
.. description has to indented
.. -*- coding: utf-8 -*- with BOM.
.. include:: Includes.txt
.. _concept:
Concept
=======
SIPs
----
The following is a technical background information. Not needed to just use QFQ.
The SIPs (=Server Id Pairs) are uniq timestamps, created/registered on the fly for a specific browser session (=user). Every SIP is
registered on the server (= stored in a browser session) and contains one or more key/value pairs. The key/value pairs never leave
the server. The SIPs will be used:
* to protect values not to be spoofed by anyone,
* to protect values not to be altered by anyone,
* to grant access, e.g.:
* load and save forms,
* upload files,
* download files,
* PHP AJAX pages.
SIPs becomes invalid, as soon as the current browser session is destroyed. The client (= user) can't manipulate the content
of SIPs - it's only possible to reuse already registered SIPs by the user, who already owns the session.
Access privileges
-----------------
The Typo3 FE Groups can be used to implement access privileges. Such groups are assigned to
* Typo3 FE users,
* Typo3 pages,
* and/or Typo3 content records (e.g. QFQ records).
This will be used for general page structure privileges.
A `record base` privileges controlling (e.g. which user can edit
which person record) will be implicit configured, by the way that records are viewable / editable (or not) through
SQL in the specific QFQ tt-content statements.
Typo3 QFQ content element
-------------------------
Insert one or more QFQ content elements on a Typo3 page. Specify column and language per content record as wished.
The title of the QFQ content element will not be rendered on the frontend. It's only visible to the webmaster in the
backend for orientation.
.. _qfq_keywords:
QFQ Keywords (Bodytext)
^^^^^^^^^^^^^^^^^^^^^^^
**All of these parameters are optional.**
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
+--------------------------------+---------------------------------------------------------------------------------+
| Name | Explanation |
+================================+=================================================================================+
| form | | Formname. |
| | | Static: **form = person** |
| | | By SIP: **form = {{form:SE}}** |
| | | By SQL: **form = {{SELECT c.form FROM Config AS c WHERE c.id={{a:C}} }}** |
+--------------------------------+---------------------------------------------------------------------------------+
| r | | <record id>. The form will load the record with the specified id. |
| | | Static: **r = 123** |
| | | By SQL: **r = {{SELECT ...}}** |
| | | If not specified, the SIP parameter 'r' is used. |
+--------------------------------+---------------------------------------------------------------------------------+
| dbIndex | E.g. `dbIndex = {{indexQfq:Y}}` Select a DB index. Only necessary if a |
| | different than the standard DB should be used. |
+--------------------------------+---------------------------------------------------------------------------------+
| debugShowBodyText | If='1' and :ref:`configuration`:*showDebugInfo: yes*, shows a |
| | tooltip with bodytext |
+--------------------------------+---------------------------------------------------------------------------------+
| sqlLog | Overwrites :ref:`configuration`: :ref:`SQL_LOG` . Only affects `Report`, |
| | not `Form`. |
+--------------------------------+---------------------------------------------------------------------------------+
| sqlLogMode | Overwrites :ref:`configuration`: :ref:`SQL_LOG_MODE<SQL_LOG_MODE>` . |
| | Only affects `Report`, not `Form`. |
+--------------------------------+---------------------------------------------------------------------------------+
| render | See :ref:`report-render`. Overwrites :ref:`configuration`: render. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.fbeg | Start token for every field (=column) |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.fend | End token for every field (=column) |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.fsep | Separator token between fields (=columns) |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.fskipwrap | Skip wrapping (via fbeg, fsep, fend) of named columns. Comma separated list of |
| | column id's (starting at 1). See also the :ref:`special-column-names` '_noWrap' |
| | to suppress wrapping. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.shead | Static start token for whole <level>, independent if records are selected |
| | Shown before `head`. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.stail | Static end token for whole <level>, independent if records are selected. |
| | Shown after `tail`. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.head | Dynamic start token for whole <level>. Only if at least one record is select. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.tail | Dynamic end token for whole <level>. Only if at least one record is select. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.rbeg | Start token for row. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.rbgd | Alternating (per row) token. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.rend | End token for row. Will be rendered **before** subsequent levels are processed |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.renr | End token for row. Will be rendered **after** subsequent levels are processed |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.rsep | Seperator token between rows |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.sql | SQL Query |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.twig | Twig Template |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.althead | If <level>.sql has no rows selected (empty), these token will be rendered. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.altsql | If <level>.sql has no rows selected (empty) or affected (delete, update, insert)|
| | the <altsql> will be fired. Note: Sub queries of <level> are not fired, even if |
| | <altsql> selects some rows. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level>.content | | *show* (default): content of current and sub level are directly shown. |
| | | *hide*: content of current and sub levels are **stored** and not shown. |
| | | *hideLevel*: content of current and sub levels are **stored** and only sub |
| | | levels are shown. |
| | | *store*: content of current and sub levels are **stored** and shown. |
| | | To retrieve the content: `{{<level>.line.content}}`. |
| | | See :ref:`syntax-of-report` |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.count | Current row index. Will be replaced before the query is fired in case of |
| | ``<level>``/``<alias>`` is an outer/previous level or it will be replaced after |
| | a query is fired in case ``<level>``/``<alias>`` is the current level. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.total | Total rows (MySQL ``num_rows`` for *SELECT* and *SHOW*, MySQL ``affected_rows`` |
| | for *UPDATE* and *INSERT*. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.insertId | Last insert id for *INSERT*. |
| <alias>.line.insertId | |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.content | Show content of `<level>`/`<alias>` (content have to be stored via |
| | <level>.content=... or <alias>.content=...). |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.altCount | Like 'line.count' but for 'alt' query. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.altTotal | Like 'line.total' but for 'alt' query. |
+--------------------------------+---------------------------------------------------------------------------------+
| <level|alias>.line.altInsertId | Like 'line.insertId' but for 'alt' query. |
+--------------------------------+---------------------------------------------------------------------------------+
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
.. _`report-render`:
Report: render
--------------
QFQ will render Report or Form in three situations:
#. Browser: The QFQ content is described by QFQ-Report syntax.
#. Browser: The QFQ content is described by a QFQ-Form.
#. API: The QFQ content is handled without Typo3. Typically a single tt-content record is specified in the request - only
that one is rendered by QFQ. This mode is typically used to export data like Excel Export.
Option 1 and 2 are distinguished by the parameter `form` (STORE_SIP or STORE_TYPO3). If 'form' is given, in most cases only a Form
should be shown (not the report).
+--------+-------------------------------------------------------------------------+
| render | Use |
+========+=========================================================================+
| single | Display Form or Report, but not both at the same time. If |
| | a SIP parameter 'form' is given, the form is rendered, else the report. |
+--------+-------------------------------------------------------------------------+
| both | Display Form and Report, both at the same time. |
+--------+-------------------------------------------------------------------------+
| api | Create output only when called via API (no Typo3). |
+--------+-------------------------------------------------------------------------+
Example::
render = both
form = {{form:SE}}
10 {
sql = SELECT ...
}
.. _`qfq-database`:
QFQ Database
------------
Recommended setup for Typo3 & QFQ Installation is with *two* databases. One for the Typo3 installation and one for QFQ.
A good practice is to name both databases equal, appending the suffix '_t3' and '_db'.
When QFQ is called, it checks for QFQ system tables. If they do not exist or have a lower version than the installed QFQ
version, the system tables will be automatically installed or updated.
.. _`system-tables`:
System tables
^^^^^^^^^^^^^
+---------------+------------+------------+
| Name | Use | Database |
+===============+============+============+
| Clipboard | Temporary | QFQ |
+---------------+------------+------------+
| Cron | Persistent | QFQ |
+---------------+------------+------------+
| Dirty | Temporary | QFQ | Data |
+---------------+------------+------------+
| Form | Persistent | QFQ |
+---------------+------------+------------+
| FormElement | Persistent | QFQ |
+---------------+------------+------------+
| FormSubmitLog | Persistent | QFQ | Data |
+---------------+------------+------------+
| MailLog | Persistent | QFQ | Data |
+---------------+------------+------------+
| Period | Persistent | Data |
+---------------+------------+------------+
| Split | Persistent | Data |
+---------------+------------+------------+
See :ref:`mail-log-page` and :ref:`form-submit-log-page` for some Frontend views for these tables.
* Check Bug #5459 / support of system tables in different DBs not supported.
.. _`multi-database`:
Multi Database
^^^^^^^^^^^^^^
Base: T3 & QFQ
""""""""""""""
QFQ typically interacts with one database, the QFQ database. The database used by Typo3 is typically a separate one.
Theoretically it might be the same (never tested), but it's strongly recommended to use a separated QFQ database to have
no problems on Typo3 updates and to have a clean separation between Typo3 and QFQ.
QFQ: System & Data
""""""""""""""""""
QFQ itself can be separated in 'QFQ system' (see :ref:`system-tables`) and 'QFQ data' databases (even more than one are
possible). The 'QFQ system' stores the forms, record locking, log tables and so on - `QFQ data` is for the rest.
A `Multi Database` setup is given, if 'QFQ system' is different from 'QFQ data'.
Data: Data1, Data2, ..., Data n
"""""""""""""""""""""""""""""""
Every database needs to be configured via :ref:`configuration` with it's own `index`.
`QFQ data` might switch between different 'data'-databases. In :ref:`configuration` one main `QFQ data` index will be specified
in `indexQfq`. If specific forms or reports should use a different database than that, `dbIndex` might change
`indexData` temporarily.
`dbIndex`: A `Report` (field `dbIndex`) as well as a `Form` (field `parameter`.`dbIndex`) can operate on a specific database.
A `Form` will:
* load the form-definition from `indexQfq` (table `Form` and `FormElement`),
* loads and save data from/in `indexData` (qfq.json) / `dbIndex` (form.parameter.dbIndex),
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
* retrieve extra information via `dbIndexExtra` - this is useful to offer information from a database and save them in a
different one.
The simplest setup, QFQ system & data in the same database, needs no `indexQfq / indexData` definition in
:ref:`configuration` or one or both of them set to '1'
To separate QFQ system and data, indexQfq and indexData will have different indexes.
A Multi Database setup might be useful for:
* several independent Typo3 QFQ installations (each have it's own form repository) and one central database, or
* one QFQ installation which should display / load /save records from different databases, or
* a combination of the above two.
Note:
* Option 'A' is the most simple and commonly used.
* Option 'B' separate the T3 and QFQ databases on two database hosts.
* Option 'C' is like 'B' but with a shared 'QFQ data'-database between three 'Typo3 / QFQ' instances.
* Further variants are possible.
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
| | Domain | Website Host | T3 | QFQ system | QFQ data |
+===+================+==============+===============================+==============================+==================================+
| A | standalone.edu | 'w' | <dbHost>, <dbname>_t3, <dbnameSingle>_db |
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
| B | appB1.edu | 'wApp' | <dbHostApp>, <dbnameB1>_t3 | <dbHostB1>, <dbnameApp>_db |
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
| B | appB2.edu | 'wApp' | <dbHostApp>, <dbnameB2>_t3 | <dbHostB2>, <dbnameApp>_db |
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
| C | appC1.edu | 'wAppC' | <dbHostAppC>, <dbnameC1>_t3 | <dbHostC>, <dbnameSysC1>_db | <dbHostData>_db, <dbNameData>_db |
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
| C | appC2.edu | 'wAppC' | <dbHostAppC>, <dbnameC2>_t3 | <dbHostC>, <dbnameSysC2>_db | <dbHostData>_db, <dbNameData>_db |
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
| C | appC3.edu | 'wAppC3' | <dbHostAppC3>, <dbnameC3>_t3 | <dbHostC3>, <dbnameSysC3>_db | <dbHostData>_db, <dbNameData>_db |
+---+----------------+--------------+-------------------------------+------------------------------+----------------------------------+
In :ref:`config-qfq-php` mutliple database credentials can be prepared. Mandatory is at least one credential setup like
`DB_1_USER`, `DB_1_SERVER`, `DB_1_PASSWORD`, `DB_1_NAME`. The number '1' indicates the `dbIndex`. Increment the number
to specify further database credential setups.
By convention, it's necessary that `DB_1` is the one who also have access to the Typo3 database. E.q. `QFQ Function`_ or
download links (based on QFQ functions) needs access to the T3 database to directly fetch tt-content records.
You'll find a real world example under `multi-db-use-case`_.
Different QFQ versions, shared database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When using different QFQ versions and a shared 'QFQ data'-database, there is some risk of conflicting
'QFQ system' tables. Best is to always use the same QFQ version on all instances or use a Multi Database setup.