Salut
Je cherche un framework php qui me permettrait de mettre en place sans trop de difficultés un espace membres que je pourrais agrandir par la suite. Je possède un bon niveau en html css php et je gère pas trop mal le sql.
Merci !

Salut,

Je dirais que ça dépend de la complexité de ce que tu veux faire. S'il y a "peu" de fonctionnalités, Lumen ou Slim peuvent très bien suffire (dépendamment de l'approche que tu préfères)

Je te conseille Laravel car il intègre directement un système de connexion! par contre il est plus complexe de l'apprendre comparé au micro framework présenter plus haut mais si tu as un bon niveau en dev web, c'est du gâteaux!!

Si tu veux utiliser un "gros" framework, apprend déjà tout ce qui concerne le modèle MVC avant de t'attaquer à la pratique, ensuite essaye toi à un framework comme Symfony (pas sur OpenClassroom, leur tuto est à côté de la plaque), Laravel ou ce genre de framework, j'ai toujours eu une préférence pour Symfony grâce à son debugger, son système d'authentification etc.. mais chacun son truc.

Je pense que Laravel est une très bonne option car il est basé sur Symphony. C'est vrai que j'ai oublier de précisé que l'architecture MVC est indispensable.

Salut
Merci à tous pour vos réponses !
Pour ce qui est de Symfony j'avais déjà commencé a apprendre à l'utiliser avec le tuto sur Openclassrooms et ce dernier ne m'a pas spécialement aidé (étant donné que c'est le premier framework que j'utilise)... si tu connais un autre bon tuto dessus je suis preneur. ^^
Pour ce qui est des autres frameworks je vais jeter un coup d'oeil !

Salut,
Perso, j'utilise Codeigniter 2 vraiment pas mal : simple, puissant et tout.
Cependant je pense m'orienter sur une techno comme Laravel ,ou node.js pour mes prochains sites.
Quant à Symfony, c'est lourd à mettre en place, perso j'aime pas.
J'ai pas encore testé Laravel mais il a l'air simple et efficace, ce que je recherche.

symfony, lorsque que tu sais où tu vas et que tu connais le framework, ce n'est pas du tout lourd/complexe à installer ni même à utiliser. Par contre, faut éviter cette daube de Doctrine, c'est une plaie à utilise recommande chaudement d'utiliser propel. D'ailleurs, propel hors symfony ça fonctionne et c'est sans doute le meilleurs ORM PHP que je connais.

Bref, si tu veux un environnement qui te contraint par des bonnes pratiques et qui permet de faire évoluer son projet sur du long terme, symfony est une bonne solution (pas la seule).

J'ai utilisé code igniter et c'est vrai que c'est pas mal, mais c'est le seul que j'ai utilisé aussi

J'utilise mon propre petit framework

Mais il est clairement pas aussi complet que Symfony

Le 20 juin 2016 à 21:37:05 Alix_Speroza a écrit :
J'utilise mon propre petit framework

Mais il est clairement pas aussi complet que Symfony

Les sources sont ou pourraient être accessibles ?

Le 21 juin 2016 à 16:42:09 deepblue a écrit :

Le 20 juin 2016 à 21:37:05 Alix_Speroza a écrit :
J'utilise mon propre petit framework

Mais il est clairement pas aussi complet que Symfony

Les sources sont ou pourraient être accessibles ?

Github
Bon, il est clairement pas aussi complet et bon que Symfony, Cake ou CodeIgniter, mais je me débrouille

Le petit ORM est compatible PGSQL

Et, y'a sûrement du code à améliorer

C'est quoi l'url du dépot ?

https://github.com/AlixSperoza

C'était pas bien difficile

Le 16 juin 2016 à 17:48:59 deepblue a écrit :
symfony, lorsque que tu sais où tu vas et que tu connais le framework, ce n'est pas du tout lourd/complexe à installer ni même à utiliser. Par contre, faut éviter cette daube de Doctrine, c'est une plaie à utilise recommande chaudement d'utiliser propel. D'ailleurs, propel hors symfony ça fonctionne et c'est sans doute le meilleurs ORM PHP que je connais.

Bref, si tu veux un environnement qui te contraint par des bonnes pratiques et qui permet de faire évoluer son projet sur du long terme, symfony est une bonne solution (pas la seule).

C'est quoi qui te dérange avec Doctrine ?

