28-04-2020, 09:23 AM
C'était un test qui:
- Cherche quels dossiers sont des modules (ca se voit car le fichier gnagnaENdpoint.php dans le dossier fait un extends d'une classe spécifique: c'est la "page web" du module)
- Cherche tous les gnagna*Endpoint dans les sous-dossiers de ce module: ce sont les pages d'API du module
- Vérifie que ces pages d'API extends une classe d'API (sinon, ça veut dire que j'ai mis une autre page web dans le module)
- Collecte les réponses possibles de PHP dans ces pages d'API (assez simple: la page return un new ApiResponse('token', data éventuelles): j'ai donc besoin de la liste des tokens possibles pour chaque page d'API)
- Vérifie que chaque page d'API est appelée au moins 1 fois dans le JS de la page web du module, et qu'aucune autre page d'API n'est appelée (d'un autre module ou qui n'existerait pas)
- Vérifie que chacun des tokens apparait 1 fois au moins dans ledit JS aussi (et qu'aucun token "inexistant" n'apparait)
Ca restait assez "magique" dans les deux derniers points niveau validation (regex et pifométrie).
Et surtout, cela m'obligeait à run les tests manuellement pour savoir s'il y a un soucis dans le JS de la page web du module. C'est vite devenu lourd & chiant (je déteste m'interrompre "mentalement" avec ce genre de trucs)
C'est donc devenu une inspection intellij assez similaire:
- Si, dans un JS, on a un const apis = window.dracca.api (en pratique, si un JSStatement du parser JS est un "const definition", avec un nom de variable "apis" qui vaut "window.dracca.api") alors ce JS est le JS d'une page web de module du jeu
- Dans ce cas, on va chercher tous les *Endpoint.php dans les sous-dossier du dossier où ce JS se trouve: ce sont les pages d'API
- L'une des classes de ce PHP (la classe principale en fait) doit extends l'une des classes d'API, sinon, affichage d'une erreur (dans le JS... c'est le seul défaut: comme l'inspection analyse le fichier JS, elle ne peut signaler les erreurs que dans le fichier JS, donc, elle dit dans le fichier JS "le endpoint d'API machinTruc là, il extends pas la classe bidule ou chose" & le "fix" me renvoie vers le fichier PHP correspondant)
- L'inspection collecte alors toute les réponses de cette classe (return new ApiResponse('token',...)) ce qui est aussi moins magique qu'avant vu que je peux utiliser le parser PHP d'intellij (en fait, l'ide a déjà parsé le fichier et je n'ai plus qu'à chercher toutes les NewExpressions qui sont des ClassReference.name = ApiReponse)
- L'inspection génère alors un statement JS, de la forme "const apis = window.dracca.api, URL_DE_LAPI = 'url/de/lapi/', URL_DE_LAPI_AVEC_LE_TOKEN_REPONDU = 'avec le token repondu', URL_DE_LAPI_AVEC_UN_AUTRE_TOKEN_REPONDU = 'avec un autre token repondu',...,URL_DUNE_AUTRE_API = 'url/dune/autre/api/',..."
- L'inspection compare ce statement avec le statement existant pour le "const apis = ....", et s'ils diffère, l'inspection affiche une erreur ("Outdated API list") dont la correction est de remplacer le "const apis=..." existants par le "const apis = ..." généré.
Ainsi, j'ai la liste des URL & tokens répondus en début de fichier JS, qui est nécessairement à jour. Ensuite, c'est l'IDE classique qui va pouvoir dire si toutes ces variables sont bien utilisées 1 fois au moins: si "non", cela signifie que j'ai une API inutile ou un token non géré. Dans le contenu du JS, j'utilise alors ces variables pour appeler/gérer les réponses des APIs. Si un token disparait, la variable disparaitra aussi dans le "consts apis=..." et l'IDE mettra ladite variable en rouge, vu qu'elle n'existe plus.
Ainsi, j'ai les infos nécessaires pour faire une colle potable entre le JS de la page web du module et ses APIs. A voir si, un jour, j'ajoute la partie "data" de cette réponse ou si ce n'est pas franchement critique. Et je pourrai aussi rajouter qu'en faisant ctrl+click sur le nom d'une API ou d'un token, cela me renvoie au fichier PHP de l'api, à la ligne du token.
J'applique déjà ce genre de stratégie de génération de code pour la colle entre la page web & sa procédure SQL: c'est efficace et robuste, donc ça me semble être une bonne approche pour la colle entre le JS de la "single page web" du module et ses APIs (c'est le même principe au fond)
- Cherche quels dossiers sont des modules (ca se voit car le fichier gnagnaENdpoint.php dans le dossier fait un extends d'une classe spécifique: c'est la "page web" du module)
- Cherche tous les gnagna*Endpoint dans les sous-dossiers de ce module: ce sont les pages d'API du module
- Vérifie que ces pages d'API extends une classe d'API (sinon, ça veut dire que j'ai mis une autre page web dans le module)
- Collecte les réponses possibles de PHP dans ces pages d'API (assez simple: la page return un new ApiResponse('token', data éventuelles): j'ai donc besoin de la liste des tokens possibles pour chaque page d'API)
- Vérifie que chaque page d'API est appelée au moins 1 fois dans le JS de la page web du module, et qu'aucune autre page d'API n'est appelée (d'un autre module ou qui n'existerait pas)
- Vérifie que chacun des tokens apparait 1 fois au moins dans ledit JS aussi (et qu'aucun token "inexistant" n'apparait)
Ca restait assez "magique" dans les deux derniers points niveau validation (regex et pifométrie).
Et surtout, cela m'obligeait à run les tests manuellement pour savoir s'il y a un soucis dans le JS de la page web du module. C'est vite devenu lourd & chiant (je déteste m'interrompre "mentalement" avec ce genre de trucs)
C'est donc devenu une inspection intellij assez similaire:
- Si, dans un JS, on a un const apis = window.dracca.api (en pratique, si un JSStatement du parser JS est un "const definition", avec un nom de variable "apis" qui vaut "window.dracca.api") alors ce JS est le JS d'une page web de module du jeu
- Dans ce cas, on va chercher tous les *Endpoint.php dans les sous-dossier du dossier où ce JS se trouve: ce sont les pages d'API
- L'une des classes de ce PHP (la classe principale en fait) doit extends l'une des classes d'API, sinon, affichage d'une erreur (dans le JS... c'est le seul défaut: comme l'inspection analyse le fichier JS, elle ne peut signaler les erreurs que dans le fichier JS, donc, elle dit dans le fichier JS "le endpoint d'API machinTruc là, il extends pas la classe bidule ou chose" & le "fix" me renvoie vers le fichier PHP correspondant)
- L'inspection collecte alors toute les réponses de cette classe (return new ApiResponse('token',...)) ce qui est aussi moins magique qu'avant vu que je peux utiliser le parser PHP d'intellij (en fait, l'ide a déjà parsé le fichier et je n'ai plus qu'à chercher toutes les NewExpressions qui sont des ClassReference.name = ApiReponse)
- L'inspection génère alors un statement JS, de la forme "const apis = window.dracca.api, URL_DE_LAPI = 'url/de/lapi/', URL_DE_LAPI_AVEC_LE_TOKEN_REPONDU = 'avec le token repondu', URL_DE_LAPI_AVEC_UN_AUTRE_TOKEN_REPONDU = 'avec un autre token repondu',...,URL_DUNE_AUTRE_API = 'url/dune/autre/api/',..."
- L'inspection compare ce statement avec le statement existant pour le "const apis = ....", et s'ils diffère, l'inspection affiche une erreur ("Outdated API list") dont la correction est de remplacer le "const apis=..." existants par le "const apis = ..." généré.
Ainsi, j'ai la liste des URL & tokens répondus en début de fichier JS, qui est nécessairement à jour. Ensuite, c'est l'IDE classique qui va pouvoir dire si toutes ces variables sont bien utilisées 1 fois au moins: si "non", cela signifie que j'ai une API inutile ou un token non géré. Dans le contenu du JS, j'utilise alors ces variables pour appeler/gérer les réponses des APIs. Si un token disparait, la variable disparaitra aussi dans le "consts apis=..." et l'IDE mettra ladite variable en rouge, vu qu'elle n'existe plus.
Ainsi, j'ai les infos nécessaires pour faire une colle potable entre le JS de la page web du module et ses APIs. A voir si, un jour, j'ajoute la partie "data" de cette réponse ou si ce n'est pas franchement critique. Et je pourrai aussi rajouter qu'en faisant ctrl+click sur le nom d'une API ou d'un token, cela me renvoie au fichier PHP de l'api, à la ligne du token.
J'applique déjà ce genre de stratégie de génération de code pour la colle entre la page web & sa procédure SQL: c'est efficace et robuste, donc ça me semble être une bonne approche pour la colle entre le JS de la "single page web" du module et ses APIs (c'est le même principe au fond)