Reprise du message précédent :
C'est sûr que ça demande réflexion. Chaque méthode a ses avantages et ses inconvénients.
 
Par exemple, d'un côté j'aime bien ne rien utiliser du tout (pas de véritable MVC, pas de template ni rien). J'ai mes petites classes perso (galerie, contrôle de formulaire, gestion de news etc...), et je me démerde très bien comme ça. Vu que c'est mon bouzin, je le maitrise, et je code rapidement...
 
Seulement quand je vois parler de Templates (avec Smarty par exemple), de MVC, de framework & co, j'ai l'impression de coder comme un porc (alors que mon code est propre, indenté, documenté, assez robuste je pense ...). Donc il est là le problème.
 
Moi ça ne me gène pas d'avoir des petits morceaux de php partout dans mon html

Tout dépend de tes besoins. Moi j'avais des besoins de réutilisation (ne pas avoir à coder un formulaire de contact à chaque fois), tout en pouvant redéfinir certains trucs (par exemple pour un menu, juste pouvoir changer la template). Du coup le MVC est obligatoire pour les modules. Y'a aussi des model que je réutilise...
 
Maintenant comme dit, je ne me voyait absolument pas créer un combo controller-view avec tous les dossier jusque pour faire un echo 'pouet.'

 
 
Ben je n'utilise pas pas de MVC, pourtant je me suis fais une classe qui me permet de gérer les formulaires avec une grande simplicité. Un truc du genre :
 

echo '
<table>
    <tr>
        <td>' . $form->input('login', 'text', 'alphanum') . '</td>
        <td>' . $form->error('login') . '</td>
    </tr>
    <tr>
        <td>' . $form->input('pass1', 'password', 'alphanum') . '</td>
        <td>' . $form->error('pass1') . '</td>
    </tr>
    <tr>
        <td>' . $form->input('pass2', 'password', 'equal', 'pass1') . '</td>
        <td>' . $form->error('pass1') . '</td>
    </tr>
</table>';

 
Enfin un truc dans le genre... si je me suis pas planté dans les quotes.
 
Ensuite j'ai un système de vérification automatique des données, qui retourne le formulaire pré-rempli, avec affichage des erreurs là où il faut, et s'il le faut... sinon validation des données etc.
 
Edit : Et d'ailleurs c'est précisement de ce genre d'exemple dont je parlais tout à l'heure, quand je parlais de mélange html/php ... Car malgré ce mélange, je trouve le code propre et clair.

C'est trop compliqué Moi je fais le formulaire en HTML normal, il s'occupe de remplir les champs et de tout faire tout seul. Faut juste mettre des class spéciales

 
Tiens, c'est justement comme ça que je suis en train de le refaire
 
Edit : Enfin pas tout à fait en fait... comment il peut le remplir automatiquement si tu fais juste un truc du genre :
 
<input type="text" name="login" />
 

 
Il faut bien que tu mettes un value="quelque chose en php" non ?
 
Ou alors la classe parse ton HTML, et modifie le bordel en utilisant des regexp ?  

Je parse mon XHTML avec DOM

Ah ok, en effet.
 
Pas pensé à ça... je matrise pas. Faudrait que je m'y mette d'ailleurs
 
Edit : Enfin je trouve que ça change pas grand chose au final ... dans ta partie Php il faut quand même que tu définisse que tel champs il doit être alpha-numérique, que celui-ci doit avoir la même valeur que celui là, que celui-ci ne doit contenir que des chiffres etc...

DOM == CACA

DOM = FTW. Y'a pas vraiment d'autres moyens. Pour les messages d'erreur par exemple, ça m'arrive de devoir traverser tout le DOM histoire de chercher un nom de champs (genre un legend pour un groupe de radios). Alors j'ai pas d'autres moyens C'est évidemment pas ce qu'il y a de plus rapide, mais quand on automatise tout, forcément y'a un prix

Le DOM est la pire interface programmatique existante pour le XML.

Ca me fait penser qu'en fait c'est xPath que j'utilise DOM est là juste pour le parsing nécessaire à xpath

 
 
pluzun..
 
mais en plus le formulaire est généré à partir d'une définition, pour le moment chargée en base de données. Actuellement je recode l'ensemble pour utiliser un fichier xml pour la structure du formulaire (champs numérique/ alpha/ spéciaux) et une autre fichier pour le nom et la description du champs (afin de pouvoir facilement créer une version traduite).
 