Le pattern design pas forcément pragmatique (repository vs datamapper), pas de système de query digne de ce nom [je ne fais pas référence à leur dql] (cf http://propelorm.org/Propel/reference/model-criteria.html de propel) et je vomis ces annotations non explicites et sujettes à de mauvaises interprétations (ne serait-ce que leur manyToOne, oneToMany). Pour terminer, je trouve abominable leur sur-enchère de __call et l'incapacité à accéder directement aux données en base (cf le pattern design). Propel est juste 100x plus pratique et va à l'essentiel selon moi : gérer des données en base en mappant la db avec des classes avec une persistance simple et indépendante de tout service. Doctrine <=> quand tu peux faire simple alors fait compliqué.

Si je comprends bien tu me dis que tu préfères le Active Record à un Data Mapper ?
Ca peut se comprendre, personnellement ayant gouté Doctrine, je ne pense pas pouvoir utiliser un AR, ca me semblerait mal. Je trouve que Doctrine est plus ancré dans une optique de programmation objet, les entités ne savent rien de la database, et il faut un manager pour les persists, ca me parait plus propre. Alors oui c'est ptet plus compliqué, mais rien de ouf non plus.

Les criteria de Propel ont l'air plutôt cool ouais, c'est auto-généré ? Tu as la même avec Doctrine mais en méthode magique, donc nul pour l'IDE, enfin de toute facon tu vas pas me dire que tu fais toutes tes query sans jamais utiliser autre chose que leur filterBy ?

Tu map comment tes relations sur Propel alors ?

Tu as aussi CakePHP qui est à PHP ce que RubyOnRails est à Ruby
Sinon Laravel semble être un très bon choix

Le 25 juin 2016 à 11:16:46 fluxies a écrit :
Si je comprends bien tu me dis que tu préfères le Active Record à un Data Mapper ?

Affirmatif.

Ca peut se comprendre, personnellement ayant gouté Doctrine, je ne pense pas pouvoir utiliser un AR, ca me semblerait mal. Je trouve que Doctrine est plus ancré dans une optique de programmation objet, les entités ne savent rien de la database, et il faut un manager pour les persists, ca me parait plus propre. Alors oui c'est ptet plus compliqué, mais rien de ouf non plus.

Je n'ai pas parlé de complexité mais de pragmatisme. Quand tu fais ton entity avec Doctrine, ton objectif est de dialoguer avec une base de données.

Les criteria de Propel ont l'air plutôt cool ouais, c'est auto-généré ? Tu as la même avec Doctrine mais en méthode magique, donc nul pour l'IDE, enfin de toute facon tu vas pas me dire que tu fais toutes tes query sans jamais utiliser autre chose que leur filterBy ?

Les méthodes filterByXXX sont magiques mais le problème ne vient pas tant du coté magique mais du coté bien fichu des query propel : https://gist.deblan.org/fr/view/576ea3557ecec/f710cf6f59d4e656dac9579d3f6f40fa793279e5
Dans 99% des cas, je n'utilise pas de DQL et les méthodes de filtre de l'ORM sont suffisantes. À savoir que tu peux faire des filterBy en accédant aux query des modèles associés :

$posts = PostQuery::create()
->filterByFoo('bar')
->useBarQuery()
    ->filterByBoo($boo)
->endUse()
->find();

Tu map comment tes relations sur Propel alors ?

Dans un schema XML (ou yaml) : https://gitnet.fr/deblan/gist/src/master/src/Gist/Resources/config/propel/schema.xml (ce n'est pas une application symfony…ça ne change rien de toute façon )

Je n'ai pas parlé de complexité mais de pragmatisme. Quand tu fais ton entity avec Doctrine, ton objectif est de dialoguer avec une base de données.

Tout dépend de la cible de ton pragmatisme alors, si je comprends bien pour toi, c'est plus logique.
Mais ne trouves-tu pas que ton entité, représentant une row et héritant de l'ORM c'est moins "propre" qu'une entité n'ayant aucune connaissance de sa provenance et nécessitant être persistée par un superviseur qui lui, sait ?

Les méthodes filterByXXX sont magiques mais le problème ne vient pas tant du coté magique mais du coté bien fichu des query propel : https://gist.deblan.org/fr/view/576ea3557ecec/f710cf6f59d4e656dac9579d3f6f40fa793279e5

Dans 99% des cas, je n'utilise pas de DQL et les méthodes de filtre de l'ORM sont suffisantes. À savoir que tu peux faire des filterBy en accédant aux query des modèles associé

Intéressant

Dans un schema XML (ou yaml) : https://gitnet.fr/deblan/gist/src/master/src/Gist/Resources/config/propel/schema.xml (ce n'est pas une application symfony…ça ne change rien de toute façon )

Bon enfait les différences ne changent pas grand chose au final, ce qui porte nos jugements est sûrement une question d'habitude non ?