Frameworks

[zzarbi]

Bon, je me répète, mais avec symfony et la présence d'une couche modèle, ne risque-je pas de fragmenter mes requêtes ? Disons que mon contrôleur a besoin pour une fonction du genre combat de récupérer 6 sortes d'infos différentes. Si je passe par des appels au modèle, ça risque de me générer 6 queries, là où une requête et des jointures bien ajustées pourraient me l'éviter. A moins que je ne sous-estime la flexibilité de la chose....

Oui rien ne t'empeche de faire ta requete avec jointures...

Sinon, effectivement Sephi si tu as pour habitude de séparer ta page (et non pas ton code) en plusieur partie genre connexion|requete|affichage c'est en gros ce que fait un MVC sauf que, le MVC comme découper en multiple fichier est beaucoup plus facile à modifier vu que une page est morceler en plusieur fichiers différent de codes... Si tu veux modifier une requete tu sais que tu n'a pas besoin d'aller dans les classe controleur et vue... Ca fait beaucoup de code qu'on a pas besoin de relire...

Cependant moi je n'aime pas le concept MVC (le vrai), ce qui fait que je ne risque pas d'utiliser de framework... J'adore les couches, les templates la POO quoi, mais le MVC n'est pas adapté selon moi aux concept de jeu, beaucoup trop simple... En tous cas pour le jeu que je développe j'aurais besoin de bcp plus de flexibilité et modularité pour la maintenance...

Pour moi les framework comme symfony ne sont utile que pour des sites assez simple genre un blog, ou un portail communautaire, un facebook un youtube, quelque chose de complet mais pas compliqué.

Je connais symfony que de nom, mais si vous dites qu'il a une classe d'abstraction SQL haute, c'est à dire qu'il construit les requetes selon le SGDB... Je pense que juste ça... Ca va faire perdre énormément de temps de calcul... Tu met ça sur SG-univers t'es sûr que le serveur il décède...

[joshua]

euuuuh zzarbi, c'est le contraire....
Les frameworks sont la justement pour gérer des applications complexes. Car ils permettent un meilleur interfacage et surtout facilite le développement. Les applications que tu me cite sont "vraiment" limitées. Le blog on le cite en exemple car il faut 30 min pour en faire un avec symfony, c'est vrai, mais ce sont des exemples......

Et symfony créé une fois les requetes et les stock ensuite. Il le fait pas a la volée. Il s'appuie sur un schema "image" qu'il fait de ta base, ce qui lui permet de la redéployer ensuite sur n'importe quelle BDD qu'il gere.
C'est donc un plus.....

[zzarbi]

c'est marrant comment tu sais dire de manière compliquée ce que j'exprime de manière simple :p
Mais l'interet c'est surtout de pouvoir changer les visu en un clin d'oeil (en gros faut pas savoir faire de php pour faire du html+css) et surtout changer de type de base en un clin d'oeil aussi.
Après oui, c'est un poil plus lourd. Mais l'objet est plus lourd. Seulement tout le monde comprend ton code, tu fais beaucoup moins d'erreur, et c'est plus exploitable.
Tu réécris pas 15 000 fois le meme code.

Heu plus haut tu écris que c'est toi même qui fait ton code... si tu décides de pas mettre de commentaire, de coder sans indentation, et autre ou de mal utiliser le framework je pense pas que tout le monde puisse comprendre mieux ce code qu'un code que j'aurai fait pareil sans objet... sans classe ...
C'est la même chose, la compréhension du code découle de l'utilisation qu'on en fait.

Pareil pour le "tu fais bcp moins d'erreurs"... ca dépend de quelle type d'erreur t'a l'habitude de faire.

Et pour :

Mais l'interet c'est surtout de pouvoir changer les visu en un clin d'oeil (en gros faut pas savoir faire de php pour faire du html+css)

Je dirais que en utilisant simplement smarty qui est super simple d'utilisation on a le même résultat mais en bcp bcp plus rapide...
Aprés faut savoir l'intégrer dans le bon sens... et c'est la que le débutant peut faire n'importequoi.

Mais à un framework je préfèrerais des petites bricks de PHP comme, un controler fait maison, l'utilisation de mysqli avec une classe qui gère le singleton, et l'utilisation de smarty... Ca fait exactement la même chose mais certes avec plus de temps pour le coder, mais bcp moins de temps pour l'execution...

Effectivement on recode la même chose à chaque projet, mais chaque projet est réellement adapter à ses besoins...

PS : Je viens de regarder la demo de génération d'administration... Eh bah pour moi c'est pas du PHP... on modifie un fichier xml, un fichier yml, et les templates qui sont eux en PHP... Et on demande à smarty de générer le reste... Un truc perso je déteste le XML, autant en format d'échange c'est génial, un truc standardisé autant l'utilisé comme ça je trouce ça idiot...

[uriak]

ben recoder, recoder... tout dépend, une classe de login, de connexion etc peut parfaitement être réemployée d'appli en appli Après pour mon projet de jeu, ce qui me rebute c'est de me voir une architecture imposée... je vais faire des requêtes assez spécialisées, donc je pense que la couche contrôleur et modèle ne feront qu'un... mais par contre le contrôleur sera étagé (pour tous les cas ou plusieurs évènements peuvent déclencher la même action)

zzarbi, peux-tu nous expliquer en quelques mots ce que fait Smarty ?

