[fait (ou presque)] feuille de route de sly

[sly]

Histoire de discuter avant que je fasse ;-) Voici ma feuille de route (roadmap) structurelle dans l'ordre des choses que j'aimerais bien coder ou faire

1) corriger les bugs ;-)

1b) vantez à mes potes de développement les mérites de l'indentation à deux espaces, les { sur une même colonne et les commentaires en début de fonction pour expliquer comment se servir de $conditions->avec_liste_polygones par exemple.

2) retirer le type de point "censuré" et en faire un champs des points (on peut être à la fois une cabane et être censuré)

3) avancer toujours plus vers MVC :
3a) Créer le dossier "controlleurs" et commencer petit à petit le déplacement vers ce dossier de tout ce qui n'est pas des vues ni des modeles (je vise : tous les fichiers à la racine, les fichiers du dossier exportations et le dossier "statique")
Les appels URL que nous connaissons (/point /nav ...) seront bien entendu maintenus mais le fichier physique sera remplacé par un unique fichier "controlleur.php" qui s'occupera de dispatcher
(Dominique : ça te semble en phase avec la logique MVC ?)

3b) Garder le fonctionnement du mode d'emploi mais tout mettre dans la base au lieu de fichiers et le convertir au modèle MVC

4) Généraliser/factoriser la récupération d'informations (points,polygones,commentaires) en provenance des actions utilisateurs (cartes, recherche, exportation, rss) L'idée étant de pouvoir arriver à un code de ce type (proto) :

Code : Tout sélectionner

$conditions=choix_utilisateurs(array_merge ( $_POST,$_SESSION));
$points_demandés=infos_points($conditions);
ou (voir "et" !)
$polygones_demandés=infos_polygones($conditions);

L'un des objectifs de cette généralisations de l'appel est de pouvoir coder, pour la recherche, la possibilité comme aujourd'hui d'avoir une liste, mais ensuite d'avoir un affichage des résultats sur la carte ou d'exporter le résultat de la recherche. ce que je pourrais alors appelé "l'objet" conditions devient monobloc et peut se transmettre en GET, en POST ou dans la SESSION

Et je vais en rester là pour l'instant des "trucs qui changent mais ne se voient pas", j'ai de quoi m'occuper un bon paquet d'heure.

Évidement, ça chamboule un peu, vos avis ?

[Dominique]

Histoire de discuter avant que je fasse Voici ma feuille de route (roadmap) structurelle dans l'ordre des choses que j'aimerais bien coder ou faire

1) corriger les bugs

2) vantez à mes potes de développement les mérites de l'indentation à deux espaces, les { sur une même colonne et les commentaires en début de fonction pour expliquer comment se servir de $conditions->avec_liste_polygones par exemple.

2) retirer le type de point "censuré" et en faire un champs des points (on peut être à la fois une cabane et être censuré)

OK sur ces points: je voulais juste vérifier que mon éditeur favori (NotePad++) offrait les mêmes facilités d'indentation avec des espaces qu'avec les tabs
C'est le cas, il est paramétrable et je suis d'accord que des espaces donnent une présentation moins dépendante de l'outil de visualisation et que 2 espaces prennent moins de place qu'une tab

3) avancer toujours plus vers MVC

J'aimerais passer un peu plus de temps sur ce point.
En particulier discuter 2 ou 3 règles simples qui pourraient améliorer la lecture du code (enfin, de mon point de vue )

[yip]

2) vantez à mes potes de développement les mérites de l'indentation à deux espaces, les { sur une même colonne et les commentaires en début de fonction pour expliquer comment se servir de $conditions->avec_liste_polygones par exemple.

Notepad++ changé. le changement est amorcé.

2) retirer le type de point "censuré" et en faire un champs des points (on peut être à la fois une cabane et être censuré)

Retirer une feature , qui même si elle sert a rien actuellement, pourrait servir dans un univers parallèle ?
Tu as perdu la tête sly ? un DoppelGanger a pris ta place ?
Ah non, c'est bien toi, c'est pas une suppression, j'ai mal lu

3) avancer toujours plus vers MVC :
3a) Créer le dossier "controlleurs" et commencer petit à petit le déplacement vers ce dossier de tout ce qui n'est pas des vues ni des modeles (je vise : tous les fichiers à la racine, les fichiers du dossier exportations et le dossier "statique")
Les appels URL que nous connaissons (/point /nav ...) seront bien entendu maintenus mais le fichier physique sera remplacé par un unique fichier "controlleur.php" qui s'occupera de dispatcher
(Dominique : ça te semble en phase avec la logique MVC ?)

Pour aller dans ce sens, je passe point_modif_ajout en MVC en ce moment

4) Généraliser/factoriser la récupération d'informations (points,polygones,commentaires) en provenance des actions utilisateurs (cartes, recherche, exportation, rss) L'idée étant de pouvoir arriver à un code de ce type (proto) :

Code : Tout sélectionner

$conditions=choix_utilisateurs(array_merge ( $_POST,$_SESSION));
$points_demandés=infos_points($conditions);
ou (voir "et" !)
$polygones_demandés=infos_polygones($conditions);

L'un des objectifs de cette généralisations de l'appel est de pouvoir coder, pour la recherche, la possibilité comme aujourd'hui d'avoir une liste, mais ensuite d'avoir un affichage des résultats sur la carte ou d'exporter le résultat de la recherche. ce que je pourrais alors appelé "l'objet" conditions devient monobloc et peut se transmettre en GET, en POST ou dans la SESSION

