Salut, suite à un sujet concernant le SDZ (cf: https://www.jeuxvideo.com/forums/1-47-52198-1-0-1-0-le-sdz.htm) je me suis dit que ça serait pas mal d'avoir un endroit où l'on discute des pratiques que chacun met en place.

Je m'explique, par exemple j'hésite très souvent à taper mon code de cette façon:

<p><?php echo $foo; ?></p>

Ou bien ceci:

<?php echo "<p>".$bar."</p>"; ?>

Ensuite j'ai aussi l'habitude de traiter tout en une page, mais je commence à me demander si faire une page de traitement ne serait pas mieux (une petite vérif ça passe, quand il y en a plusieurs dizaines ça devient moins lisible je trouve).

Et puis des conneries que j'ignorais (merci deepblue xP):

if(isset($_POST['foo'], $_POST['bar'], etc etc))

au lieu de

if(isset($_POST['foo']) && isset($_POST['bar']) && etc etc)

Ou encore les foreach: je passais mon temps quand j'avais 20 champs à les récuperer un à un, avec le foreach, clé valeur et il se charge du reste (par contre pour les vérifs ça me pose un problème parfois).

Fin bref, ça peut parfois être des bêtises pour certain je vous l'accorde mais par exemple ici je suis en train de refaire un site que j'avais fait il y a quelques mois et je me demande franchement comment j'ai pu faire cette horreur, bref une vraie merde à remettre à jour, et je me dis qu'avec une meilleure organisation, ça aurait pu être éviter.

Et si ce genre de chose peut être utile alors pourquoi ne pas en faire profiter les autres (on essaye de ne pas réinventer la roue, mais chercher comment ne pas la réinventer, je trouve ça quand même utile ^^).

J'ai mon index.php qui vient inclure les pages suivant ce que l'utilisateur demande. Du coup, j'ai une page (pour mon blog) de gestion de commentaire, de gestion des articles, une pour lire un article, etc. Avec pour chaque modules qui affiche du contenu : la page du module et la vue (template).
Mes templates n'ont aucun script php qui écrire des balises. En gros je fais ça : <p><?php echo $foo; ?></p>

Quand tu dis templates tu parles de vues? Les vérifications etc, tu les fais sur quel page (exemple les isset/empty etc) ? Parce qu'admettons que tu dois afficher un message d'erreur, tu devrais le renvoyer vers la page d'affichage.

Pour le principe de base je fonctionne pareil sur base d'includes selon la section.

A vrai dire j'ai essayé de faire il y a quelques semaines une automatisation des requêtes, j'entends par là de ne plus taper le SQL mais de le générer. Ca m'aide mais le fait que ça soit plus automatique me pose un soucis au niveau vérification (en gros tout les champs sont pris tel quel, donc on ne distingue pas le texte de l'email quoi).

En gros avant je faisais ça si tu veux:

$sql = 'SELECT id, nom, prenom FROM membres WHERE id = 1';
$rs = mysql_query($sql);
$r = mysql_fetch_assoc($rs);

echo $r['nom'];

Avec ce que j'ai fais ça deivent:

$sql = read(1, 'membres');
echo $sql['nom'];

Bon là l'utilité n'est pas très implicite mais par contre quand tu as des formulaires qui renvoient 15 champs à insérer, ça aide.

Et puis aussi, le jour où je décides de changer un truc, je change mes fonctions et tout le site s'adapte au niveau des requêtes (le SQL étant le même, ça ne posera pas vraiment de soucis). J'avais initialement fait ça en POO (fallait bien que je suive la vague un moment donné xP), mais je suis retourné en procédural (pas que j'aime pas le principe, mais établir toute une structure en POO pour 2 classes, c'est prendre le bazooka pour tuer la mouche).

