25-07-2019, 11:27 AM
Je ne vois pas comment les extraires sans devoir perdre le sélecteur (parce que je n'ai pas envie de le répliquer dans la doc) ou être obligé de faire 1 fichier/comportement (pour 8 comportements à tout casser, ça me fait un peu chier d'aller tracter ensuite des mergeurs de JS et tout le bouzin).
Générer les codes à partir de la doc, Springboot kiff faire ça (bon, ok, ils le font avec les annotations, mais je pense que d'autres FW le font avec la doc pour PHP, ce langage n'ayant pas les annotations) mais perso, je déteste, ça supprime souvent la customisation et surtout à mon sens, le code est ce que la machine exécute et la doc sert à l'humain à comprendre plus facilement ce code... Là, en mixant les deux, les points d'arrêts passent à côté de la doc alors qu'elle influencerait l'exécution :/
'fin bon, les routes, c'est pas le soucis puisqu'elles matchent directement le dossier du endpoint (/map/world/ c'est la route de... php/eclerd/endpoint/map/world/) Ce qui me bloquait plus, c'étaient les typages des paramètres, leur caractère obligatoire, et les réponses du endpoint, parce que là, c'est pas simple à extraire (que ce soit code=>doc ou doc=>code)
Là, il faudra que je trouve comment déterminer les typages des paramètres, le fait qu'ils soient obligatoires, le fait que le endpoint réponde HTTP 200 ou HTTP 403, quand est-ce qu'il répond 403, et quels formats de réponse il accepte (aka les formats de TitlemessageTemplate)... Pour l'instant, j'ai donc laissé tomber, c'est pas d'une importance capitale. Après, si t'as des suggestions, je suis preneur Mon autre piste étaient de faire un test par endpoint et d'y checker ses capacités de formattage, mais c'est lourd je trouve...
Générer les codes à partir de la doc, Springboot kiff faire ça (bon, ok, ils le font avec les annotations, mais je pense que d'autres FW le font avec la doc pour PHP, ce langage n'ayant pas les annotations) mais perso, je déteste, ça supprime souvent la customisation et surtout à mon sens, le code est ce que la machine exécute et la doc sert à l'humain à comprendre plus facilement ce code... Là, en mixant les deux, les points d'arrêts passent à côté de la doc alors qu'elle influencerait l'exécution :/
'fin bon, les routes, c'est pas le soucis puisqu'elles matchent directement le dossier du endpoint (/map/world/ c'est la route de... php/eclerd/endpoint/map/world/) Ce qui me bloquait plus, c'étaient les typages des paramètres, leur caractère obligatoire, et les réponses du endpoint, parce que là, c'est pas simple à extraire (que ce soit code=>doc ou doc=>code)
class MapMapcaseConstructionConstructionSubmitEndpoint extends AWebSimpleFormEndpoint {
public const PARAM_ID_MAPCASE = 'idMapcase';
public const PARAM_ID_BUILDING = 'idBuilding';
protected function httpPost(IConfig $config): IWebUrlResponder {
try {
$bean = PdoProcedure::call(
$config->getDb(),
$config->getSessionManager()->mustBeLoggedIn(),
Param::requiredPostId(static:ARAM_ID_MAPCASE)->getValue(),
Param::requiredPostId(static:ARAM_ID_BUILDING)->getValue());
return TitlemessageTemplate:uccess(
"Chantier lancé",
"Le chantier \"" . BuildingHtml::getLabel($bean->building->id) . "\" a été lancé.");
} catch (NotAllowedSqlException $e) {
return TitlemessageTemplate::forbidden(
"Action impossible",
"Vous ne pouvez pas construire ce bâtiment sur cette case.");
}
}
}
Là, il faudra que je trouve comment déterminer les typages des paramètres, le fait qu'ils soient obligatoires, le fait que le endpoint réponde HTTP 200 ou HTTP 403, quand est-ce qu'il répond 403, et quels formats de réponse il accepte (aka les formats de TitlemessageTemplate)... Pour l'instant, j'ai donc laissé tomber, c'est pas d'une importance capitale. Après, si t'as des suggestions, je suis preneur Mon autre piste étaient de faire un test par endpoint et d'y checker ses capacités de formattage, mais c'est lourd je trouve...