WebFront C++23Tome II / CHAPITRE 06
Pour comprendre et contribuer
Ouvrir et fermer une fenêtre
La page peut être la même dans plusieurs moteurs. Le travail nécessaire pour ouvrir sa fenêtre, lui, dépend de la plateforme.
Conventions de notation
Les noms de fonctions, types, commandes, options et fichiers sont composés en chasse fixe, par exemple describe, wf test ou main.cpp. L’italique introduit un terme lors de sa définition. Les blocs de code donnent les extraits à saisir ; le texte qui les précède précise leur emplacement et leurs prérequis.
Ce qui change avec la fenêtre
Supposons que nous voulions afficher notre application dans WKWebView plutôt que dans le navigateur système. Nous souhaitons garder les pages et les fonctions C++ déjà écrites. Ce que nous remplaçons est la pièce chargée d’initialiser le moteur et d’ouvrir la page : le frontend.
Le type frontend::FrontendType décrit ce que cette pièce doit fournir. Les ressources continuent à venir du serveur HTTP et les appels utilisent le même pont.
Activer un moteur dans CMake le rend disponible à la construction. Le choix de l’utiliser reste dans le type de l’application. Ainsi, activer CEF ne change pas silencieusement le navigateur système choisi par webfront::WebFront.
Quand l’ouverture se termine
Pour une fenêtre embarquée, open() reste généralement actif jusqu’à la fermeture. L’action du frontend indique alors au propriétaire s’il doit fermer le serveur. Le navigateur système est différent : l’application ne peut pas observer la fermeture de son onglet de la même façon.
Le chemin d’erreur demande autant d’attention que le chemin normal. Si l’ouverture échoue après le démarrage du serveur, il faut arrêter et joindre celui-ci avant de propager l’exception. Sinon, l’appelant recevrait une erreur alors qu’un thread oublié continuerait à utiliser ses objets.
Les tests de contrat reproduisent ces situations avec des doubles déterministes. Nous pouvons donc étudier l’ordre des opérations sans ouvrir une fenêtre à chaque test.
Le bon thread pour le bon toolkit
Un adaptateur peut satisfaire le concept C++ et rester incorrect à l’exécution. Les signatures de ses fonctions sont peut-être bonnes, mais cela ne dit pas sur quel thread elles sont appelées.
AppKit, GTK et WebView2 ont leurs propres exigences. Avec une fenêtre embarquée, la construction de l’application et l’appel à show() se font sur le thread adapté au moteur, habituellement le principal. Le serveur travaille pendant ce temps sur son contexte.
Lorsque nous ajoutons un adaptateur, nous devons donc suivre son initialisation jusque dans le toolkit, puis examiner son retour et ses exceptions. C’est à cet endroit que se trouvent les contraintes que le compilateur ne peut pas vérifier pour nous.
La page reçoit une autorité
Un callback qui ouvre un fichier ou lance un calcul donne à la page la possibilité de demander cette opération. Le fait que la page soit affichée dans notre fenêtre ne retire pas cette autorité au JavaScript qu’elle exécute.
La politique de contenu limite les origines admises au pont et les navigations embarquées. La vérification d’une archive nous assure que nous avons reçu les octets attendus. Ni l’une ni l’autre ne rend inoffensif du code que nous avons choisi d’exécuter.
Il faut aussi se méfier des raccourcis dans l’identification d’un client. Une adresse loopback peut appartenir à un proxy ou à un tunnel. Pour comprendre pourquoi une connexion reçoit un droit, nous devons suivre le mécanisme d’association ou d’autorisation prévu pour ce droit, jusqu’à sa vérification.
Vérifier sa compréhension