Le truc c'est que je récupérer avec un foreach à présent, seulement voilà si j'ai un email ou un numéro de téléphone à vérifier, comment lui dire que je veux une vérification sur ce champ là (la seule idée que j'ai eu serait de stocker tout dans un tableau, faire mes vérifications sur les champs que je veux, et puis enfin envoyer le tableau si celles ci sont correctes, seule solution que je vois).

Les templates sont mes vues oui. Voila comment je gère mes formulaires :
- index.php -> chargement du module -> vue avec le formulaire
- au submit du form : index.php -> chargement du module de gestion -> si erreur(s), création de variable de session, redirection vers le module
- index.php -> chargement du module -> vue avec le formulaire : affichage des erreurs
Ce que j'ai décris est fait sur mon blog.

Dans mediaplayer.deblan.fr, je n'ai pas d'étape de redirection, je charge directement la vue avec les erreurs (et uniquement les erreurs).

Je n'ai pas encore de vraie solution pour bien traiter les formulaires. Je t'invite à regarder ce que fait codeigniter.

Disons qu'il faut que je me penche aussi sur la gestion des erreurs, chose que je zappe mais qui a son importance.

Tiens pour que ça soit plus concret, voilà un exemple de page admin:

http://wall.deblan.fr/x1d41/php/1/

Comme tu vois je fais tout en un (et comme dit j'ai mes fonctions qui gérent les requêtes SQL).

Question idiote mais dans une page admin, quand tu dois modifier un enregistrement, t'es bien obligé de faire des vérifications sur la vue non ?

Sinon je me posais la question en POO, comme dit j'ai une classe qui exécute toutes mes requetes mais est ce que je ne devrais pas plutôt faire (exemple bidon, des articles, un article pouvant aller dans plusieurs catégories, et aussi forcément plusieurs catégories, donc relation 1 à n) une classe Articles, et une Categories (avec des méthodes, add, insert, update etc où là je tape la requête, qui sera donc propre à la classe) mais c'est pas un peu redondant, ou bien alors comme je fais pour le moment une classe SQL et où je change les paramètres (nom de la table, des champs etc).

Vérifications sur la vue avec du js, sinon ce sont tes controleurs (avec l'appel ou pas de modèle) qui feront le travail.

Alors, tu as une classe SQL si tu veux qui est générique. Basiquement, tu pourras avoir une méthode pour éxecuter une requête, une autre qui te retourne un nombre d'enregistrement, une autre qui te retourne un tableau des résultats d'une requête, etc. Là, je te renvoi une nouvelle fois à CodeIgniter qui en a une qui fonctionne très bien (et ça me permet de ne pas écrire une seule ligne de SQL).

Ensuite, tu as tes modèles Article, Categorie, etc qui ont des méthodes pour mettre à jour les données de la bd (insertion, modification, etc). Ils font bien sur appel à la classe Sql.

Tu as des modèle plus généralistes, type "Blog" qui devront être composés de méthodes pour trouver plusieurs données qui leur appartiennent. Il ne faut pas oublier que dans un modèle Objet, si j'ai un objet Commentaire, alors il ne peut pas contenir l'ensemble des commentaires (d'où la classe généraliste type Blog).

Tes controleurs ne sont là que pour faire joujou avec tes modèle. On peut dire que la classe SQL est une bibliothèque. Typiquement, dans ton controleur, tu pourras avoir ça : $blog->getComments();

s/(avec l'appel ou pas de modèle)/(avec l'appel ou pas de modèle/bibliothèques)

Je change chaque semaine de méthode moi... xP

J'ai parlé avec mon prof (qui comme dit devient plus un pote qu'un prof xP) sur le système utilisé par leur societé et je dois dire que je n'y aurai jamais pensé bien qu'il y ai encore quelques questions que je me pose dans certains cas.

Le principe en réalité est de faire une table générique, et non plus un truc genre news, articles, rubriques etc comme j'avais l'habitude de faire (car parfois un champ différenciait les 2 tables, donc à peu de chose près la même structure de base).

En gros on considère les éléments comme des "médias", médias qui appartiennent à un type (photo, articles, rubriques, vidéos etc) et on a des champs eux aussi assez générique (title, body, language, header, URL, custom (si par exemple un article est accompagné d'une image), on pourrait même en rajouter d'autre genre signature, copyright).

Le gros avantage est de pouvoir établir une structure qui marcherait à peu près (comme dit j'ai encore 2-3 trucs qu'il faut que je lui pose) dans tout les cas (bien qu'on utilise pas toujours tout les champs) et donc de pouvoir transposer ça sur un grand nombre de site.

Et là on aurait une classe Medias qui s'occuperait alors d'insérer un nouveau média, supprimer, rechercher etc.

Perso même si l'idée parait tordue au début, au final je pense que ça s'adapte mieux en production.