Frameworks

[janeo]

Alors j'ai tout lu et je trouve ça hyper intéressant.

Je suis d'accord avec naholyr qui dit que PHP est un excellent language de template.

Personnellement je suis un grand débutant en PHP, et voici où j'en suis arrivé.

Je sépare la partie PHP de la partie XHTML. Cependant la "partie XHTML" peut contenir des conditions et des fonctions persos qui génèrent du html très rapidement. Par exemple pour tous mes sites le contenu destiné à être affiché dans le corps est contenu dans la variable $content et une fonction affiche tout.

Ce que je trouve très répétitif en PHP, c'est les formulaires. J'avais lu un tutoriel qui montrait la création de formulaires avec un framework (je ne sais plus lequel), et j'avais trouvé que ça prenait trop de code. J'ai donc développé une classe Form dont l'objectif est d'avoir le moins de code possible, tout en vérifiant les entrées de l'user et en sauvegardant ce qu'il a écrit si le formulaire est invalide.

Ca donne

$f1 = new Form();

$f1->box('label','name','value','minchar','maxchar');
$f1->email();
$f1->select('label','name');
$f1->RTE(); //éditeur de texte riche en javascript sans code (bbcode etc.)

if($f1->getStatus() == 1)
{
//ici je gère erreurs persos (c'est assez rare) et si c'est bon j'effectue les actions nécessaires si le formulaire est valide.
}

$f1->getForm('html si le formulaire est valide'); //En fonction du statut, ça affiche le HTML qu'il faut.

Cette classe a beaucoup de possibilité et permet de créer presque tout ce que je veux très rapidement.

Je suis anti-template, par contre les frameworks pourquoi pas, j'attend de voir l'évolution du débat. Que pensez-vous de Zend Framework?

[Loetheri]

Dire que je n'ai aucune connaissance en objet, c'est faux. Mais il est clair que je ne maîtrise pas tous les tenants et les aboutissants.

Cependant, même si, ne le prends pas mal, tu te considères comme ayant plus de visions, je suis désolé mais PHP n'est pas fait pour l'objet, même si on considère les démarches que tu proposes. Ce sont une échappatoire, une roue de secours mais jamais un moyen réel de profiter de l'objet. Maintenant, tu as ta vision et moi, la mienne.

Cela dit, si on veut discuter de l'objet, j'invite quelqu'un à faire la démarche d'en parler ailleurs. Car moi, cela m'intéresse vraiment de savoir pourquoi certains estiment qu'utiliser un framework est intéressant.

[janeo]

Précise ta pensée avec des exemples s'il te plait pour l'objet car je ne comprend pas très bien Loetheri.

[zzarbi]

Je vais repréciser ma pensée en ce qui concerne l'objet.
L'objet sous PHP est et reste une absurdité. Pas à cause de l'objet en soi mais tout simplement parce que son utilité est ... réduite à la création de la page. Si je crée un objet, il est limité à la page. L'objet, outre les différents aspects qu'il apporte, devient nul en PHP. Je dis bien en PHP.

Ca par contre c'est absurde...
L'objet en PHP comme dans n'importe quel langage de programmation c++, java ou autre existe uniquement lorsqu'il est exécuté... Maintenant une application en php l'objet existe en mémoire que quand il est executer, exactement comme une application en java, la seul différence et c'est pas lier au langage c'est que normalement les application en java ou C++ dure plus longtemps (et encore) qu'un script en php qui lui dure qqes secondes.

maintenant fait une application en java qui créer un objet y fait des opérations et affiche juste un résultat le temps, le fonctionnement, le résultat sera exactement la même chose qu'en PHP...

[Edit :] A l'aube de l'objet à la fin du C, tous les programmeurs ont dit "le C c'est pas fait pour de l'objet, le C++ c'est evil"...
Avec le PHP c'est pareil, dans le sens ou c'est faux... Le C++ s'en sort plutot bien et mainten le c# est quasiment parfait mais je préfère largement le Java...

Pour en revenir au framework, là ou je le vois super utile c'est pour faire énormément de formulaire par exemple les panneaux d'admin de nos jeux... Plein de code qu'on devrait copier/coller sans framework

En conclusion l'objet en PHP5 est tout à fait comme les autres... Pour ceux qui trouve que c'est mal implémenter, moi j'aimerais bien savoir en quoi... J'ai fait fu java j'ai rien vu qui n'était pas fesable en PHP 5.

[lanoix]

Cependant, même si, ne le prends pas mal, tu te considères comme ayant plus de visions,

