L'éditeur d'états de WINDEV et WEBDEV propose une option d'intégration du code compilé au niveau de chaque état :
Lorsqu'elle est cochée, l'option permet d'avoir des états autonomes qui peuvent être diffusés sans être intégrés à la bibliothèque (.WDL) de l'exécutable. Cette solution était régulièrement utilisée pour fournir des états personnalisés à des utilisateurs finaux des applications, avant qu'il n'existe la version actuelle de "Etats et Requêtes" version utilisateur (appelé également le logiciel Etats & Requêtes).
L'option est donc indispensable lors qu'un état est diffusé en parallèle de l'exécutable, sans être inclus dans la bibliothèque. Mais dans tous les autres cas, il n'est pas conseillé d'activer l'option. En effet sa désactivation permet :
d'optimiser considérablement le temps de compilation des projets qui comportent de nombreux états,
d'exploiter pleinement le mécanisme de "Etats et Requetes" version utilisateur qui sait extraire le code lors de la personnalisation d'un état qui est inclus dans un exécutable (valable à partir de la version 62h de WINDEV et WEBDEV 18).
A noter qu'avant la version 62h de WINDEV et WEBDEV 18, tous les états créés avaient l'option "Intégrer le code compilé" active par défaut. A partir de la version 62h, les nouveaux états créés n'ont plus l'option cochée (les états existants ne sont pas modifiés, ils gardent donc l'option).
Une information importante à garder à l'esprit : elle s'applique intégralement aux composants externes utilisés par les applications, et les sites.
Ainsi son appel dans un projet, permet d'avoir dans le .WLOG obtenu les actions effectuées par l'utilisateur de l'application dans les traitements du projet lui-même, mais également dans les traitements des composants externes qui sont appelés par le projet.
Exemple type dans lequel cette fonctionnalité est extrêmement pratique, la mise en production d'un site web avec une possibilité de paiement sécurisé. En effet, il est très simple dans un site WEBDEV d'ajouter des fonctions de paiement en ligne grâce au composant WW_PaiementSecurise. La mise en production peut cependant être ralentie le temps d'adapter les droits ou autre. Dans ce cas il suffit de :
appeler DBGActiveLog dans le projet du site avant de faire appel au composant de paiement,
récupérer le WLOG obtenu sur le serveur,
ouvrir le .WLOG dans le projet WEBDEV du site pour vérifier les appels du composant,
ouvrir le .WLOG dans le projet source du composant pour vérifier les traitements exécutés.
La seule limitation de ce principe concerne les codes sources, il faut bien sûr disposer du code source du composant externe afin de pouvoir charger ses données d'exécution. Tous les composants inclus en exemple avec WINDEV et WEBDEV disposent du code source :
Pour les sites qui ne sont pas destinés à un navigateur précis, cela fait un gain très appréciable pour les phases de tests. En effet WEBDEV parvient à masquer la majeure partie de la complexité invraisemblable, parfois à la limite de l'inextricable, de la difficulté à obtenir un rendu identique des pages dans tous les navigateurs. Mais on ne peut cependant pas éviter le test avec tous les navigateurs, afin de s'assurer des résultats, notamment lorsqu'il y a des changements de versions et/ou de navigateurs.
Cette évolution du navigateur Opéra est donc positive, il profitera d'emblée de nouvelles fonctionnalités liées au moteur de rendu Webkit, et fera "affichage commun" avec Chrome.
Sur le sujet du rendu des pages, il faut également souligner qu'en plus de prendre en charge les particularités des navigateurs, WEBDEV ne limite pas les possibilités de création. Il est donc toujours possible de créer un page ayant une combinaison de champs ou d'options de génération qui ne sont déjà adaptés à une particularité d'un navigateur. Comme évoqué dans un précédent billet, lorsqu'une différence de rendu apparaît dans un navigateur, présentez nous le cas par le choix "Requête au Support Technique" du bouton "Aide" du volet "Accueil" du ruban. Joignez bien une page de mise en évidence tirée d'un des exemples livrés (surtout pas juste une copie d'écran), en précisant la version du navigateur concerné. Il est ainsi possible de soumettre le cas à l'équipe Développement, qui peut le plus souvent adapter le code HTML et/ou javascript généré au navigateur si :
il ne s'agit pas d'une anomalie connue du navigateur, puisque qu'une adaptation dans ce cas pourrait provoquer des anomalies dans la prochaine version corrigée du navigateur,
il ne s'agit pas d'un cas lié à une technologie trop ancienne d'un navigateur (mode de compatibilité d'un navigateur pour les anciens codes : HTML 5 est recommandé maintenant),
Les stations comme les serveurs disposent maintenant d'une RAM importante. Mais surprise, comme souvent lorsqu'il y a abondance, il est toujours aussi fréquent de manquer de RAM.
Ce n'est pas surprenant, avec les systèmes d'exploitation 64 bits, les processus ne sont pas limités pour l'allocation de la mémoire. En 32 bits ils ne pouvaient pas dépasser 2 Go, en théorie, ce qui pouvait constituer un garde fou !
Windows lui-même est concerné, son propre cache peut occuper un espace très conséquent, limitant ainsi la RAM disponible pour les applications et services.
Sur ce sujet, la LST 93 dispose d'un utilitaire très pratique pour retrouver la RAM, j'ai pu voir des serveurs de données se "transformer en avion de chasse" grâce à lui :
D'autre part il existe un utilitaire très pratique qui permet de voir à un instant donné la RAM utilisée : RAMMap. Il détaille l'utilisation de la mémoire, et permet de voir les fichiers qui sont en caches. Voici des liens très utiles sur ce point :
Dans une application Android affichant des images, il est possible de demander un chargement en "tâche de fond" (cf. volet "Détail" de la description des images) :
Il est important de bien positionner cette option afin d'obtenir une bonne fluidité du rendu.
Lorsque les images ont une taille importante, il est recommandé de cocher l'option. De cette manière l'affichage de l'IHM est immédiate, le chargement des images se faisant en arrière plan.
A l'inverse lorsque les images ont une taille réduite (élément d'interface comme des pictogrammes...), il est préférable de ne pas cocher l'option de chargement en tâche de fond. En effet dans ce cas, le fait de différer l'affichage de l'image provoque un effet visuel de clignotement, ou scintillement.
Attention, lorsque les images sont dans une zone répétée, le chargement en tâche de fond est systématique quelque soit la valeur de la coche. Si une application WINDEV Mobile 18 doit utiliser une zone répétée avec des images réduites, et qu'un effet d'affichage se produit, il est possible d'utiliser une mise à jour de WD180ANDROID.JAR, proposée dans les ressources pratiques (lien "Liste des modules correctifs disponibles"). Elle permet d'avoir la prise en compte du chargement en tâche de fond dans tous les cas, y compris les zones répétées.
Une nouveauté des versions 18 de WINDEV et WEBDEV permet d'obtenir le source XML complet de la réponse d'un webservice, c'est le nouveau type wsRéponse.
La version 180063 (disponible depuis le 16/7/2013 dans l'espace téléchargement), complète encore ce principe, avec un nouveau type wsRequête. A l'inverse ce type va permettre d'avoir le source XML complet de la requête envoyée pour la consommantion du webservice.
La fonction SOAPPrépare donne déjà l'information dans le cas général, mais pas lorsque le webservice nécessite :
des données spécifiques dans son entête (SOAPAjouteAjouteEntête),
ou une assertion (SOAPAjouteAssertionSAML) dans le cas de Sesam Vitale par exemple.
En pratique, l'appel traditionnel d'une fonction :
La fonction XMLExécuteXPath permet l'exécution d'un requête XPATH sur un document XML. C'est intéressant pour la recherche d'une information contenue dans le document, afin d'éviter de programmer un parcours complet. Dans tout autre cas, l'utilisation du type XMLDocument reste très avantageuse pour le traitement de données XML.
Voici un exemple complet qui peut être copié/collé dans un bouton pour expérimentation. Il viendra sous peu compléter les exemples déjà présents dans l'aide) :
XMLSuivant("DocXML") FIN // Parcours terminé, on termine la requête XMLAnnuleRecherche("DocXML")
FIN XMLTermine("DocXML") SINON Erreur(ErreurInfo()) FIN
A noter avec cette solution, le parcours TANTQUE XMLTrouve ..., permet uniquement de se déplacer dans les résultats de la requête. Pour chaque itération, il n'est pas possible de se déplacer dans l'arborescence du document, même avec une mémorisation de la position avec XMLSauvePosition.
Le passage d'un projet existant en UNICODE pour son exécution a été abordé dans un précédent billet, pour le cas des échanges entre différentes plate-formes :
Mais indépendamment des échanges de données entre, par exemple, un webservice et une application sous Android ou iOS, des cas similaires peuvent se produire tout en restant sur une plate-forme unique. Voici un exemple abordé ce jour dans une demande reçue par notre support :
une application WINDEV exécutée sous Windows avait initialement ses chaînes en exécution en ANSI.
cette application avait des données cryptées mémorisées sur disque dans des fichiers. Exemple :
sDonnées est une chaîne="contenu crypté" sPasse est une chaîne="motpasse" Cryptage est un Buffer Cryptage =Crypte(sDonnées,sPasse,crypteSécurisé,encodeAucun) fSauveBuffer("c:\démo.txt",Cryptage)
pour son internationalisation cette application a été recompilée en UNICODE
le traitement initial de décryptage des données reste parfaitement opérationnel :
sPasse est une chaîne="motpasse" Cryptage est un Buffer Cryptage =fChargeBuffer("c:\démo.txt") Info(Décrypte(Cryptage,sPasse,crypteSécurisé,encodeAucun))
cependant l'affichage des données ne donne plus le résultat attendu, puisque l'application est configurée pour afficher de l'UNICODE.
la solution consiste donc pour retrouver l'information initiale à "forcer" l'application à utiliser l'ANSI pour montrer les données. Par exemple : Info(AnsiVersUnicode(Décrypte(Cryptage,sPasse,crypteSécurisé,encodeAucun),alphabetAnsi))
ou :
sDonnées est une chaîne ANSI =Décrypte(Cryptage,sPasse,crypteSécurisé,encodeAucun) Info(sDonnées)
Le principe nécessaire à la conservation d'un "contexte" pour l'Internaute qui navigue dans un site dynamique WEBDEV a été détaillé dans le billet suivant du blog :
Suite à une remontée au support sur une apparente consommation excessive de CPU/processeur sur un serveur Web au niveau du module WDAWP.EXE (WD170AWP.EXE en version 17, WD180AWP.EXE en version 18), j'ajoute ce billet qui permettra d'avoir le cheminement complet du traitement nécessaire aux requêtes des utilisateurs d'un site dynamique. Car comme toujours, lorsque l'on connaît le principe complet, il est bien plus facile de rechercher l'origine d'un comportement imprévu !
Dans le billet relatif aux sessions nécessaires à la gestion de chaque connexion, le module WDSESSION.EXE (WD170SESSION.EXE en version 17, WD180SESSION.EXE en version 18), a été détaillé. C'est ce module qui fait la majeure partie du travail sur le serveur, notamment toutes les exécutions des codes serveurs du site. Le rôle de WD180AWP.EXE bien que totalement indispensable est donc minime : il s'agit uniquement d'un programme "lanceur" qui va transformer une demande HTTP reçue par le serveur Web (IIS, Apache...). En résumé :
l'internaute demande l'accès à un site dynamique : http://MonSite ou http://serveur/WD180AWP.EXE/WD180AWP.EXE/CONNECT/MonSite
le module WD180AWP.EXE fait le lancement d'une nouvelle instance de WD180SESSION.EXE si il s'agit d'une nouvelle connexion, ou passe les paramètres reçus du serveur Web à une instance WD180SESSION.EXE existante, dans le cas d'une demande pour une connexion existante,
le module WD180AWP.EXE attend la réponse de WD180SESSION.EXE, puis se termine immédiatement.
Si à un instant donné par le gestionnaire de processus on observe une persistance en mémoire d'un WD180AWP.EXE, avec une importante activité du processeur :
ce n'est pas directement que le module est en train d'exécuter un traitement. En effet, c'est uniquement un lanceur, il ne peut qu'être en attente du lancement d'une instance de WD180SESSION.EXE. Windows montre dans ce cas une utilisation complète du processeur, ou du coeur, si ce dernier n'est pas sollicité par d'autres processus. Mais il s'agit d'une attente non prioritaire, le processeur reste libre si d'autres processus l'utilisent.
c'est donc un module WD180SESSION.EXE qui ne peut pas être lancé, ou qui ne répond plus si un traitement trop long lui a été demandé.
A noter qu'un échec complet du lancement de WD180SESSION.EXE par WD180AWP.EXE peut se solder par le retour ERR_LAUNCH_FAILED au niveau du navigateur.
d'un code serveur trop coûteux en temps et/ou en ressource qui devrait être déporté en back-office,
d'un code en erreur pour lequel un timeout est trop long (par exemple la perte d'une connexion avec un serveur de données auquel le code serveur tente de se connecter),
trop de sessions sont lancées (ressources nécessaires pour une session * nombre de connexions > ressources disponibles sur le serveur) ...
Dans tous les cas une surveillance des WD180SESSION.EXE via le gestionnaire de processus sur le serveur permet de comprendre ce qu'il se passe, en recoupant si besoin avec les remontées de l'observateur d'événement de Windows, et/ou les logs des sessions.
Le WLangage propose l'inférence de typeà partir de la version 18. Par exemple le code :
sPile est une chaîne sPile =dbgInfo(dbgPile)
peut avantageusement être remplacé par :
soitsPile =dbgInfo(dbgPile)
Avantages :
simplicité extrême pour les déclarations de types simples,
praticité pour la récupération de types complexes ou de membres, retour de fonction,
moins de caractères frappés dans l'éditeur de code,
suppression du risque d'erreur de type lors de la déclaration,
plus lisible (mais là c'est presque une question de goût/habitude personnel).
Inconvénients : moins lisible lorsque l'on s'éloigne du code de déclaration, si on n'utilise pas une charte de programmation avec un pré-fixage du nom des variables par le type.
Une requête SQL peut mettre en action de nombreuses tâches : parcours, filtrage, tri, union, sélection... La fonction EXPLAIN permet d'obtenir le détail du plan d'exécution d'une requête (cf. nouveauté 124 de HFSQL).
Voici un exemple d'utilisation, à partir d'un cas concret. Avec une requête SQL "NATURAL JOIN" je tente d'obtenir toutes les rubriques des fichiers CLIENT et COMMANDE reliés par une rubrique NumClient. Le code SQL de ma requête est des plus simple, directement saisi dans l'éditeur de requêtes :
A l'exécution de la requête, en test depuis l'éditeur, ou avec la fonction HExecuteRequete, aucune ligne ne remonte. Pourtant il y a bien des enregistrements qui vérifient l'égalité CLIENT.NumClient = COMMANDE.NumCommande. Un EXPLAIN de la requête exécuté via le centre de contrôle HFSQL, ou directement dans le code de clic d'un bouton de test permet de tout de suite comprendre le résultat obtenu :
// Code de clic sur un bouton de test ... ReqExplain est une Source de Données
Le résultat obtenu dans le presse-papier avec ce code :
L'explication des filtres permet immédiatement de comprendre. Il y a bien la rubrique "NumClient" qui a été utilisée pour mettre en correspondance les enregistrements des deux fichiers, mais également la rubrique "Observations". En effet par définition le "NATURAL JOIN" utilise le nom de toutes les rubriques communes aux tables pour effectuer la jointure, j'avais oublié la présence de cette rubrique...
L'exemple WD Analyseur Explain HFSQL inclus avec WINDEV (dossier \Exemples\Exemples didactiques\) permet d'obtenir une représentation graphique du résultat en plus de la description XML renvoyée par défaut.
Conclusion :
pratique le EXPLAIN qui montre tout de suite ce qui est fait lors d'une interrogation,
bien vérifier les rubriques des tables avant un NATURAL JOIN. Et surtout, après l'ajout de rubriques par la suite, bien vérifier si il n'y a pas un impact sur les jointures naturelles des requêtes existantes (personnellement, j'évite les NATURAL JOIN pour cette raison).
iOS7 est maintenant disponible pour les Développeurs, et sera en téléchargement officiel à partir du 18 septembre 2013. Une version de Xcode lui a été adaptée, la 5. Apple propose ainsi une mise à jour majeure de son système, qui impacte tous les développements pour iPhone, iPad et iPod. Voici les réponses aux premières questions que soulèvent ces nouvelles versions.
Les applications WINDEV Mobile 18 existantes peuvent-elles être déployées sous iOS 7 ?
Les applications existantes qui sont déployées via l'Apple Store doivent également être recompilées, afin d'être soumises à nouveau à Apple.
Quelle version de Xcode utiliser pour recompiler une application WINDEV Mobile 18 afin qu'elle s'exécute sous iOS 7 ?
Les versions 4.6.3 et 5 de Xcode peuvent être utilisées. Attention cependant, en fonction de la version de Xcode utilisée pour la compilation, une même application n'a pas la même taille écran sous iOS 6 et iOS 7 (nouvelle gestion de la barre système de iOS 7, indépendante de WINDEV Mobile) :
pour que l'application s'exécute sans modification, il est donc impératif de recompiler avec Xcode 4.6.3.
pour recompiler avec Xcode 5, il faut modifier les fenêtres maximisées afin de laisser de l'espace pour la barre système. Ce point est détaillé dans la FAQ 8007 de notre site.
Si besoin les différentes versions de Xcode sont disponibles sur le site Apple :
Le GDS (Gestionnaire de Sources) de WINDEV, WEBDEV et WINDEV Mobile permet le partage des projets entre Développeurs, tout en conservant un historique complet de toutes les modifications de tous les éléments (fenêtres, pages, états, requêtes, classes ...) des projets.
Cet historique complet est extrêmement pratique, car il permet de revoir à tout moment l'interface et/ou le code d'une précédente version. Il est accessible :
d'un simple clic sur le bouton "Historique" du volet "GDS" du ruban.,
par un clic droit sur l'élément dans l'Explorateur de projet.
Par défaut l'historique proposé permet de comparer la version en cours de l'élément du projet, avec ses précédentes versions. Par exemple lorsque l'on demande l'historique d'une fenêtre, le bouton "Comparer" permet de voir toutes ses différences avec ses précédentes versions ("faire un diff" !).
Mais l'historique d'un élément propose une autre possibilité, celle de comparer deux anciennes versions. Il suffit pour cela d'effectuer une sélection multiple (Ctrl+clic), afin de sélectionner les deux versions à comparer. Une miniature pour chaque version est alors montrée, et le bouton "Comparer" permet cette fois-ci d'avoir les différentes entre ces deux versions :
Les iPhone, iPad et iPod sous iOS sont mis à jour par l'application Apple iTunes. Une fois le périphérique connecté, il suffit de cliquer sur "Rechercher les mises à jour", afin d'avoir la dernière version disponible du firmware.
En phase de test, il peut être nécessaire de changer la version de iOS d'un périphérique, mais pour une version plus ancienne que celle installée. Par exemple ce jour je récupère deux iPhone 4 équipés de iOS 7, je souhaite en conserver un avec iOS 7, mais avoir le second sous iOS 6. Voici une façon de procéder :
Rechercher la version du firmware désiré, via Google. Il suffit de spécifier l'appareil, la version de iOS, et "ipsw", qui correspond à l'extension des fichiers contenant le système complet :
Une fois le téléchargement du bon Firmeware effectué, aux alentours de 1 Go, il suffit de connecter le périphérique, de lancer iTunes et de cliquer sur "Rechercher les mises à jour", mais en pressant la touche Shift sur un PC, "Commande" sur un Mac. Un sélecteur de fichiers est ouvert, il suffit de sélectionner le fichier".ipsw" téléchargé précédemment. iTunes fait le reste, secondé à la fin par l'assistant de démarrage de l'iPhone, l'iPad ou l'iPod.
A noter qu'il s'agit d'un processus entièrement Apple, il ne s'agit pas d'un domaine couvert par notre support. Mais ayant eu à faire la manipulation plusieurs fois, je tenais à la partager.
L'assistant d'installation de WEBDEV permet de déployer très simplement un site dynamique sur une plate-forme hébergée dans le CLOUD des applications PC SOFT :
Lorsque le déploiement est fait, le site peut être lancé directement en utilisant l'adresse de la plat-forme :
ou : http://<adresse-nom-plate-forme>/ si le site "SITE_TEST" a été déclaré dans le tableau de bord de la plate-forme comme site par défaut.
Il reste alors à associer le domaine au site lui-même, afin que l'accès au site soit possible via "www.monsite.com". Pour cela différentes solutions sont possibles, en fonction du but à atteindre, et des possibilités proposées par l'hébergeur du domaine.
Cas 1 : on souhaite un accès au site via son domaine "www.monsite.com", mais une fois le site lancé, la navigation doit se faire en conservant l'url complète du site dynamique avec ses informations de contexte :
Il suffit d'utiliser la méthode de redirection d'url proposée par l'hébergeur du domaine :
si un seul site est installé sur la plate-forme, il suffit de le déclarer comme site par défaut dans la configuration de la plate-forme dans le tableau de bord de PCSCLOUD. Le domaine pointera ainsi directement sur la plate-forme : http://<adresse-nom-plate-forme>
si plusieurs sites sont installés sur la plate-forme, la redirection doit préciser le site à lancer : http://<adresse-nom-plate-forme>/SITE_TEST.
Illustration sur un domaine hébergé par 1&1 :
Cas 2 : on souhaite un accès au site via son domaine "www.monsite.com", et ce domaine doit persister dans la barre d'adresse du navigateur, durant toute la navigation (le contexte est masquée de la barre d'adresse) :
La méthode à appliquer sera dépendante des possibilités proposées par l'hébergeur du domaine. Si ce dernier propose l'utilisation d'un frameset pour inclure le site, il suffit uniquement de spécifier dans son paramétrage l'adresse du site à inclure, par exemple : http://<adresse-nom-plate-forme>/SITE_TEST
Illustration sur un domaine hébergé par 1&1 :
Si l'hébergeur propose uniquement une redirection d'url, une action supplémentaire sera nécessaire sur le site :
dans le site à déployer sous WEBDEV, via l'Explorateur de projet, ne pas indiquer de "Page d'accueil",
dans la configuration du domaine, chez son hébergeur, effectuer la redirection vers le site : http://<adresse-nom-plate-forme>/
dans le tableau de bord de la plate-forme, chez PCSCLOUD, indiquer SITE_TEST comme site par défaut,
sur le poste de développement, créer un fichier texte dans le répertoire du projet nommé index.htm, dont le contenu sera identique à celui proposé dans l'aide de WEBDEV, pour afficher un site en masquant son adresse complète.
dans la configuration de la plate-forme, utiliser le lien "Administrateur WEBDEV",
dans l'administrateur sélectionner le site "SITE_TEST" dans le volet "Sites",
utiliser le bouton "Explorer le répertoire",
dans le dossier "SITE_TEST_WEB", utiliser le bouton "Envoyer un fichier" afin de placer le fichier index.htm créé précédemment à cet emplacement :
Attention, si une page d'accueil statique avait été ajoutée dans le projet, supprimer toujours par "Explorer le répertoire" dans "SITE_TEST_WEB" et dans "SITE_TEST_WEB\FR" les fichiers index.html, accueil.htm, index.awp, accueil.awp.
Dans les deux cas, que le frameset soit dans la configuration de l'hébergeur du domaine, ou sur la plate-forme PCSCLOUD, on aura un accès direct via "www.monsite.com", tout en conservant cette unique adresse dans le navigateur durant la navigation dans les pages dynamiques du site.
Si dans un cas particulier la solution du frameset ne peut pas être appliquée (pas de redirection par frame chez l'hébergeur du domaine, pas de solution d'accès aux fichiers du site chez son hébergeur) il est également possible d'utiliser les solutions suivantes :
Cas 1 : en conservant les adresses complètes des pages dans la barre d'adresse du navigateur :
créer une nouvelle page dans le site dynamique,
indiquer le type statique dans sa description,
dans l'explorateur de projet par un clic droit sur la page, indiquer "Page d'accueil",
dans le code de chargement navigateur onload de la page, ajouter : SiteDynamiqueAffiche("TEST_SITE")
dans le tableau de bord de PCSCLOUD, indiquer qu'il s'agit du site par défaut.
Cas 2 : en masquant les adresses des pages dans la barre d'adresse du navigateur :
créer une nouvelle page dans le site dynamique,
indiquer le type statique dans sa description,
dans l'explorateur de projet par un clic droit sur la page, indiquer "Page d'accueil",
ajouter un champ iframe couvrant toute la page,
préciser pour ce champ iFrame un ancrage à 100% du navigateur en largeur et en hauteur,
indiquer dans la description de l'iframe l'url de lancement du site dynamique avec le nom ou l'adresse de la plate-forme : http://<adresse-nom-plate-forme>/WD180AWP/WD180Awp.exe/CONNECT/SITE_TEST
déployer le site,
dans le tableau de bord de PCSCLOUD, indiquer qu'il s'agit du site par défaut.
A noter sur le thème général des noms de domaines, pour éviter de rechercher une anomalie lorsqu'il n'y en a pas :
les actions faites dans la configuration d'un domaine chez son hébergeur peuvent ne pas être instantanée. Un délai de propagation dans les DNS peut être nécessaire.
les caches des navigateurs peuvent ne pas voir un changement de DNS qui vient d'être fait.
Lorsqu'un changement est fait dans la redirection d'un nom de domaine, avant de nouveaux tests il faut donc bien penser à vider les caches du navigateur, et/ou attendre la propagation du changement (surtout si l'hébergement du site n'est pas sur le même continent que le test).
