DOCUMENTATION EN LIGNE
DE WINDEVWEBDEV ET WINDEV MOBILE

Aide / Développer une application ou un site / Spécificités WEBDEV
  • Présentation
  • Utilisation des plans
  • Effets lors du chargement
  • Affichage différé
  • Utilisation des popups
  • Authentification
  • Gestion de la touche Back
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaEtats et RequêtesCode Utilisateur (MCU)
WEBDEV
WindowsLinuxPHPWEBDEV - Code Navigateur
WINDEV Mobile
AndroidWidget AndroidiPhone/iPadWidget IOSApple WatchMac CatalystUniversal Windows 10 App
Autres
Procédures stockées
Présentation
Une "Single Page App" est une application Web (Internet ou Intranet) dont toutes les pages sont regroupées dans une même page.
Avec WEBDEV, ce type d'application est facilement réalisable grâce aux plans, aux popups, aux cookies, ...
Utilisation des plans
A partir de la version 22, WEBDEV permet d'utiliser les plans dans une page Web. L'utilisation de plans permet d'éviter les allers-retours avec le serveur à chaque changement de page : les applications paraissent donc plus fluides, plus "natives".
Le fonctionnement des plans en WEBDEV est très proche du fonctionnement des plans en WINDEV/WINDEV Mobile.
Il existe cependant quelques différences :
  1. Les plans sont disponibles indépendamment pour chaque élément conteneur : la page, une zone de mise en page, une zone de texte riche, une cellule. Cette fonctionnalité permet d'effectuer des combinaisons d'affichage pour répondre à tous les besoins.
  2. La gestion des plans doit être explicitement activée dans l'élément. Depuis la description de l'élément conteneur, onglet "UI", il suffit d'activer l'option "Activer la gestion des plans".
  3. Il n'existe pas de plan "0".
    • En WINDEV, un champ qui doit s'afficher sur tous les plans est relié au plan "0". C'est le plan par défaut, qui est toujours visible.
    • En WEBDEV, un champ qui doit être visible tout le temps doit être explicitement mis sur tous les plans ayant du contenu.
  4. Il n'est pas possible de modifier le plan d'un champ par programmation. L'association d'un champ à un ou plusieurs plans se fait uniquement en édition.
Pour modifier le plan affiché, il suffit d'utiliser la propriété Plan sur l'élément conteneur.
// Passage au plan Tableau de bord
CELL_Plan.Plan = 2

Effets lors du chargement