Je ne me considère pas "en sachant + que toi". Je suis un développeur/architecte pro Java. Tout ce que je connais viens de là, et je code en PHP comme je code en Java. Pour moi c'est devenu naturel de faire des objets, et j'ai su bien les intégrer dans mon PHP de tous les jours. Mais je ne suis pas pour autant une référence lol... J'ai justement cette vision (trop) "javaïste", partisant de "concepts particuliers" en programmation. Par contre je ne suis pas pour l'utilisation des frameworks à outrance, malgré l'impression que je donne peut-être. Je n'utilise quelque chose comme Smarty (dont on parlait) QUE si c'est pleinement justifié. Je ne l'utilise pas dans mes "petits sites".

Pour moi si je dois conclure un peu ce débat aujourd'hui c'est "Framework oui, assurément, à condition d'avoir des bases minimum et de bien étudier la question." (En gras au cas ou qq lis en diagonale)
On ne prend pas un framework pour dire qu'on en prends un


NB: ca fait 3 fois que tu me dis "ne le prends pas mal", mais pas de soucis, je pense qu'on est là pour exprimer ses divergences d'opinion... On a pas encore trop troller :motard:

[pascal]

j'ai une approche pragmatique des frameworks :
_ gain de temps, via la création de la couche d'accès aux données
_ gain de temps, via la génération de modules d'administration
_ gain de temps, via l'installation de plugin ( authentification, blog, cms...)
_ gain de temps, via les fonctionnalités natives ( internationalisation, sécurité, gestion des formulaires ... )

à noter que le sytème de template de symfony est ... PHP, mais que l'on peut utiliser Smarty ou d'autres.

voili voilà, je veux forcer personne à utiliser un framework!

A+

Pascal

[naholyr]

pour l'écrire de cette manière ta logique de calcul/affection est "au-dessus", pas spécialement le même fichier mais au même niveau (niveau d'exécution), donc dans la couche business.

Pas du tout

Si mon moteur de template a cette forme :

Code :

<?php
class Template {
    protected $vars = array();
    function set($var, $val) {
        $this->vars[$var] = $val;
    }
    function render($template_filename) {
        extract($this->vars);
        include $template_filename;
    }
}

Difficile de faire plus court :lol:
Et en plus, ça marche

Code :

<?php

$moteur = new Template;
$moteur->set('prenom', 'Bob');
$moteur->set('infos' => array(
    'nom' => 'Jones',
    'prenom' => 'Bob'
));
$moteur->render('monFichier.php');

