-

Note: You are currently viewing documentation for Moodle 3.10. Up-to-date documentation for the latest stable version of Moodle may be available here: Dashboard Configuration: Raw data (litteral) rendering.

Dashboard Configuration: Raw data (litteral) rendering: Difference between revisions

From MoodleDocs
Line 103: Line 103:
Right as for output columns, filter criterias will have comprehensive labels for display.
Right as for output columns, filter criterias will have comprehensive labels for display.


Youmay enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.
You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.


Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...
Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

Revision as of 21:03, 13 September 2012

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

Common settings for row data output

Choosing columns as data output

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

  SELECT
  firstname as fn,
  lastname as ln,
  username as login
  ...

Following names could figure in the column selection textfield: ln;fn;login

Output fields display name

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login Output field names : Firstname;Lastname;UserID

Output fields format

Formatter les données exactement dans l'expression de la requête SQL n'est pas toujours commode. Cette liste permet d'effectuer un post-formattage des données, basé sur la fonction sprintf(). Il est par exemple possible de reformatter des données numériques en utilisant les codes de format de cette fonction :

   %s : string
   %d : integer (floored)
   %03d : integer with 3 digits, 0-filled (001, 002, etc.)
   %.2f : 2 digit decimals
   etc. (check the PHP sprintf documentation for the complete formatting syntax).

Result Page Size

This setting sets up a page limitation for linear tables as output.

Override Big Results security

This check box disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

Query caching

Enabling query cache

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

TTL (Time to live)

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : L'activation du cache de résultat est obligatoire pour activer les exports en fichiers.

Data Cleanup (linear table output only)

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

Sortable Table (linear table only)

If table is set to sortable, column names will enable sorting links.

Sub-totals

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table is sorted using the subtotal driving column.

Output Dynamic Filters

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

  SELECT
  firstname as fn,
  lastname as ln,
  city as ct
  ....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

Filters

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter defintion needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

Filter names

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

Défaut pour les filtres

Les filtres ajoutent des clauses de restriction à la requête. Sans valeur par défaut, les clauses de filtrage sont inopérantes lorsque le tableau de bord est affiché pour la première fois dans la même session. Ce réglage permet de palier à ce défaut et permet d'activer une modalité du filtre particulière dès le premier accès au tableau de bord. Les modalités possibles sont :

   FIRST : Restreint la plage de données à la première modalité du filtre
   LAST : Restreint la plage de données à la dernière modalité du filtre
   <vide> : Aucune restriction par défaut pour ce filtre.

Les défauts doivent être définis comme une liste à point-virgule (;) égale en ordre et en nombre à la liste déclarée de filtres.

Exemple :

Filtres : department as dpt;city as ville Default pour les filtres : ;FIRST

Dans cet exemple, la valeur par défaut du filtre département est laissée vide. Options pour les filtres Des options pour les filtres peuvent changer de manière importante la réaction du tableau de bord ou d'une association de tableaux de bord sur la même page. Ces options sont des "marqueurs" alphabétiques et peuvent s'associer dans n'importe quel ordre :

   g : Filtre gobal. Si d'autres filtres sont définis avec les mêmes identifiants de colonnes dans d'autres instances de tableaux de bord sur la même page, alors les choix de modalité de l'ensemble de ces filtres globaux sont identiques. (Cela permet de filtrer de la même manière différents résultats associés sur la même page).
   s : "Single" : Ce commutateur, s'il est présent interdit la sélection de la modalité "*" (pas de filtrage), et impose donc que le filtre soit calé sur l'une de ses modalités. Cela est utile lorsque la quantité de résultats produits par la requête du tableau de bord est très importante et pourrait poser des problèmes de performances générales du site. Si aucune valeur explicite de "défaut" n' été définie pour ce filtre, la valeur implicite FIRST est utilisée dans ce cas.
   m : "Multiple" : Ce commutateur, s'il est actif, autorise la sélection de plusieurs modalités du filtre pour réaliser des intervalles ou une association de plages. Le filtre se transforme en liste à sélection multiple.
   x : "Crossover" : Habituellement, la construction interne d'un filtre effectue des traitements complexes de nettoyage de la requête pour trouver les modalités d'un filtre. Ces traitements peuvent échouer dans certains cas, si la requête a une expression complexe par elle-même (union, requêtes imbriquées, multiples clauses ORDER BY imbriquées, etc.). Ce commutateur désactive ces traitements, ce qui peut dans certains cas de figure favorables, rétablir un fonctionnement correct de la pré-requête du filtre.

Type de tables

Ce sélecteur choisit entre trois types de rendus de données brutes :

  • Rendu linéraire : Les données sont affichées comme une table simple, avec les colonnes de sortie en horizontal, et les enregistrements trouvés en vertical.

Sortie en table linéaire

(Requête origine pour l'exemple)

  • Rendu tabulé (tables croisées) : Les données sont présentées sous forme de tableaux croisés dynamiques à deux dimension. La configuration de ce mode nécessite des paramètres supplémentaires.

Sortie de donnée tabulaire

  • Rendu hiérarchique : Ce mode de rendu demande quelques contraintes sur la requête. Pour pouvoir utiliser ce mode de rendu, les données extraites de la base de données doivent présenter une structure hiérarchique induite. Une structure hiérarchique doit présenter :
    • Un principe de parenté (un enregistrement est "fils" d'un autre de niveau hiérarchique supérieur)
    • Un indicateur (ou une combinaison d'indicateurs) disponible pour chaque noeud de l'arbre.

Tree-shaped hierarchic view

Ce mode d'affichage nécessite des paramètres supplémentaires.