a fond.
Comme une collection de filtres. (filtre pouvant etre aussi bien geometrique que criteria) Si j'avais 3 lettres a placer ...
mais faire grossir infos_points avec toujours plus de conditions et de champs n'est pas la solution a mes yeux.
je verrai bien une logique plus unix, petites briques:
infos point ne recupererait que les points satisfaisant une condition.
et renverrait une liste des points bruts satisfiant la condition.
point barre.
c'est d'autres fonctions qui se charge des noms et de l'habillage (nom des polys, nom des types, types des polys...)

Qu'il y ait plus haut, un autre étage qui s'occupe d"en faire un objet generique a renvoyer partout, c'est carrement l'avenir mais pas une grosse fonction monolithique

On peut aussi penser qu'un polygone est un objet vectoriel comme un poin, et ne plus categoriser les objets en 2 types "point" et "poly" mais 1 seul "vectoriel" .

[sly]

Pour aller dans ce sens, je passe point_modif_ajout en MVC en ce moment

whaa punaise, je prie pour le salut de ton âme, dominique et moi s'y sont cassé les dents tellement c'est un foutoir ce truc. Mais il fallait quelqu'un pour le faire, je suis content que ça soit pas moi ;-)
Tous mes vœux de réussite t'accompagnent !

Qu'il y ait plus haut, un autre étage qui s'occupe d"en faire un objet generique a renvoyer partout, c'est carrement l'avenir mais pas une grosse fonction monolithique

C'est un peu se que je vise avec la fonction choix_utilisateurs(array_merge ( $_POST,$_SESSION)); (ou peut-importe le nom que je lui trouverais)

Mais rendre infos_points complètement agnostique de ce qu'est un point, à mon avis, faut pas rêver

On peut aussi penser qu'un polygone est un objet vectoriel comme un poin, et ne plus categoriser les objets en 2 types "point" et "poly" mais 1 seul "vectoriel" .

Je vois pas comment une fonction générique pour aller chercher des poly et des points ne peut finir autrement qu'en usine à gaz énorme. Mutualiser des sous-fonctions entre les deux, c'est une bonne idée, les fusionner, j'ai du mal à l'imaginer

[yip]

Pour aller dans ce sens, je passe point_modif_ajout en MVC en ce moment

whaa punaise, je prie pour le salut de ton âme, dominique et moi s'y sont cassé les dents tellement c'est un foutoir ce truc. Mais il fallait quelqu'un pour le faire, je suis content que ça soit pas moi
Tous mes vœux de réussite t'accompagnent !

No problemo ! entre 2 git pull, 1 heures max de code, et c'est plié ! LOL
Ah oui, en même temps temps, pour pas avoir a coder 2 fois je passe les champs binaires en booleens ...
Ma branche est pas près d'être stable !
Le prochain push va etre fun ! (comme les bugs qui suivront)

[Dominique]

2) vantez à mes potes de développement les mérites de l'indentation à deux espaces, les { sur une même colonne et les commentaires en début de fonction pour expliquer comment se servir de $conditions->avec_liste_polygones par exemple.

Puis je requérir l'indulgence du jury et porter à 4 le nombre d'espaces par indentation ?
(c'est le standard OL et je serais bien malheureux de reparamétrer mon NotePad++ à chaque fois que je passe d'un fichier WRI à OL)
En vous en remerciant d'avance

[sly]

Va pour 4 (j'ai un écran bien large, donc ça ne devrait pas me poser trop de problème)

[sly]

De ma feuille de route :
Point 1) 1b) et 2) réalisés sur dev. Quelques petits ajustements à prévoir pour que le 2) voir : http://www.refuges.info/forum/viewtopic.php?t=5255

Pour le 3a) et 3b) je viens de mettre sur dev une version du mode d'emploi tout stocké en base + changement des URLs afin surtout de tenter la réalisation technique de 3a) et voir ce que ça peut bien nous apporter.

Pour l'instant, je ne suis pas tout à fait convaincu moi même, je vois quelques trucs que ça peut apporter, comme générer plus tard plus facilement les parties dynamique du bandeau de lien (zones couvertes, et mode d'emploi)
Gérer un peu plus proprement la notion d'utilisateur authentifié et l'alerte de la petite "*" lorsqu'un commentaire est à modérer.

Mais au niveau factorisation du code c'est pas vraiment l'extase, on gagne un include ou deux, on centralise partiellement l'inclusion des vues et des controlleurs mais çe ne fait guère que 4 ou 5 lignes économisées dans chaque fichier.
Le prix lui, est déjà de 30 lignes pour le controlleur.php

Un des avenirs qui aurait pu vraiment mériter cette abstraction aurait été de générer un mécanisme de mise en cache des pages générées de façon centralisée. Mais avec les include, ça ne va pas être simple, ce qui voudrait revenir vers la tentative de dominique de faire ça par des fonctions ou objets. Mais on était arrivé à ce dire que dans l'état actuel, c'était un peu usine à gaz.

Je vais laisser ainsi pour l'instant le temps de voir si se dégagent des avantages, mais je n'exclu pas de laisser tomber l'idée.

ps: un point juste pour les maniaques du rangement, ça place tous les controlleurs aux même endroit ;-)

[sly]

Finalement, tout à été fait sur cette feuille de route, sauf ceux pour lesquels il existe maintenant une proposition disctincte dans ce même forum

je retire le tag proposition

Note : le point 4) n'est pas réalisé, mais se connecte avec la nouvelle API qui sera sans doute une excuse pour unifier les paramètres d'appel de l'API publiée autant que de l'API php interne