Maintenant, je crains que ça prenne pas mal de temps.. j'espére que le systéme de cache va bien fonctionner...
 
A pour info, j'utilise simple XML, + Xpath pour "parser" mes fichiers.

<?php
...
?>

<?php
...
?>

 
Je suis horrifié .... Je suis horrifié ....

 
Enchanté, je suis YeLL, je suis YeLL

Moi pour afficher une page HTML... On fout le fichier html et point-barre, rien d'autre à faire . D'ici peut de temps, je faire faire un post plus complet sur ma structure et le fonctionnement général

ça fait un bail qu'on l'attend ce post !

lol Là je suis encore en train d'y faire 2-3 truc, de faire aussi un peu de refactoring, de faire quelques tests unitaires (ou je sais mieux vaut les faire au début), de tester la sécurité... Et surtout de développer un ou deux controllers histoire de voir si c'est bien fait, que ça simplifie effectivement le développement

Topic de qualité    
J'ai pas tout lu mais c'est interessant de voir tous les avis et idées.
 
A ce propos, j'aimerai votre avis sur une petite chose. Jusqu'a quel point peut-on rapprocher un système de template et un framework MVC.  
Je m'explique. Pour moi, un système de template embarque forcement un petit controleur mais le but principal, c'est vraiment un découplement traitement (modele) / présentation (vue). Un framework MVC fait bcp plus. En addition de cette séparation vue / modele, la présence d'un "vrai" controleur permet bcp plus de choses comme la génération de formulaires, le contrôle de données ou la gestion de DAO.
Je developpe actuellement (comme bcp ici ) un système de template très orienté séparation vue / traitement. Mon [petit] controlleur est une classe qui instanciée, parse recursivement un arbre de template jusqu'a l'obtention de la page finale. En bonus, le système gère de facon automatique un layout de base à savoir une page composée de n parties fixes et un partie dynamique (ie index.php?page=ma_page)
 
Tout ça pour dire que je pense qu'il n'y a pas UNE solution miracle mais des solutions avec leurs avantages et inconvénients et que le contexte du site est important dans le choix d'une solution. Il faut aussi voir, lors du développement d'une solution "maison" jusqu'à quel point on veut la rendre générique et réutilisable
 

Oui, il y a plusieurs solutions, le MVC est plus un concept qu'autre chose qui définit les grandes lignes. Après l'implémentation peut varier.

En faite, le mvc est le petit fils du developpement en tiers.
Personnellement, comme je l'avais décris ici mon system qui est un mix entre les deux (tier et mvc) que j'appelle CAMI : Controleur, Affichage, Métier, Information.
J'étais partie dans le concepte java qui était le developpement en tier et par la suite j'ai du rajouter ce que j'appelle contrôleur mais qui est un chef d'orchestre. Avantage c'est que ces systemes peuvent se détacher et ne sont pas dépendant. Je peux router le signal. C'est pas encore parfait mais c'est une autre façon de voir les choses.

Pareil, j'ai essayé de faire le plus indépendant possible. Là déjà mes model sont super-indépendants. Grâce à de belles factory, j'arrive à les coupler facilement dans le MVC.

Le MVC en comparaison avec un systeme de template qui sépare couche dev et intégration ?

Le système de template rentre dans la partie View en fait

 
Euh pas trop d'accord
 
prenons phplib ; le fichier template.php s'occupe de gérer les fonctions et requetes mais en aucun cas de l'affichage propre (aucune balise html etc)

Hein ?
 
La View est en général composée d'une classe qui sélectionne des données, et une template qui les affiches.
 
A la View, on ne doit passer que le strict minimum (idéallement juste le model)

 
hein?
Pourquoi ça s'appelle template, alors, si ça sert à tout sauf à faire des templates?}

 
C'est ce que je dis; le template.php fais les requetes etc et le template.tpl s'occupe d'afficher les données

Oui enfin presque. Le template.php reçoit un objet qui fait les requêtes, hors de question d'avoir du SQL dedans Tout l'accès aux données doit être fait dans le model.

J'ai quand meme bcp de mal a comprendre l'interet d'un tel principe.
 
