Variables from specific stores: {{<name>[:<store/s>[:<sanitize class>]]}}
Row index and total rows: {{<level>.line.count}} or {{<level>.line.total}}
...
...
@@ -974,6 +976,7 @@ The parsed bodytext could be displayed by activating 'showDebugInfo' (:ref:`debu
debugShowBodyText = 1
A small symbol with a tooltip will be shown, where the content record will be displayed on the webpage.
Note: :ref:`debug` information will only be shown with *showDebugInfo=yes* in config.ini .
Structure
---------
...
...
@@ -1011,7 +1014,7 @@ Across several lines
^^^^^^^^^^^^^^^^^^^^
To make SQL quieres more readable, it's possible to split a line across several lines. Lines with keywords are on their
own - if there are non 'keyword' lines, they will be appended at the last keyword line. 'Keyword' lines:
own - if a line is not a 'keyword' line, it will be appended at the last keyword line. 'Keyword' lines are detected on:
* <level>.<keyword> =
* {
...
...
@@ -1803,7 +1806,8 @@ Solution for *#Challenge_2*:
Include a form via link/url
^^^^^^^^^^^^^^^^^^^^^^^^^^^
In most occasions it is handy if a formname does not have to be hard-coded in report but can be passed to the page as a parameter. To achieve this, first build a link on page A which includes the required parameters:
In most occasions it is handy if a formname does not have to be hard-coded in report but can be passed to the page as a
parameter. To achieve this, first build a link on page A which includes the required parameters:
**page A**
...
...
@@ -1814,9 +1818,8 @@ In most occasions it is handy if a formname does not have to be hard-coded in re
..
The above example builds a link to pageB - refer to the 'link'-manual for details. The link tells page B to render the form with name formname and load the record with id id for editing.
The above example builds a link to pageB - refer to the :ref:`column-link`-manual for details. The link tells page B to
render the form with name formname and load the record with id id for editing.
Examples
--------
...
...
@@ -2032,7 +2035,18 @@ Formating (i.e. wrapping of data with HTML tags etc.) can be achieved in two dif
..
The same as above, but with braces::
10 {
sql = SELECT p.name FROM exp_person AS p
head = <ul>
tail = </ul>
rbeg = <li>
rend = </li>
}
::
Two queries
...
...
@@ -2086,7 +2100,7 @@ Two queries: nested with variables
* For every record of '10', all assigned records of 10.10 will be printed.
Two queries: nested with hidden variables in a table
Two queries: nested with hidden variables in a table
::
...
...
@@ -2100,8 +2114,43 @@ Two queries: nested with variables
..
Same as above, but written in the nested notation::
10 {
sql = SELECT p.id AS _p_id, p.name FROM exp_person AS p
rend = <br />
10 {
# inner query
sql = SELECT a.street FROM exp_address AS a WHERE a.p_id='{{10.p_id}}'
rend = <br />
}
}
* Columns starting with a '_' won't be printed but can be accessed as regular columns.
Best practice
=============
Debug Report
------------
Writing "report's" in the nested notation or long queries broken over several lines, might not interpreted as wished.
Best for debugging is to specify in the tt-content record::
debugShowBodyText = 1
Note: Debug information is only display if it's enabled in *config.ini* by
* *SHOW_DEBUG_INFO=yes* or
* *SHOW_DEBUG_INFO=auto* and logged in in the same Browser as a Typo3 backend user.
More detailed error messages
----------------------------
If *SHOW_DEBUG_INFO* is enabled, a full stacktrace and variable contents are displayed in case of an error.