L'exemple que j'ai donné marchera «tel quel» et pourtant la vue est bien encapsulée dans le niveau d'exécution de la fonction «render», ce qui signifie qu'elle n'a accès qu'à $this (qui représente l'instance du moteur de template, totalement justifié au niveau de la vue), $template_filename (pratique non ? ) et les variables définies par "set". Donc aucun problème de mélange des niveaux, tout est bien séparé. C'est le fonctionnement du moteur Savant.

@ naholyr : Tu dis qu'il faut en saisir le sens ^^ Je suis d'accord mais quels sont les avantages réels de l'usage d'un framework.
Pour ton exemple sur les requêtes, j'avoue avoir été perdu au début du deuxième paragraphe ^^

Si tu n'es pas familier de la conception objet, c'est normal C'en est un des avantages : la surcharge de méthode permet ce genre de possibilités très simplement.

L'objet sous PHP est et reste une absurdité. Pas à cause de l'objet en soi mais tout simplement parce que son utilité est ... réduite à la création de la page. Si je crée un objet, il est limité à la page. L'objet, outre les différents aspects qu'il apporte, devient nul en PHP. Je dis bien en PHP.

Et pourtant, justement avec les frameworks et les système de persistence en base de données (autrement appelée ORM pour «Object Relational Mapping»), l'objet devient persistent, il a une vie propre sans qu'on ait à se soucier de le stocker de nous-même.
Bien sûr tu entendais surtout qu'un objet doive vivre dans la mémoire du serveur, mais c'est aussi possible avec APC ou MemCached.

Tu sembles penser que ça marche nativement dans d'autres langages, mais en Java cela nécessite l'utilisation de Hibernate, en Python cela nécessite l'utilisation d'un framework (comme Django), etc… Aucun langage n'offre ce type de fonctionnalité comme ça, magiquement, ça passe toujours par une librairie tierce.

Cela dit, si on veut discuter de l'objet, j'invite quelqu'un à faire la démarche d'en parler ailleurs. Car moi, cela m'intéresse vraiment de savoir pourquoi certains estiment qu'utiliser un framework est intéressant.

Tout ceci est intimement lié : un framework implémentera toujours le concept MVC, ce qui implique de faire un choix pour la vue, et donc de sélectionner un type de moteur de template. Et un framework reposera toujours sur une conception orientée objet.

On ne peut donc pas discuter de l'utilité d'un framework sans discuter de ces deux autres points

[joshua]

@janeo: juste pour la forme, ton idée de classe est très bien.
Maintenant regarde, tu verras que symfony te propose la meme chose: -> http://www.symfony-project.com/book/trunk/10-Forms

Je ne cherche pas non plus a imposer les framework.
Pour ma part j'ai développé en C, un poil en C++, et depuis je fais de l'exploit, donc du shell ^^, et encore quand je code (c'est l'avantage d'etre chef :p )
Par contre dans mon temps libre, je m'essaie a pas mal de choses.
J'ai développé mon premier site en procédural, intégralement. J'ai décidé que pour SWRoE, je ferais de l'objet, et en essayant l'objet, j'ai découvert le MVC. Et en découvrant le MVC, grace a pascaltje, je viens de découvrir les frameworks.
Alors apres 10 000 pages de lectures pour en arriver là, je vous dis juste que ca semble bien prometteur ^^
Parce que comme tout bon informaticien, je suis faineant et j'aime les choses qui marchent.
Pourquoi se priver?

[lanoix]

Pas du tout

Bah désolé si, tu es au même niveau d'exécution (et pas d'encapsulation); ton exemple le prouve... Si ton designer se plante dans son PHP, ton site plante. C'est court, ca marche, et tu trouves ca propre, tant mieux pour toi.

Mais peut-être faudrait-il rajouter que...
- Smarty ne permettra pas à mon designer de faire planter mon site... Tout au plus sa template va planter, mais jamais mon code
- Smarty va gèrer les erreurs liées aux templates de manière propre
- Smarty m'offre des fonctions plutôt utiles formattant mes balises automatiquement (html_img, html_select_date, html_select_time...)

Ce sont surtout les 2 premiers points qui terminent la séparation code/design. Savant pour gèrer les erreurs à sa manière aussi, mais si tu veux te protéger des erreurs il faudra je crois rajouter une classe qui compile tes templates non? Et là Savant devient "pareil" à Smarty...

Tu sais, si un framework est créé, évolue et perdure, c'est qu'il y a des raisons. Un framework qui ne répond à aucun besoin tombe vite aux oubliettes...


NB: Je n'utilise Smarty que dans 2 projets... Je répète que l'utilité doit en être prouvée!

[naholyr]

- Smarty ne permettra pas à mon designer de faire planter mon site... Tout au plus sa template va planter, mais jamais mon code

Tu as de la chance :lol: le mien m'a fait sorti X fois des Fatal Error… Et bonjour pour aller débugger du Smarty… Il faut aller chercher l'erreur dans le PHP auto-généré, afin de remonter vers l'erreur dans le template, et vue la gueule du PHP auto-généré je te souhaite de ne jamais aller y faire un tour.
Si mon designer introduit une Fatal Error dans le template en PHP, cela ne concernera que la page où le template est utilisé, ni mieux ni moins bien que pour Smary

- Smarty m'offre des fonctions plutôt utiles formattant mes balises automatiquement (html_img, html_select_date, html_select_time...)

D'où l'utilité de «helpers», des fonctions (ou des méthodes de l'objet Template) qui offriront ce genre de raccourci

Tout n'est qu'une question d'organisation et de propreté. On peut faire du crade avec n'importe quoi, on peut pourrir des fichiers de config même s'ils sont en Yaml, on peut pourrir un template et faire planter la page quel que soit le moteur derrière, etc… D'où les formations :lol:

L'important étant qu'on est je pense tous d'accord là-dessus : Quel que soit le langage de template, il faut séparer la couche métier de la couche présentation de façon claire et concrète. Pour cela, il faut passer par un intermédiaire (un moteur de template, qu'on pourrait appeler «vue» dans le concept MVC )

Tu sais, si un framework est créé, évolue et perdure, c'est qu'il y a des raisons. Un framework qui ne répond à aucun besoin tombe vite aux oubliettes...

En effet, mais Smarty n'est pas un framework (PEAR en est un). En revanche, Symfony dont on peut dire qu'il évolue et perdure, a choisi pour ses templates le moteur... PHP (bien sûr, comme c'est du modulaire, on peut aussi remplacer les vues par du Smarty si on préfère).