PC SOFT

DOCUMENTATION EN LIGNE
DE WINDEV, WEBDEV ET WINDEV MOBILE

  • Présentation
  • Utilisation des plans
  • 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/iPadApple WatchUniversal Windows 10 AppWindows Mobile
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 "IHM", 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 "IHM" de la description de l'élément conteneur. Cette option active deux nouveaux traitements "Chargement différé d'un plan", disponibles depuis l'éditeur de code :
  • un traitement serveur AJAX appelé lorsqu'un plan va être affiché,
  • un traitement navigateur appelé juste après le chargement du plan.
C'est dans ces traitements que le chargement effectif des plans doit être programmé.
// -- Traitement "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 traitements, 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'IHM 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 traitement 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 le traitement 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.
Versions 23 et supérieures
Gestion de la touche Back
Quand l’internaute utilise la touche "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, la touche Précédent renvoie par défaut à la page affichée avant le lancement de l’application !
A partir de la version 23, WEBDEV permet de donner à la touche 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 :
Nouveauté 23
Gestion de la touche Back
Quand l’internaute utilise la touche "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, la touche Précédent renvoie par défaut à la page affichée avant le lancement de l’application !
A partir de la version 23, WEBDEV permet de donner à la touche 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 :
Gestion de la touche Back
Quand l’internaute utilise la touche "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, la touche Précédent renvoie par défaut à la page affichée avant le lancement de l’application !
A partir de la version 23, WEBDEV permet de donner à la touche 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 :
Version minimum requise
  • Version 22
Commentaires
Cliquez sur [Ajouter] pour publier un commentaire