+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Documentation des classes CSS (/showthread.php?tid=3303)
Pages :
1
2
RE: Documentation des classes CSS - niahoo - 25-07-2019
En fait je parlais plus de définir tes routes et ta doc à partir d'un format unique. Le code peut être simplement de la validation, ton contrôleur n'étant appelé que si celle-ci est passée. Généralement tous les frameworks ont une feature ou un plugin pour faire ça.
Pour le JS j'avais oublié que ce sont les selectors que tu veux documenter en fait
Du coup un truc comme ça ?
/**
* Bla bla bla de la doc
*/
export const FORM_DISABLED = 'form[data-disabled]'
/**
* Encore de la doc
*/
export const FORM_ON_SUCCESS = 'form[data-on-success]'
// --------------------
import { FORM_DISABLED, FORM_ON_SUCCESS } from '....../dom-api-truc'
function defineBehaviour(selector, onEachNode) {
document.querySelectorAll(selector).forEach(onEachNode)
}
defineBehaviour(FORM_DISABLED, f => {
if (f.dataset['onSuccess']) {
// The form is "disabled" so it's not submittable anyway even in JS
delete f.dataset['onSuccess'];
}
// ...
})
edit : ouch c'est moche le rendu des blocs de code là ! Que font les admins !
edit2: bon si on précise pas le langage c'est mieux.
RE: Documentation des classes CSS - Xenos - 25-07-2019
Oui, du coup, c'est ce que je fais: le code (emplacement & classname) définit la route, et la doc HTML générée se base là-dessus. Ca revient au même je dirai, le format unique étant le path de la classe (et le code normalement, puisque je peux surcharger ce path dans un endpoint si besoin, typiquement, la page d'accueil, mais bof, pas la peine de traiter ce seul cas particulier IMO).
Ca revient un peu au même mais je préfère rester sur ce que j'ai actuellement: les import/export, j'avais essayé il y a peut-être bien 1 an, et le navigateur (et moi) finissons en PLS, et je préfère éviter d'avoir des variables (même des constantes) qui se baladent dans l'espace global et de devoir faire de la colle entre la définir de ces selecteurs et l'application des comportements. L'exemple-type chiant dans ce genre de cas serait le data-increment-value: les autres attributs (data-increment-speed, data-increment-max etc) sont dans le corps de la function du "forEach". La doc répète donc les Node.dataset.incrementMax/Min/etc qui sont dans le corps de cette méthode, et si je sors les sélecteurs, j'augmente drastiquement le risque que la doc et le code ne soient plus en phase. Ou alors, il faudrait sortir aussi ces attributs dans les export, avoir un export const DATA_INCREMENT_MAX = 'data-increment-max'; mais merger sa doc avec la doc du data-increment-value, et changer les dataset pour des getAttributes ou mettre DATA_INCREMENT_MAX = 'incrementMax' si je veux garder le .dataset['incrementMax']
PS: j'ai édité ton message, le code me parait bien formatté à moi?! en revanche, le formattage se fait au chargement de la page, il faudra faire F5 si tu as édité le message en "édition rapide"
RE: Documentation des classes CSS - niahoo - 25-07-2019
Bah pour le JS tu peux bien avoir les constantes et les fonctions qui les utilisent dans le même module …
Et pour le php le path n'est pas suffisant, une api correcte propose le typage des paramètres ou un json-schema, des types de réponses, etc ...