Le passage d'un plan à un autre peut être accompagné d'un ou plusieurs effets. Les effets peuvent être définis depuis la fenêtre de description de l'élément, onglet "Style". Les effets peuvent être définis :
  • sur l'élément conteneur qui gère le plan. Il suffit d'ajouter un effet avec un déclencheur adapté (changement de plan, passage au plan précédent, ...). 6 effets sont disponibles pour gérer le changement de plan : balayage de plan, flou d'enchaînement de plan, fondu de plan (%), recouvrement de plan, repliement de plan, retournement de plan.
  • sur le champ présent dans le plan. Il suffit d'ajouter un effet avec un déclencheur d'apparition (affichage du plan où se situe le champ) ou de disparition (affichage d'un autre plan).

Affichage différé

Par défaut, lorsque le navigateur charge la page, il la charge complètement, avec le contenu complet de chacun des plans. Dans une application où tout est présent dans une seule et même page, ce fonctionnement peut ralentir considérablement l'affichage de la page.
Pour éviter ce ralentissement, les plans peuvent être chargés en différé : le contenu d'un plan ne sera effectivement chargé que lorsqu'une demande d'affichage explicite du plan sera faite :
  • soit au chargement de la page si le plan est affiché par défaut,
  • soit lors du changement de plan via la propriété Plan.
Pour activer le chargement différé des plans, il suffit de cocher l'option "Chargement différé du contenu des plans" depuis l'onglet "UI" de la description de l'élément conteneur. Cette option active deux nouveaux événements "Chargement différé d'un plan", disponibles depuis l'éditeur de code :
  • un événement serveur AJAX appelé lorsqu'un plan va être affiché,
  • un événement navigateur appelé juste après le chargement du plan.
C'est dans ces événements que le chargement effectif des plans doit être programmé.
// -- Evénement "Chargement différé d'un plan (serveur)"
// Selon le plan
SELON MoiMême.Plan
// Tableau de bord
CAS 2
ChargementWidget()
ChargementGraphe()
// Produits
CAS 3
...
FIN

Dans ces deux événements, le numéro du plan qui vient d'être affiché est disponible via la propriété Plan.
Si vous avez besoin de connaître le numéro du plan qui était affiché avant, il suffit de le mémoriser dans une variable.
Pour plus de détails sur les plans, consultez Les plans en WEBDEV.
Utilisation des popups
Pour que l'Internaute ait la sensation d'utiliser une application native, il est possible d'utiliser des boîtes de dialogue, par exemple pour proposer une authentification.
Pour réaliser ce type d'interface (UI) avec WEBDEV, il suffit d'utiliser des pages Popup.
Pour créer une page Popup, sous le volet "Création", dans le groupe "Conteneurs", cliquez sur "Popup".
L'affichage d'une page Popup est effectué depuis un code navigateur, via la fonction PopupAffiche. Cette fonction attend en paramètres le nom de la popup à afficher ainsi que sa position (position spécifique ou relative à un champ).
// Affiche la popup de connexion
PopupAffiche(POPUP_Connexion, popupHautGauche, 0, 0)
Pour plus de détails, consultez Le champ Popup.
Authentification
L'authentification est un élément à ne pas négliger dans une application Web, quelle qu'elle soit.
Bien entendu, l'authentification ne doit pas être effectuée dans un événement navigateur : une personne malveillante pourrait trop facilement contourner l'authentification.
Mais dans une application Single Page App, les retours serveur sont à éviter. Il faut donc passer par un traitement Ajax :
  • soit en utilisant la fonction WLangage AjaxExécute.
    // Vérifie les informations
    // d'authentification de l'utilisateur
    soit sIdentifiantConnexion = AJAXExécute(VérifieInformationsConnexion, SAI_Login, SAI_Motdepasse)
  • soit en activant le mode Ajax du bouton de connexion (si le code de connexion est directement dans le bouton).
Pour éviter que l'utilisateur n'ait à saisir ses identifiants à chaque fois, il est possible de mémoriser son authentification via un cookie.
Au prochain lancement de l'application, si le cookie est présent et correct, l'utilisateur sera automatiquement authentifié et accédera directement au contenu de l'application.
Pour réaliser ce comportement, il suffit de :
  1. Mémoriser un cookie au moment de l'authentification via la fonction CookieEcrit. Bien sûr, le cookie ne mémorise pas directement le nom de l'utilisateur mais une valeur aléatoire générée lorsqu'il s'est connecté et qui a été mémorisée en base.
    //-- Procédure serveur exécutée via AjaxExécute
    PROCÉDURE VérifieInformationsConnexion(...
    sLogin est une chaîne, sMotDePasse est une chaîne)
    // Recherche l'utilisateur en base
    HLitRecherchePremier(Utilisateur, Login, sLogin)
    ...
    // Mémorise un identifiant de connexion
    Utilisateur.GUIDConnexion = DonneGUID()
    HModifie(Utilisateur)
    // L'identifiant est renvoyé (pour être mémorisé)
    RENVOYER Utilisateur.GUIDConnexion
    //-- Code navigateur du bouton de connexion
    // Génère un cookie si besoin
    SI INT_SeSouvenirDeMoi ALORS
    CookieEcrit("Connexion", sIdentifiantConnexion)
    FIN
  2. Dans l'événement de chargement de la page (OnLoad), si le cookie est présent, la popup d'authentification n'est pas affichée et l'utilisateur est directement connecté.
    //-- Code navigateur de chargement de la page
    soit sGUIDConnexion = CookieLit("Connexion")
    // Recherche l'utilisateur
    soit bUtilisateurConnu = AJAXExécute(VérifieIdentifiantConnexion, sGUIDConnexion)
    //-- Procédure serveur
    PROCÉDURE VérifieIdentifiantConnexion(LOCAL sIdentifiantConnexion)
    // Recherche l'utilisateur
    HLitRecherchePremier(Utilisateur, GUIDConnexion, sIdentifiantConnexion)
    RENVOYER HTrouve(Utilisateur)
Conseil : Pour une application Web avec authentification, n'oubliez pas d'utiliser une connexion HTTPS pour que le login et le mot de passe ne puissent pas être interceptés.
Gestion de la touche Back
Quand l'internaute utilise le bouton "Précédent" du navigateur, le navigateur revient à la page précédente. Or, une application Single Page App n'a qu'une page ! Donc, le bouton Précédent renvoie par défaut à la page affichée avant le lancement de l'application !
WEBDEV permet de donner au bouton Précédent le fonctionnement attendu.
  • L'historique de navigation est automatiquement alimenté et intercepte l'événement "Précédent" (ou "Suivant") pour contrôler l'affichage.
  • La page de l'application Single Page App est affichée dans son état précédent.
Cette gestion s'effectue par programmation :
  • grâce aux fonctions :
    NavigateurHistoriqueAjouteAjoute une entrée dans l'historique de navigation en lui associant des données. Ces données seront transmises lors du retour sur cette entrée.
    NavigateurHistoriqueModifieModifie les données de l'entrée courante dans l'historique de navigation. Ces données seront transmises lors d'un retour sur l'entrée courante.
  • grâce à l'événement optionnel "Déplacement dans l'historique de navigation" appelé lorsque l'internaute utilise les boutons "Précédent" ou "Suivant". Pour plus de détails, consultez Evénements optionnels associés aux pages
Version minimum requise
  • Version 22
Commentaires
Cliquez sur [Ajouter] pour publier un commentaire

Dernière modification : 14/06/2023

Signaler une erreur ou faire une suggestion | Aide en ligne locale