[codage] Bien choisir notre modèle MVC

Problèmes, bugs et difficultés rencontrés sur le site.
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Dominique a écrit : Besoin d'aide sur les commandes lignes, certainement (je suis plutôt habitué au mode icones de Tortoise)
si c'est juste ça, je peux faire et je te donner la seule commande intéressante pour passer de l'un à l'autre.
Mais tu as raison: pas besoin de GIT: on va faire ça sur dom.r.i
C'est possible, mais tu ne pourra pas "facilement" revenir à la version "master" et moi, je serais obligé d'aller coder chez toi avec ton compte.
On peut travailler en mode FTP à cette étape de maquettage
Avec ou sans branches, ça revient au même de ce coté là.
Ou ? Qu'est devenu n.r.i ? Dispo pour ça ?
n.r.i est devenu www.r.i, il y a au total 5 instances de wri :
dom / yip / leo / sly / www
Avatar du membre
Dominique
Messages : 3474
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

sly a écrit :n.r.i est devenu www.r.i, il y a au total 5 instances de wri :
dom / yip / leo / sly / www
Sans abuser, tu pourrais nous faire une mvc.r.i (accessible en FTP par tout le monde (même pswwd que www) ?
Pour une maquette, FTP est le bon mode
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Dominique a écrit :
sly a écrit :n.r.i est devenu www.r.i, il y a au total 5 instances de wri :
dom / yip / leo / sly / www
Sans abuser, tu pourrais nous faire une mvc.r.i (accessible en FTP par tout le monde (même pswwd que www) ?
Pour une maquette, FTP est le bon mode
Bon ok, compris, t'en veux pas de mes branches. Ben c'est pas moi qui m'occuperais de fusionner avec le www si l'envie nous en prends parce que ça risque d'être pas fun.

C'est là que c'est :
http://objets.refuges.info/
le login est "objets"
mot de passe ftp et ssh du www

Je suis tétu et bourricot, mais j'ai pas voulu de "mvc" parce que le mvc ça y existe déjà sur la version actuelle
Avatar du membre
Dominique
Messages : 3474
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

sly a écrit :C'est là que c'est :
http://objets.refuges.info/
le login est "objets"
mot de passe ftp et ssh du www

Je suis tétu et bourricot, mais j'ai pas voulu de "mvc" parce que le mvc ça y existe déjà sur la version actuelle
L'a tapé objet !
ben dis donc
Moi qui croyait qu'il n'y avait ni touches O ni B ni J E T sur ton clavier :laughing:

Merci pour la MV !
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Re: [débat] Bien choisir notre modèle MVC

Message par sly »

sly a écrit : - 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)
Beaucoup de nettoyage en ce sens, et retrait des éditeurs de polygone (dominique peut les retrouver dans l'historique ou la branche "avant-pdo" si volonté de remettre cela en service.
- renommer la variables $modele en $vue de partout
Fait, maxi ménage !

sly a écrit : - 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()
beaucoup d'opérations dans ce sens, mais il en reste encore pas mal
Avatar du membre
Dominique
Messages : 3474
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

Quelques réactions à chaud:

- J'aime bien les contrôleurs tels que tu les a fait
S'ils ne font pas gagner en ligne de code (MVC n'est pas fait pour ça), la lisibilité est bien meilleure

- Je militerais pour la création d'un répertoire /includes qui contiendrait
config.php
config_privee.php
fonctions_autoconnexion.php
fonctions_bdd.php
fonctions_zip.php
Qui ne sont pas vraiment des modèles au sens MVC

- Les modeles y gagneraient en clarté si on avait 1 fichier = 1 fonction de même nom
On peut éventuellement passer en objet et y gagner l'include automatique du fichier

- Je suis un peu gêné par l'emploi systématique de stdClass
C'est un opérateur interne à PHP qui ne'est pas sensé être utilisé dans le code
La programmation objet, c'est pas ça :avocat:
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Dominique a écrit : - J'aime bien les contrôleurs tels que tu les a fait
S'ils ne font pas gagner en ligne de code (MVC n'est pas fait pour ça), la lisibilité est bien meilleure
Alors il y a au moins un adepte ;-)
J'ai trifouillé le controlleur.php un peu rapidement pour faire ce dont j'avais besoin sur le moment, c'est sur le long terme que je verrais ce que je peux lui faire faire de plus.
Et voir si la manière de gérer les urls a un sens ou nous embrouille plus qu'autre chose.
- Je militerais pour la création d'un répertoire /includes qui contiendrait
config.php
config_privee.php
fonctions_autoconnexion.php
fonctions_bdd.php
fonctions_zip.php
Qui ne sont pas vraiment des modèles au sens MVC
Pas d'objections, bien que je n'y vois pas tant le gain rangement ni pourquoi fonctions_zip.php serait si différente de fonctions_nouvelles.php.
- Les modeles y gagneraient en clarté si on avait 1 fichier = 1 fonction de même nom
ça va t'en faire un paquet de fichiers, t'as vu le nombre de fonctions qu'on a ?
- Je suis un peu gêné par l'emploi systématique de stdClass
C'est un opérateur interne à PHP qui ne'est pas sensé être utilisé dans le code
La programmation objet, c'est pas ça :avocat:
Si on le fait pas, php renvoi un warning parce qu'il n'est pas content.

Il n'est pas tant ici question de programmer "objet" ce qui n'est pas le cas, les $vue $condition et $point ne sont en fait rien d'autre que des tableaux, on aurait tout aussi bien pu faire avec seulement des tableaux :
$vue['titre'] au lieu de $vue->titre
$point['altitude'] au lieu de $point->altitude

