Tous les frameworks PHP populaires utilisent aujourd'hui leur propre implémentation de couche d'affichage basée sur des templates PHP purs et beaucoup d'aides. J'ai essayé certains d'entre eux et j'ai toujours trouvé que cette approche introduisait d'énormes complications dans des choses assez simples. Par exemple, dans les formulaires Zend Framework et la pagination, utilisez leurs propres solutions pour personnaliser l'aspect de ces éléments. Les helpers réinventent les boucles, fournissant aussi des solutions assez lentes, et la couche vue entière, à mon avis, n'existe pas en une seule partie, mais beaucoup de ses fonctionnalités sont déléguées à d'autres parties du script. Les mêmes problèmes de configuration se sont produits dans Symfony et le générateur d'administration, et dans Kohana j'ai été forcé de dupliquer le même code sur toutes mes formes. PHP est-il vraiment un bon choix pour la couche de vue? Trouvez-vous également ces implémentations peu pratiques ou peut-être, pourquoi malgré tous ces problèmes ils sont bons et ne peuvent pas être remplacés, par exemple par un moteur de modèle intelligent (je ne veux pas dire Smarty :))?Trouvez-vous les implémentations de vue dans les frameworks PHP pratiques?
Répondre
Maintenant, j'aime bien PHP mais en fin de compte, c'est avant tout un langage de template, pas un langage de programmation généraliste nor an object-oriented language. Ne le combat pas. Embrasse le. J'ai regardé quelques frameworks MVC différents comme Symfony, CakePHP et Zend et j'ai du mal à dépasser les exemples. Typiquement, ils sont "avec ces 17 fichiers, vous pouvez faire un programme" Bonjour tout le monde "!" Huh?!?!
Il existe une telle complexité pour résoudre le problème avant que vous n'ayez un problème et je dois encore être convaincu que ces frameworks poids lourds (sont) ajoutent vraiment de la valeur. Je suis plus d'un fan de 'no framework' framework. C'est vraiment "rouler le vôtre" mais je pense que cela conduit à un résultat final le plus maigre et le plus propre.
Je pense également à propos de Smarty. Beaucoup de gens sur SO sont de grands fans de Smarty mais ça n'a jamais été logique pour moi d'ajouter une langue de gabarit à votre langue de gabarit.
En fin de compte je finis par écrire ce type de script PHP la plupart du temps
<?
require 'config.h'; // set up constants, DB connections and so on
page_header('My Page'); // page header, site menu and so on
deny_unregistered(); // security
if (/* user submitted page */) {
$valid = validate_form(/* validation rules */);
if ($valid === true) {
// do db changes
// redirect user ie POST+REDIRECT+GET
} else {
// output error messages
}
}
?>
// display page
<? page_footer(); ?>
Avec une utilisation judicieuse des fonctions d'aide (par exemple, les liens de pagination), ce qui précède est incroyablement facile à lire et à déboguer. Je préfère aussi beaucoup à ce modèle:
URL: /index.php?inc=blah
index.php:
<?
require "$inc.php"; // hopefully you sanitize this but so many don't
?>
Je trouve cela laid, et même dangereux sujettes à erreur. J'ai une hiérarchie de fichiers PHP qui reflète la structure du site (du point de vue du menu) où chaque page est un script PHP. S'ils ont un comportement commun, ils en ont tous les deux besoin (not require_once, qui est généralement utilisé comme un hack pour une mauvaise organisation).
Simple, facile, compréhensible, simple.
Il semble que beaucoup de programmeurs vont jeter un cadre dans le mix avant qu'il n'y en ait vraiment besoin. Je pense que c'est une pratique assez paresseuse et qui coûte cher: chaque décision prise aujourd'hui est une décision qui devient plus difficile à changer plus tard, alors ne prenez pas de telles décisions aussi longtemps que possible. Présenter quelque chose plus tard est plus facile que d'introduire quelque chose maintenant, en découvrant qu'il ne fait pas vraiment ce que vous voulez et en le changeant ensuite.
Il existe plusieurs autres moteurs de modélisation. Cependant, j'ai toujours trouvé le php pur pour être le plus pratique. Je suis juste plus à l'aise avec ça. La chose que je n'aimais pas à propos des aides à la vue dans ZF, c'est qu'elle rendait mon code plus gonflé que le nettoyeur. Je parle spécifiquement de l'aide de $ this-> url() :)