[codage] Bien choisir notre modèle MVC

Message par **sly** » 11 mars 2013, 13:27

dominique a écrit :
sly a écrit : 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 :wink: )

Ouais, cool, moi aussi j'aimerais bien qu'on arrive à se synchroniser et je suis en bonne condition mental pour accepter de faire des efforts ;-)
Et j'ai moi aussi plusieurs suggestions, mettons tout dans un sac, secouons, et voyons ce qui peut être fait ?

Mes revendications :

- ne pas mettre des vues ailleurs que dans /vues (ou un sous dossier) (même s'il s'agit de l'édition de polygone, de la gestion ou autre) et pareil pour modeles et controlleurs (dans la mesure du possible bien sûr, OL et forum qui sont des projets repris, n'ont que peut de chance de s’accommoder de notre MVC)

- l'idée de l'objet $modele qui contient tout ce dont la vue a besoin est une excellente idée, qui laisse entrevoir une évolution future pour faire mieux que les "include" et qui, dès maintenant est déjà super, sauf que j'ai été surpris de voir que les vues font parfois appel à des variables autres et c'est plus dur de comprendre

- renommer la variables $modele en $vue de partout

- ne plus mettre un seul appel de fonction dans les vues/*.html je me suis surpris à en voir, et quand je dois changer les appels à une fonction, j'ai pour habitude de parcourir tous les php pour faire le changement, et ça foire parce qu'il y a des appels dans les html
Ne plus accepter que les foreach, les if, et les if (isset()) ou if ($variable) ou if empty() ou if count()

Questions rangement (là, j'ai des idées, mais je n'en suis pas super convaincu moi même)

- Tout en vrac dans /vues ça va devenir peu lisible, j'aimerais bien ranger avec ce format :
/vues/js/$thème/nav.js
/vues/html/$thème/nav.html
/vues/css/$thème/nav.css
/vues/xml/$thème/

$thème pouvant par exemple devenir : gestion ou principal ou exportation

Et vous, vos idées et revendication ?

Message par **Dominique** » 11 mars 2013, 13:46

sly a écrit :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

)[/quote]

Ouais, cool, moi aussi j'aimerais bien qu'on arrive à se synchroniser et je suis en bonne condition mental pour accepter de faire des efforts

Et j'ai moi aussi plusieurs suggestions, mettons tout dans un sac, secouons, et voyons ce qui peut être fait ?

Mes revendications :

- ne pas mettre des vues ailleurs que dans /vues (ou un sous dossier) (même s'il s'agit de l'édition de polygone, de la gestion ou autre) et pareil pour modeles et controlleurs (dans la mesure du possible bien sûr, OL et forum qui sont des projets repris, n'ont que peut de chance de s’accommoder de notre MVC)
DOM: OK

- l'idée de l'objet $modele qui contient tout ce dont la vue a besoin est une excellente idée, qui laisse entrevoir une évolution future pour faire mieux que les "include" et qui, dès maintenant est déjà super, sauf que j'ai été surpris de voir que les vues font parfois appel à des variables autres et c'est plus dur de comprendre
DOM: OK

- renommer la variables $modele en $vue de partout
DOM: OK

- ne plus mettre un seul appel de fonction dans les vues/*.html je me suis surpris à en voir, et quand je dois changer les appels à une fonction, j'ai pour habitude de parcourir tous les php pour faire le changement, et ça foire parce qu'il y a des appels dans les html
Ne plus accepter que les foreach, les if, et les if (isset()) ou if ($variable) ou if empty() ou if count()
DOM: OK

Questions rangement (là, j'ai des idées, mais je n'en suis pas super convaincu moi même)

- Tout en vrac dans /vues ça va devenir peu lisible, j'aimerais bien ranger avec ce format :
/vues/js/$thème/nav.js
/vues/html/$thème/nav.html
/vues/css/$thème/nav.css
/vues/xml/$thème/

DOM: /js bof. Je trouve pratique d'avoir les fichiers de même usage côte à côte (nav.html nav.js ...)

$thème pouvant par exemple devenir : gestion ou principal ou exportation
DOM: OK

Et vous, vos idées et revendication ?

Message par **sly** » 11 mars 2013, 13:56

Dominique a écrit :
- Tout en vrac dans /vues ça va devenir peu lisible, j'aimerais bien ranger avec ce format :
/vues/js/$thème/nav.js
/vues/html/$thème/nav.html
/vues/css/$thème/nav.css
/vues/xml/$thème/
DOM: /js bof. Je trouve pratique d'avoir les fichiers de même usage côte à côte (nav.html nav.js ...)

js et html côte à côte, ça me va aussi.
Pareil pour css ? (a supposer que, à l'avenir, on coupe le css en morceaux afin d'éviter de charger un gros truc à chaque fois dont 10% vont servir pour la page en question ?
ou ok pour un dossier css à coté ?

Auquel cas, l'arboresence deviendrait donc :
/vues/html/$thème/ (pour par exemple nav.html et nav.js)
/vues/css/$thème/ (pour, par exemple nav.css, global.css)
/vues/xml/$thème/ (pour, par exemple all.gml points.gpx garmin.gpx quand $thème est "exportations")

Tu n'as pas répondu à quelles étaient tes attentes/propositions, dont tu parles dans l'autre sujet

Message par **Dominique** » 11 mars 2013, 14:02

Pour CCS, pareil

Pour mes propositions, je fourbis mes armes. Prépare toi

Message par **Dominique** » 11 mars 2013, 14:10

Mes revendications:

La vue est un fichier html avec des inclusions <?php?> c'est déjà le cas

/modeles n'est pas l'équivalent de /includes
J'aimerais réhabiliter /includes pour des fichiers comme config.php, ... qui ne sont pas des modèles au sens MVC

OK pour un point d'entrée commun (sauf forum et extractions)

Pour les modèles et contrôleurs:
- un contrôleur = une url (nav, point, ... actuellement)
- un modèle = l’accès à un type de donnée (point, massif, ...). Le reste devra aller dans /includes

Pour qu'on puisse retrouver facilement le fichier : le nom du fichier = le nom du type de donnée = le nom de la fonction

Un seul fichier par contrôleur ou un modèle, donc qui rend 1 type d'objet
(pas une longue liste de fonctions dans functions_tartenpion.php)

Un contrôleur ou un modèle rend une variable avec des membres de la forme $var->membre (pas un tableau)

Jusque là, j'espère qu'on est d'accord ?

... bon. Maintenant, une fonction qui rend une variable avec des membres $var->membre, ça s'appelle une classe

Donc une classe par fichier ? de même nom ?
Qu'on n'appelle pas par info_massifs () mais par new massifs ()

Reste que ça va nous faire une palanquée d'includes à gérer !!!
Mais, monsieur PHP à pensé à tout : une fonction spl_autoload_register() permet d'automatiser le chargement des fichiers includes adéquats quand on crée un objet
new massifs () suffit !

On essaye un peu avant de dire qu'on a mal ?

Message par **sly** » 11 mars 2013, 15:03

Comment se fait il que je ne sois pas étonné que tu nous ressortent tes objets lorsqu'il est question de MVC ?
Alors même que la moitié seulement du site utilise ce modèle ?

Dominique a écrit : - un modèle = l’accès à un type de donnée (point, massif, ...). Le reste devra aller dans /includes
(...)
Un seul fichier par contrôleur ou un modèle, donc qui rend 1 type d'objet

Et ben il va être bien creux ton dossier "modeles", et le contenu des fichiers va lui aussi être bien creux puisque les appels aux points, par exemple, étant fait plus ou moins partout, ton fichier points.php va contenir une classe qui ne sera qu'un wraper vers la vrai fonction dans includes

Soit, pour résumé, une classe qui va faire :

Code : Tout sélectionner

class point
&#123;
  function __construct&#40;$id_point&#41;
  &#123;
   return infos_point&#40;$id_point&#41;;
  &#125;
&#125;
new point = point&#40;$id&#41;;

Mais il est possible que je n'ai pas tout compris ;-)

On essaye un peu avant de dire qu'on a mal ?

J'ai rien contre si c'est ton temps, mais je crois que ça rejoins ce que tu disais déjà : "il faut bien définir nos objets" et je ne vois pour l'instant rien de bien tangible.

Message par **Dominique** » 11 mars 2013, 15:15

sly a écrit : Et ben il va être bien creux ton dossier "modeles", et le contenu des fichiers va lui aussi être bien creux puisque les appels aux points, par exemple, étant fait plus ou moins partout, ton fichier points.php va contenir une classe qui ne sera qu'un wraper vers la vrai fonction dans includes

Soit, pour résumé, une classe qui va faire :
Code : Tout sélectionner
class point
&#123;
  function __construct&#40;$id_point&#41;
  &#123;
   return infos_point&#40;$id_point&#41;;
  &#125;
&#125;
new point = point&#40;$id&#41;;

Ben, le but, c'est de mettre le contenu de la fonction infos_point() là, dans __construct()

sly a écrit :
On essaye un peu avant de dire qu'on a mal ?
J'ai rien contre si c'est ton temps, mais je crois que ça rejoins ce que tu disais déjà : "il faut bien définir nos objets" et je ne vois pour l'instant rien de bien tangible.

C'est bien le problème: le plus gros de la programmation objet est de définir les objets que nous manipulons
Après, le codage va vite et les factorisations impressionnantes
Tant qu'on a pas tout entré dans des objets (je t'assure qu'on peut tout y mettre) et que ces objets ont chacun une raison d'être, on n'a pas fini l'analyse

Alors: on tente la liste des objets ? (en levant le nez du code, SVP)
- Massif, zone ? ... ou l'un est une sous classe de l'autre ?
- Point
- Caractéristique d'un point
- Commentaire
- Photo ?
- Carte

- Lien
- ...

Message par **sly** » 11 mars 2013, 15:43

Dominique a écrit : Ben, le but, c'est de mettre le contenu de la fonction infos_point() là, dans __construct()

Et la page recherche doit, elle aussi, inclure la classe point, comme elle inclura aussi la classe polygone.
mais si c'est entendu qu'un contrôleur va appeler plusieurs classes, donc plusieurs modeles, ben il me semble que l'on revient, peu ou prou à la situation acutelle ou dans "modeles" on trouve fonctions_points.php, si ce n'est qu'on le renomme points.php et qu'on passe en objet.

Alors: on tente la liste des objets ? (en levant le nez du code, SVP)

J'en suis incapable, car je ne mesure pas ce que ça apporte, ni quel but on vise avec. J'aurais donc juste tendance à lister ce qui existe déjà, et pas besoin d'avoir le nez dans le code, l'ayant en tête, je vais être perturber par ça.
objets :
- accès aux points par des conditions
- accès aux polygones par des conditions
- accès aux commentaires ....
- accès aux utilisateurs ...
- accès aux fiches du mode d'emploi ....

Message par **Dominique** » 11 mars 2013, 16:08

sly a écrit :Et la page recherche doit, elle aussi, inclure la classe point, comme elle inclura aussi la classe polygone.
mais si c'est entendu qu'un contrôleur va appeler plusieurs classes, donc plusieurs modeles, ben il me semble que l'on revient, peu ou prou à la situation acutelle ou dans "modeles" on trouve fonctions_points.php, si ce n'est qu'on le renomme points.php et qu'on passe en objet.

Oui, un objet contient d'autres objets
Quand au langage, une déclaration de classe ou une fonction, peu importe. C'est l'analyse et les factorisations qui sont importantes

sly a écrit :- accès aux points par des conditions
- accès aux polygones par des conditions
- accès aux commentaires ....
- accès aux utilisateurs ...
- accès aux fiches du mode d'emploi ....

Je crois qu'on converge. Je peux essayer.

Message par **sly** » 11 mars 2013, 16:11

Dominique a écrit : Quand au langage, une déclaration de classe ou une fonction, peu importe. C'est l'analyse et les factorisations qui sont importantes

Je ne peux qu'être d'accord.

Dominique a écrit : Je crois qu'on converge. Je peux essayer.

Puis-je suggérer, considérant que ça représente plus ou moins de changer presque tous les fichiers, la création d'une branche git qui me permettra de passer simplement à ta version et tester, et toi de continuer à proposer des corrections sur la branche active ?

Message par **Dominique** » 11 mars 2013, 16:30

sly a écrit :Puis-je suggérer, considérant que ça représente plus ou moins de changer presque tous les fichiers, la création d'une branche git qui me permettra de passer simplement à ta version et tester, et toi de continuer à proposer des corrections sur la branche active ?

Tout à fait. D'autant plus que, dans un premier temps, je veux surtout valider la méthode (sur quelques fonctions)
Rappelle toi, pour les vues, on a essayé plusieurs solutions avant d'en trouver une simple et efficace
Si ce n'est pas simple et efficace, on ne fera pas

Message par **sly** » 11 mars 2013, 16:53

Dominique a écrit : Rappelle toi, pour les vues, on a essayé plusieurs solutions avant d'en trouver une simple et efficace
Si ce n'est pas simple et efficace, on ne fera pas

Tout à fait, et bien d'accord, et ok pas de problèmes donc.

Si besoin d'aide technique pour créer la "branche git" en ligne de commande, je peux m'en occuper, ou t'indiquer comment, à moins que tu préfères faire autrement comme dupliquer tout le site, ou copie chez toi, ou autre de ta convenance.

Il n'est évidement pas exclus, qu'une fois la solution que tu aura fait avancé me plait, je tente moi aussi d'y ajouter des trucs pour voir dans certains cas comment ça se comporte en terme de quantité de code à taper par rapport à la méthode et quelle facilité ça apporte.

Message par **yip** » 11 mars 2013, 17:47

Debut de semaine sur les chapeaux de roues

OK pour le MVC, a part
- /vues/$theme/ inutile
- decouper le CSS, je suis pas pour, ca incite a faire des DIV et du css par Class, ce qui n'est pas bien.
- decouper les includes, sachant qu'il y a des tirs croisés de partout, ca va pas être évident.

Bosser sur 2 branches GIT qui ne pourront pas merger, ca revient a dire que certains vont bosser sur une voie de garage

Definir les objets:
+1 Dominique, avant de bosser, on fait un gros brainstorm sur le choix des objets, plusieurs semaines avant le code pour se laisser le temps de bien choisir

Message par **Dominique** » 11 mars 2013, 17:50

sly a écrit :Si besoin d'aide technique pour créer la "branche git" en ligne de commande, je peux m'en occuper, ou t'indiquer comment, à moins que tu préfères faire autrement comme dupliquer tout le site, ou copie chez toi, ou autre de ta convenance.

Besoin d'aide sur les commandes lignes, certainement (je suis plutôt habitué au mode icones de Tortoise)

Mais tu as raison: pas besoin de GIT: on va faire ça sur dom.r.i
On peut travailler en mode FTP à cette étape de maquettage

Ou ? Qu'est devenu n.r.i ? Dispo pour ça ?

Message par **Dominique** » 11 mars 2013, 17:52

yip a écrit :Debut de semaine sur les chapeaux de roues

OK pour le MVC, a part
- /vues/$theme/ inutile
- decouper le CSS, je suis pas pour, ca incite a faire des DIV et du css par Class, ce qui n'est pas bien.
- decouper les includes, sachant qu'il y a des tirs croisés de partout, ca va pas être évident.

Bosser sur 2 branches GIT qui ne pourront pas merger, ca revient a dire que certains vont bosser sur une voie de garage

Definir les objets:
+1 Dominique, avant de bosser, on fait un gros brainstorm sur le choix des objets, plusieurs semaines avant le code pour se laisser le temps de bien choisir

+ partout. Seulement, en parallèle de la tempête crânienne, j'aime bien faire 2 ou 3 essais sur des fichiers (à jeter) pour le côté langage