Historiquement, si j'ai choisi cette voie, c'est pour deux raisons :
- la première, c'est la flemme : l'écriture $point->altitude économise 2 caractères sur le tableau et un echo "l'altitude est $point->altitude (en mètres)"; est possible sans trop s'embêter avec les ' et les "
- la deuxième, tu vas rire, c'est que je n'ai jamais perdu de vue l'idée de pouvoir un jour le transformer en vrai objet et arriver à faire un jour un truc dans ce goût là :

Code : Tout sélectionner

$point = new point(45);
$point->nom="toto";
$point->enregistre();
$gpx=$point->export_gpx();
Dans les faits, j'en ai jamais vu le besoin pour l'instant et le code actuel fait ça :

Code : Tout sélectionner

$point = infos_point(45);
$point->nom="toto";
creation_modification($point);
$gpx=exportation($point,"gpx");
ce qui prend précisément le même nombre de ligne et offre les même flexibilités sur les besoins que j'ai identifié.
Mais on optant en interne pour ce format, je garde une porte plus facile à pousser qui est celle des objets.
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

je continue mon rangement, si vous récupérez la dernière version de dev, pensez bien à reprendre le htaccess.modele.txt pour le copier vers .htacess sinon ça ne marche pas
Avatar du membre
Dominique
Messages : 3474
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

sly a écrit :Pas d'objections, bien que je n'y vois pas tant le gain rangement ni pourquoi fonctions_zip.php serait si différente de fonctions_nouvelles.php.
Parce que zip est une facilité système et nouvelles un modèle d'info manipulé par le site
Bon, j'avoue, c'est un débat de jésuites
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Dominique a écrit : Parce que zip est une facilité système et nouvelles un modèle d'info manipulé par le site
Bon, j'avoue, c'est un débat de jésuites
jésuites ou pas, ce raisonnement se tient, et je comprends mieux qui va dans quel dossier. Very good, je fais.
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Mmmm le config.php risque bien de moins bien se laisser faire, il est présent de partout et de nombreuses fois par son chemin précis.

Il est inclus par tous les modèles qui vont devoir faire include("../includes/config.php");

Je vais voir comment faire, mais il se pourrait bien, si je ne veux pas y perdre mon chemin que le include_path finisse dans le .htaccess en espérant que le apache windows fasse la correction pour php sinon je ne sais pas comment lui passer le path separator
Avatar du membre
Dominique
Messages : 3474
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

sly a écrit :Je vais voir comment faire, mais il se pourrait bien, si je ne veux pas y perdre mon chemin que le include_path finisse dans le .htaccess en espérant que le apache windows fasse la correction pour php sinon je ne sais pas comment lui passer le path separator
Bof
Tu ne peux pas éditer tous les fichiers contenant config.php ?
Il y en a une tripotés, mais ça se fait: je l'avais fait en local (mais pas uploadé)
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

C'est toujours possible, mais ça en fait bien un paquet à changer. Et ça force toujours chaque appelant à savoir où se trouve le config.php ce qui rend la gesticulation include("../../includes/config.php") un peu relou je trouve, surtout quand on souhaite déplacer le fichier !
Avatar du membre
Dominique
Messages : 3474
Enregistré le : 08 avr. 2006, 21:58

Message par Dominique »

sly a écrit :Mmmm le config.php risque bien de moins bien se laisser faire, il est présent de partout et de nombreuses fois par son chemin précis.

Il est inclus par tous les modèles qui vont devoir faire include("../includes/config.php");
Voilà qui est fait (Dispo dans GIS dev)
ça fait pas mal de fichiers, mais 3 types de change all en fin de compte, ça se groupe bien sous Notepad++
Je vais voir comment faire, mais il se pourrait bien, si je ne veux pas y perdre mon chemin que le include_path finisse dans le .htaccess en espérant que le apache windows fasse la correction pour php sinon je ne sais pas comment lui passer le path separator
Pas la peine. Que config soit dans /includes ou /modeles, quelle différence ?

**EDIT**
sly a écrit :ça force toujours chaque appelant à savoir où se trouve le config.php ce qui rend la gesticulation include("../../includes/config.php") un peu relou je trouve, surtout quand on souhaite déplacer le fichier !
Je propose un include qui marche quel que soit le niveau de profondeur du script appelé

include (str_repeat('../',substr_count ($_SERVER['SCRIPT_NAME'],'/')-1).'includes/config.php');
(pas implémenté)
Avatar du membre
sly
Messages : 4765
Enregistré le : 29 févr. 2004, 17:59
Localisation : Chambéry - Savoie

Message par sly »

Dominique a écrit :Que config soit dans /includes ou /modeles, quelle différence ?
Rien de bien dramatique, ça fait que les fichiers php qui sont dans modeles ont besoin de faire include('../includes/config.php"); ce qui est un peu plus long que include("config.php"); à taper.
Je propose un include qui marche quel que soit le niveau de profondeur du script appelé
include (str_repeat('../',substr_count ($_SERVER['SCRIPT_NAME'],'/')-1).'includes/config.php');
(pas implémenté)
Pas super en terme de lisibilité et je préfère encore déclarer le chemin à la main, des fois qu'on finisse par inclure un includes/config.php qui traine dans le forum ou une copie de sauvegarde.

Qu'est-ce qui t'embête à ce point avec le mettre dans .htaccess ? où c'est juste que tu n'as pas réussi à configurer ton apache pour qu'il s'en serve ? ;-)
Répondre