Afficher une vue sous forme de grille

Objectif

Placer une liste d’enregistrements sur votre portail sans dessiner la liste — la grille propre à la plateforme, avec les colonnes décidées par une vue.

Avant de commencer

• Une vue sur la table, avec les colonnes que vous voulez montrer aux visiteurs. C’est d’elle que viennent les en-têtes, les largeurs et l’ordre.
• Une API personnalisée qui liste la table, cochée dans Ce qu’il peut lire du portail. Voir Publier une application en tant que portail pour savoir comment fonctionne cette liste.

Étapes

1. Dans le concepteur d’application, déposez Composants → Vue de table ou formulaire là où doit aller la liste.
2. Dans l’onglet Écran, choisissez la Table. Laissez Vue sur Celui par défaut de la table, ou choisissez l’une des vues de la table.
3. Choisissez l’API personnalisée (portail) par laquelle passent les lignes — Notices (api:par_list_notices@1), par exemple. Seuls les contrats qui répondent à un GET sont proposés, car une grille ne fait que lire.
4. Publiez, puis ouvrez le portail.

C’est tout, côté dessin. Vous ne choisissez pas les colonnes ici — la vue l’a déjà fait.

Une grille pose deux questions, et chacune des deux zones répond à l’une d’elles. La table et la vue décident de ce qu’il faut montrer — les en-têtes, les largeurs, l’ordre — et la plateforme les calcule avant que la page ne soit servie, si bien que rien de la structure de votre table n’atteint un navigateur public. L’API personnalisée décide de quelles lignes, car sur un portail chaque lecture passe par un contrat que vous avez écrit. Dans la liste des applications, la zone de l’API est ignorée et la table fournit les deux.

Ce que l’API doit faire

Paginer, et dire combien il y en a. La grille demande une page à la fois et lit total pour savoir s’il y en a une suivante :

var page = runQuery({
  entity: 'par_notice',
  select: ['par_name', 'par_category', 'par_published_on'],
  order: [{ field: 'par_published_on', descending: true }],
  top: num(getInput('top')),
  skip: num(getInput('skip'))
});

setOutput('rows', page);
setOutput('total', page.length());

Sans total, le pagineur ne peut pas distinguer une dernière page d’une page pleine, et proposera un bouton Suivant qui ne mène nulle part.

Une colonne que la vue a et que l’API ne renvoie pas

Elle affiche un tiret sur chaque ligne. La vue décide des en-têtes ; l’API décide de ce qu’il y a dans chaque ligne, et un champ que son select omet n’est pas dans la ligne. Ajouter une colonne, c’est donc deux modifications : la colonne dans la vue, et le champ dans le select de l’API.

C’est voulu, pas un oubli. La vue est partagée avec l’application à l’intérieur de la plateforme, et ajouter une colonne pour vos propres équipes ne doit pas publier ce champ à des inconnus. Ce qui sort de la plateforme, c’est ce que l’API sélectionne.

Une grille sans API n’apparaît pas du tout

Laissez API personnalisée (portail) vide, ou nommez une API qui n’a pas été accordée au portail, et la grille n’est pas servie — vous n’obtenez aucune grille plutôt que des en-têtes au-dessus d’un corps vide.

C’est voulu, et c’est la même règle que celle que suit le reste du portail : une grille vide se lit comme il n’y a aucun enregistrement, ce qui est une affirmation différente de ce portail n’a jamais été autorisé à les montrer. Se rabattre sur une lecture directe de la table serait pire encore — ce serait exactement la porte que ferme le §6.11.3, revenue par un autre chemin.

D’où viennent les colonnes, et quand

De la vue, au moment où le portail est servi. Modifiez la vue, rechargez le portail, et les colonnes changent — il n’y a rien à republier. C’est aussi pourquoi une page de portail ne demande jamais à la plateforme ce que contient une vue : la réponse arrive avec la page.

Si vous nommez une vue et la supprimez ensuite, la grille indique qu’elle est indisponible plutôt que de se rabattre discrètement sur la vue par défaut. Vous avez choisi ces colonnes, et un autre ensemble apparaissant sans avertissement sur une page publique est pire qu’une grille qui admet honnêtement être cassée.

Ce qu’un visiteur peut et ne peut pas en faire

Il peut la lire et la parcourir page par page. Il ne peut pas sélectionner de lignes, ouvrir un enregistrement ni utiliser une barre de commandes — rien de tout cela n’existe ici. Chacune de ces choses est une action sur un enregistrement, et ce qu’un inconnu peut faire à un enregistrement relève de votre API personnalisée, pas d’une grille.

Si vous voulez qu’un visiteur fasse quelque chose, dessinez un bouton et donnez-lui sa propre ligne dans la liste d’autorisations.

Non disponible sur un portail

• Un formulaire rapide (surfaces Create/Edit). Un formulaire a besoin des règles d’obligation de la table, de ses choix et de ses étapes de plug-in, et rien de tout cela n’a sa place sur un site public. Dessinez plutôt les champs, et écrivez l’API personnalisée derrière votre bouton Enregistrer — voir Permettre aux visiteurs d’enregistrer des modifications.
• Une liste de tâches. Un visiteur de portail n’est pas un utilisateur de la plateforme et n’a pas de boîte de réception.

Les deux le signalent sur la page plutôt que d’échouer en silence.

Vérifier que cela a fonctionné

Ouvrez le portail comme le ferait un inconnu. La grille affiche les colonnes de votre vue, avec ses en-têtes, et parcourt page par page les enregistrements que renvoie l’API. Modifiez ensuite l’un des en-têtes de colonne de la vue et rechargez — le portail suit.