[Loetheri]

J'ai lu ce sujet ... et parfois, je suis assez étonné des arguments avancés.

Quand on me dit qu'il faut utiliser un framework, car, par exemple, tu as des modules tout fait. Désolé, mais tu as des modules tout fait sans utiliser de frameworks. Il suffit d'aller les puiser là où ils existent. Alors soit je suis un débile soit l'argument est mal formulé.

Utiliser un framework est utile sur un CV. Oui et non. Car ton entreprise a beaucoup de chances d'avoir développé son propre framwork ou passe peut-être par un framework qui n'est pas réellement disponible au grand public. Maintenant, cela permet de pouvoir dire "Je sais m'adapter à utiliser un framework" ... Je reste peu convaincu.

On trouve des tutoriaux -_-' Mouais ... Je trouve quand même plus de tutoriaux sur PHP tout simplement que sur un framework (connu ou non).

Dire qu'on peut plus facilement recruter des personnes qui connaissent ce framework est un argument qui me semble assez juste mais relatif ;-) Si on code comme un porc, utiliser un framework ne servira à rien. Cela permet, dans ma vision des choses et je me trompe peut-être, d'avoir plus facilement la même chose si je l'écris ou si un autre l'écrit.

Quand on me dit "J'ai changé de base de données et j'ai changé une ligne et j'ai claqué des doigts", je suis épaté. Mais ... combien de fois cela est arrivé ? Donc utile, oui, mais très très relativement ;-)

Je m'arrête là car je ne sens pas le besoin de continuer. Et de toute façon, vous l'aurez compris, quand les arguments me semblent raisonnables, l'utilisation d'un framework est un avantage ... assez relatif.


Alors comme le dit naholyr, peut-être que les arguments pro-frameworks sont légions mais je ne dois pas les comprendre car je ne veux peut-être pas me remettre en question. Quoi qu'il en soit, aucun des arguments ne me convainc réellement.

[joshua]

j'attends mes collegues pour repondre :p
que je sois aps le seul a defendre le steak, j'ai l'impression d'etre seul au monde :$

[lanoix]

zzarbi, peux-tu nous expliquer en quelques mots ce que fait Smarty ?

C'est un moteur de templates... Il te permet d'avoir tes fichiers "html" dans un dossier particulier en ne contenant que des variables. Dans ton code php, tu assigne à ces variables des valeurs, puis il te suffit de préciser que tu veux une impression de la template X pour avoir le rendu de tes pages. C'est un résumé grossier mais c'est l'idée... Moi je l'utilise, j'aime bien cette séparation, qui permet notamment d'avoir des styles différents, d'internationaliser tes pages, ou encore de travailler plus facilement avec un graphiste (il te fournit une page avec des données bidons, tu as juste à la découper et à mettre tes variables).


@Loetheri : je ne pense pas qu'on puisse donner des arguments à l'utilisation d'un framework dans le vide non plus. Dans un gros projet c'est un choix qui arrive relativement tard dans l'étude... Il faut au minimum que toute l'étude fonctionnelle soit terminée, et que l'étude technique soit en cours. Et il faut toujours connaître un minimum un framework avant de le choisir.
Dans un projet comme nos jeux PHP... A mon humble avis ca dépend beaucoup plus des envies de chacun

[uriak]

Je n'ai pas tellement vu d'arguments à ce sujet, mais est-ce qu'un framework est plutôt bien adapté à du travail en équipe (codeurs > 2 ) ? J'imagine que c'est quand même le principal atout de la chose.

[zzarbi]

zzarbi, peux-tu nous expliquer en quelques mots ce que fait Smarty ?

Pour ton eptit projet uriak je pense qu'il serait effectivement plus simple pour toi de commencer à utiliser des briques comme smarty (moteur de template), et une fois que tu auras plus d'expérience t'interesser au framework si le coeur t'en dit ^^....

Sinon pour faire simple et pas trop HS, smarty est un moteur de template, un gestionnaire de vue, qui a pour but de spérarer réellement le code PHP du code HTML... Suffti de faire un fichier .tpl (template) comem ce ci :

Code PHP :

<?php 

<html>

    <head><title>{$title}</title></head>

(etc.... vais pas faire toute la page) 

[Loetheri]

@ lanoix ^^ : Smarty est, pour moi, (je dis bien pour moi) un surcouche totalement inutile. Pourquoi ? Parce que PHP sans Smarty ou autre, est déjà un très bon moteur de template en soi. Pour cela, il suffit de structurer un poil sa façon de faire. Mais là n'est pas le débat.

Sinon, je veux bien qu'il est difficile de dire pourquoi il faut utiliser ou non un framework. Mais s'il s'agit de cas particuliers ou de cas précis, je ne vois pas pourquoi tout le monde en utilise ;-) Je ne sais pas si je me suis bien fait comprendre. Si ce n'est pas le cas, dites-le ;-)

@ joshua : Je crois que tu n'es pas le seul. Je pense que seulement que beaucoup parmi nous ne vont pas exactement à quoi cela sert.
Pour ma part, je range pour l'instant, les frameworks au même rang que l'Objet sous PHP et les moteurs de templates autre que PHP simplement, c'est-à-dire au rang des choses absurdes. Mais je ne doute pas qu'il y ait de réels avantages; seulement, maintenant, je ne les vois pas ;-)