Explique moi l'interet d'avoir ce que tu me dis en comparatif a un systeme de template ? les pours et les contres ?
 
parce que phplib ou autre fait deja bien les choses, il s'occupe de faire les requetes etc et donne au fichier tpl les infos a afficher
si tu dois modifier ta requete ou autre tu vas dans le fichier impliqué

Il comprend pas
 
A la template (template.php), je lui file un model. Par exemple pour mon module "Menu", je lui file un objet implémentant l'interface module_menu_model_menu. L'objet s'occupe lui de sélectionner les données suivant sont type : xml, mysql.
 
Ensuite dans mon template.php, je peux faire appel à :

Maintenant si j'ai un menu XML, et que je veux changer pour un MySql (site qui prend de l'importance par exemple, ou autres raisons), suffit de changer le type de Model dans la config, et ça roule (c'est de l'injection de dépendance )
 
Si maintenant dans mon template j'aurais eu du SQL, bah pouet, impossible de basculer vers du XML...

 
 
Et pourquoi ca ?
Dans ton template.php qui gere les injections vers le template.tpl tu modifies en xml au lieu du sql  
ca te reviens au meme et tu enleves une couche

Parce que le template.php est fortement couplé au template.tpl, et que parfois j'ai besoin de réutiliser un model ailleurs. Autant qu'il soit le plus générique possible, réutilisable parfaitement dans n'importe quelle condition...

 
Effectivement si tu as besoin de réutiliser les données ailleurs alors oui c'est utile
Si tu utilises des données un peu partout (les memes) il faut passer par une classe ou fonction générale qui va s'occuper de gérer ca  
 
En fait plus je lis ce topic et plus je me demande l'interet réel d'une telle mise en place, je cherche un exemple concret de bascule a ce site  
Mais un exemple viable (une appli tres lourde, un site a tres fort trafic > 4M vu/mois, etc...) pour en voir les réelles possibilités
 
Car la pour l'instant a part que ca fait tres jouli dans une appli et ca impressionne je ne vois pas l'interet de basculer a ce systeme par rapport a un systeme de template poussé.  
 
Je précise d'avance pour les chambreurs ingénieurs que je m'occupe de sites tres lourds a tres forts trafic donc pas la peine de chambrer

L'objectif pour moi, même si c'est pas du MVC ultra-strict, c'est surtout d'avoir des p'tits modules réutilisables pour faire du site rapidos.
 
Pour la partie model, ça m'arrive d'en réutiliser : un modèle menu fonctionne très bien pour un diaporama. Que ce soit un menu ou un diapo, on a une liste d'éléments.
 
Pour la partie controller, l'objectif et de faire de la réécriture d'url automatisée, de mapper une url à une action et ses valeurs.
 
Et pour la partie View, pouvoir être appelée n'importe où, et pouvoir surcharger les template (.tpl) dans le site : chaque module (menu, diapo, etc.) a un HTML par défaut, mais on peut le modifier au sein du site (sachant que les modules sont communs à tous les sites)

Si t'as du SQL dans ton template, c'est pas un template

 
Il veut dire template.php qui injecte vers template.tpl

Et ben voilà

Non mais je m'en fous hein, tout ce que les templates doivent connaître ce sont les données à afficher déjà récupérées, donc elles peuvent avoir une certaine connaissance des modèles, elles peuvent recevoir des infos à côté (paramètres), mais elles ne doivent jamais avoir une quelconque vue de l'implémentation, rien dans la partie "Vue" ne doit accéder au FS ou à un moyen de stockage/persistence quelconque (SQL, cache, ...) de manière explicite

Voilà par exemple pour un menu simple, le constructeur de la view :

Les 3 premiers trucs sont communs à tout le monde (pour le controller et le context, c'est pas encore top, va y avoir du refactoring).
 
Pour le reste, c'est des paramètres sélectionnés par le Controller et transmis à la view. Notez qu'il y a un Model, passé ici par semi-injection de dépendance. Suffit de toucher à la config, de sélectionner un autre type et ça roule, tout se fait de manière transparente

C'est immondement mochissime
 
Tu es prié de ne plus jamais poster ton code ici

C'est normal c'est du PHP
 
Et c'est un cas un peu spécial, vu que cette View peut être récursive et doit d'auto-appeller
 
Si t'as d'autres idées