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

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

From MoodleDocs
Line 40: Line 40:
     etc. (check the PHP sprintf documentation for the complete formatting syntax).
     etc. (check the PHP sprintf documentation for the complete formatting syntax).


===Result Page Size===
==Result Page Size==


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


==Override Big Results security : Cette case à cocher désactive un dispositif de sécurité qui agit lorsque le cours contenant le tableau de bord est en mode édition. En effet, si une requête est mal configurée, il est possible que l'exécution de la requête provoque une erreur majeure et ne permette plus l'accès à la configuration du tableau de bord. La sécurité d'édition force l'utilisation de données en cache lorsque le cours est en mode édition pour préserver l'accessibilité à la configuration de la requête.
===Override Big Results security=== Cette case à cocher désactive un dispositif de sécurité qui agit lorsque le cours contenant le tableau de bord est en mode édition. En effet, si une requête est mal configurée, il est possible que l'exécution de la requête provoque une erreur majeure et ne permette plus l'accès à la configuration du tableau de bord. La sécurité d'édition force l'utilisation de données en cache lorsque le cours est en mode édition pour préserver l'accessibilité à la configuration de la requête.


==Query caching==
==Query caching==

Revision as of 20:46, 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=== Cette case à cocher désactive un dispositif de sécurité qui agit lorsque le cours contenant le tableau de bord est en mode édition. En effet, si une requête est mal configurée, il est possible que l'exécution de la requête provoque une erreur majeure et ne permette plus l'accès à la configuration du tableau de bord. La sécurité d'édition force l'utilisation de données en cache lorsque le cours est en mode édition pour préserver l'accessibilité à la configuration de la requête.

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

Si des sommateurs sont déclarés (voir rubrique "sommateurs"), alors il est possible de produire des sous-totaux de ces sommateurs pilotés par le changement de valeur dans la colonne mentionnée. Pour que ces sous-totaux apparaissent, il sera également nécessaire que la clef de tri activée soit cette colonne. Filtrage des données

Ce chapitre important permet d'obtenir qu'une requête puisse présenter une certaine interactivité à l'exploitation des résultats.

Les filtres définissent des critères qui permettent d'ajouter au tableau de bord des "sélecteurs" (listes déroulantes) de filtrage éliminant des données non désirées. Un filtre désigne en général une colonne dont l'ensemble des valeurs distinctes deviennent les "modalités de filtrage".

Exemple :

Soit une requête :

SELECT firstname as fn, lastname as ln, city as ville

....

et des utilisateurs répartis entre 3 villes PARIS, LYON et MARSEILLE.

Définir la colonne "city as ville" comme filtre ajoutera une liste de filtrage dont les modalités seront "*,PARIS,LYON,MARSEILLE". Il sera donc possible de filtrer la sortie suivant l'une ou l'autre de ces modalités. Filtres

Ce champ accepte une liste à point-virgules (;) de définition de colonnes qui constituent les filtres.

   Le filtre doit être défini par la "clause SQL de définition de colonne" entière, à savoir avec son expression aliasée. (Ainsi dans l'exemple précédent on écrira comme nom de filtre "city as ville" et non "city" ou "ville" tout seul).

Filter names

Pour une meilleure compréhension de l'usager des rapports, il est possible de redéfinir quel est le nom visible du filtre sur l'interface.

Ce champ de texte permet de donner une liste à point-virgule (;) des labels associés à chaque filtre, dans le même ordre et nombre que la définition des filtres.

Note : Il n'est pas prévu d'échappement pour un caractère littéral ";". Ce caractère n'est donc pas utilisable ni dans les labels, ni dans les noms affichés de colonnes.

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.