de manière générale le nombre de request me donne mal au crâne je vais check ton db et class mais je me demande si y'a pas moyen de polish tout ça https://www.youtube.com/watch?v=Vy8moBcKVIM&pp=ygUKcG9saXNoIGNvdw%3D%3D
C'est une genre de sous partie de RegRequest servant un peu de "résumé", je l'ai crée pour palier au fait que quand on arrive sur le menu de séléction des demandes d'inscriptions, je veux les lister, ce faisant je n'ai pas besoin de load toutes les informations de toutes les demandes d'inscription, j'ai juste besoin de quelques attributs pour les lister.
C'est une genre de sous partie de RegRequest servant un peu de "résumé", je l'ai crée pour palier au fait que quand on arrive sur le menu de séléction des demandes d'inscriptions, je veux les lister, ce faisant je n'ai pas besoin de load toutes les informations de toutes les demandes d'inscription, j'ai juste besoin de quelques attributs pour les lister.
Je pense que tu ne devrais pas avoir un endpoint par type de requests mais plustot un /request général et puis des dérivation de cette requetes pour les différents types. comme expliqué dans un commentaire ci-dessous.
Je pense que tu ne devrais pas avoir un endpoint par type de requests mais plustot un /request général et puis des dérivation de cette requetes pour les différents types. comme expliqué dans un commentaire ci-dessous.
Est-ce vraiment nécéssaire de faire des ré-ré register ? est-ce que ca ne serais pas une sous-classe de register avec peut être un bool pour dire si c'est la première fois ou non ?
Est-ce vraiment nécéssaire de faire des ré-ré register ? est-ce que ca ne serais pas une sous-classe de register avec peut être un bool pour dire si c'est la première fois ou non ?
Non, cela impliquerait une redondance d'informations. Quand un étudiant se réinscrit on a pas besoin de restocker son nom, son prénom, son adresse, ...
On les a déja avec le matricule.
Non, cela impliquerait une redondance d'informations. Quand un étudiant se réinscrit on a pas besoin de restocker son nom, son prénom, son adresse, ...
On les a déja avec le matricule.
Le fait de metre des end-points n'a rien à voir avec le stockage d'information tho. ton end point peut être clair et concis tandis que ta base de données et ton backend s'occupent de chercher les infos ou tu veux. en clair tu ne dois pas suivre ce qui est fait dans class et db
Le fait de metre des end-points n'a rien à voir avec le stockage d'information tho. ton end point peut être clair et concis tandis que ta base de données et ton backend s'occupent de chercher les infos ou tu veux. en clair tu ne dois pas suivre ce qui est fait dans class et db
Same, est-ce que tu ne ferais pas un
(GET) /requests -> array of all requests
(GET) /requests/{type} -> array of all requests of
et pour les post c'est juste un paramètre ? c'est moins verbeux et plus lisible ?
Same, est-ce que tu ne ferais pas un
(GET) /requests -> array of all requests
(GET) /requests/{type} -> array of all requests of <type>
et pour les post c'est juste un paramètre ? c'est moins verbeux et plus lisible ?
Je suis d'accord avec toi ! Mais comment spécifier le type de retour qui change en fonction du paramètre {type} ducoup ? Et je n'ai pas compris la deuxième partie de la question
Je suis d'accord avec toi ! Mais comment spécifier le type de retour qui change en fonction du paramètre {type} ducoup ? Et je n'ai pas compris la deuxième partie de la question
Perfecto en vrai.
J'ai fait quelques proposition de changement mais je vais approve à partir de maintenant car pour moi c'est good.
(Je suis pas fan des nom du genre RRRequest mais en soit c'est toi qui vois)
Perfecto en vrai.
J'ai fait quelques proposition de changement mais je vais approve à partir de maintenant car pour moi c'est good.
(Je suis pas fan des nom du genre RRRequest mais en soit c'est toi qui vois)
je ne sais pas si c'est l'intention, mais tu n'as pas la possibilité de faire un fetch de toutes les requests.
le plus simple est de changer l'endpoint à /Requests
et le paramètre tu peux le mettre à in: query. en required: false
je ne sais pas si c'est l'intention, mais tu n'as pas la possibilité de faire un fetch de toutes les requests.
le plus simple est de changer l'endpoint à `/Requests`
et le paramètre tu peux le mettre à `in: query`. en `required: false`
si tu appliques les précédents commentaire tu as soit le choix de laisser le post dans /Requests/{type} soit de le mettre avec /Requests et dans ce cas il suffit de mettre le type en paramètre dans requestBody ou dans query (je pense que requestBody serait mieux dans le cas présent)
si tu appliques les précédents commentaire tu as soit le choix de laisser le post dans `/Requests/{type}` soit de le mettre avec `/Requests` et dans ce cas il suffit de mettre le type en paramètre dans `requestBody` ou dans `query` (je pense que requestBody serait mieux dans le cas présent)
pour le patch ça pose pas de problème mais pour le post tu ne peux pas demander d'envoyer un id car il n'y a pas encore d'id.
Une solution serait d'enlever l'id dans les schèma dans le bas du document et des les ajouter explicitement quand tu peux (GET, PATCH -> si id peut être modifié)
pour le patch ça pose pas de problème mais pour le post tu ne peux pas demander d'envoyer un id car il n'y a pas encore d'id.
Une solution serait d'enlever l'id dans les schèma dans le bas du document et des les ajouter explicitement quand tu peux (GET, PATCH -> si id peut être modifié)
tonitch marked this conversation as resolved
LeoMoulin
marked the pull request as work in progress 2023-12-13 08:24:55 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
tonitch
Maxime
Bon les gars je vais pas passer par 4 chemins :
Zǎoshang hǎo zhōngguó xiànzài wǒ yǒu BING CHILLING 🥶🍦 wǒ hěn xǐhuān BING CHILLING 🥶🍦 dànshì sùdù yǔ jīqíng 9 bǐ BING CHILLING 🥶🍦 sùdù yǔ jīqíng sùdù yǔ jīqíng 9 wǒ zuì xǐhuān suǒyǐ…xiànzài shì yīnyuè shíjiān zhǔnbèi 1 2 3 liǎng gè lǐbài yǐhòu sùdù yǔ jīqíng 9 ×3 bùyào wàngjì bùyào cu òguò jìdé qù diànyǐngyuàn kàn sùdù yǔ jīqíng 9 yīn wéi fēicháng hǎo diànyǐng dòngzuò fēicháng hǎo chàbùduō yīyàng BING CHILLING 🥶🍦zàijiàn 🥶🍦
@@ -369,0 +390,4 @@summary : Get all the data composing a register requesttags :- RegisterRequests- StudentRegistrationPAS BIEN VAIS TE FRAPPER AVEC MA GROSSSE BATTE
tous tes Extensions tags pas bons
@@ -369,0 +413,4 @@summary: Change the state of a register requesttags:- RegisterRequests- StudentRegistrationPAS studentRegistrattion
de manière générale le nombre de request me donne mal au crâne je vais check ton db et class mais je me demande si y'a pas moyen de polish tout ça https://www.youtube.com/watch?v=Vy8moBcKVIM&pp=ygUKcG9saXNoIGNvdw%3D%3D
@@ -369,0 +542,4 @@items :$ref : '#/components/schemas/SSRequest'post :summary: Add a new scholarship requestpeut-être rajouter user dans les tags ?
les tags sont fixs !
@@ -462,0 +886,4 @@description: Path of the pdf containing the user's foreigner certificate (optionnal)State:type : stringà quoi sert RegRequests ?
C'est une genre de sous partie de RegRequest servant un peu de "résumé", je l'ai crée pour palier au fait que quand on arrive sur le menu de séléction des demandes d'inscriptions, je veux les lister, ce faisant je n'ai pas besoin de load toutes les informations de toutes les demandes d'inscription, j'ai juste besoin de quelques attributs pour les lister.
Je pense que tu ne devrais pas avoir un endpoint par type de requests mais plustot un /request général et puis des dérivation de cette requetes pour les différents types. comme expliqué dans un commentaire ci-dessous.
@@ -369,0 +444,4 @@content:application/x-www-form-urlencoded:schema:$ref: '#/components/schemas/RegRequest'Ici en utilisant le ref, l'id est présent. sauf que tu ne peux pas post avec un id vu qu'il est généré par le post.
@@ -369,0 +447,4 @@$ref: '#/components/schemas/RegRequest'responses:'201':description: New student createdNew Student created -> Register request created ?
@@ -369,0 +451,4 @@'401':$ref: '#/components/responses/UnauthorizedError'/ReRegRequest:Est-ce vraiment nécéssaire de faire des ré-ré register ? est-ce que ca ne serais pas une sous-classe de register avec peut être un bool pour dire si c'est la première fois ou non ?
Non, cela impliquerait une redondance d'informations. Quand un étudiant se réinscrit on a pas besoin de restocker son nom, son prénom, son adresse, ...
On les a déja avec le matricule.
Le fait de metre des end-points n'a rien à voir avec le stockage d'information tho. ton end point peut être clair et concis tandis que ta base de données et ton backend s'occupent de chercher les infos ou tu veux. en clair tu ne dois pas suivre ce qui est fait dans class et db
@@ -369,0 +526,4 @@description: State modified'401':$ref: '#/components/responses/UnauthorizedError'/SSRequest:Same, est-ce que tu ne ferais pas un
(GET) /requests -> array of all requests
(GET) /requests/{type} -> array of all requests of
et pour les post c'est juste un paramètre ? c'est moins verbeux et plus lisible ?
Je suis d'accord avec toi ! Mais comment spécifier le type de retour qui change en fonction du paramètre {type} ducoup ? Et je n'ai pas compris la deuxième partie de la question
EDIT : c'est fait
@@ -462,0 +854,4 @@properties:id:type : integerName :Vu que ce sont les mêmes données qu'un utilisateur y'a moyen de faire
C'est pas les mêmes ! Pas de regNo dans RegRequest !
@@ -368,0 +438,4 @@'401':$ref: '#/components/responses/UnauthorizedError'/Requests/{type}{id}:Il manque un /
/Requests/{type}/{id}Perfecto en vrai.
J'ai fait quelques proposition de changement mais je vais approve à partir de maintenant car pour moi c'est good.
(Je suis pas fan des nom du genre RRRequest mais en soit c'est toi qui vois)
@@ -368,0 +406,4 @@parameters:- name: typein: pathje ne sais pas si c'est l'intention, mais tu n'as pas la possibilité de faire un fetch de toutes les requests.
le plus simple est de changer l'endpoint à
/Requestset le paramètre tu peux le mettre à
in: query. enrequired: false@@ -368,0 +410,4 @@description: type of the requestrequired: trueschema:type: integertu peux ajouter la ligne
enum: blop1, blop2, blop3, ...en dessous et au même niveau que type pour spécifier les différent paramètres disponible.
@@ -368,0 +412,4 @@schema:type: integerpost :si tu appliques les précédents commentaire tu as soit le choix de laisser le post dans
/Requests/{type}soit de le mettre avec/Requestset dans ce cas il suffit de mettre le type en paramètre dansrequestBodyou dansquery(je pense que requestBody serait mieux dans le cas présent)@@ -368,0 +424,4 @@content:application/x-www-form-urlencoded:schema:oneOf:pour le patch ça pose pas de problème mais pour le post tu ne peux pas demander d'envoyer un id car il n'y a pas encore d'id.
Une solution serait d'enlever l'id dans les schèma dans le bas du document et des les ajouter explicitement quand tu peux (GET, PATCH -> si id peut être modifié)
g vu le commit caca