Le but de Zend Framework est de fournir un ensemble de composants de très haute qualité pour le développement web en PHP 5, avec une documentation de l'API et un manuel maintenu continuellement. Pour cela, Zend veut reprendre les recettes qui ont fait le succès de PHP : des solutions simples et élégantes qui fonctionnent partout.
Bien qu'en concurrence avec les autres projets de framework, ZF encourage la création de framework PHP. (symphony , CodeIgniter , CakePHP , QCodo ).
Gageons que ZF jouira d'un certain succès. Le libre ayant déjà par ailleurs une très nette domination dans le développement web avec Ruby et RoR, Python et Plone, voire Java et Apache. L'avenir nous dira si Zend Framework est ou n'est pas un clou de plus sur le cercueil du web propriétaire. Zend est une société fondée par Andi Gutmans et Zeev Suraski (le nom Zend est un mot-valise de leurs prénoms Zeev et Andi) et connue pour son moteur de langage de script à la base du langage PHP (depuis la version 4) : le moteur Zend. Le moteur Zend a été un accélérateur du succès de PHP.
Cette fois-ci, Zend continue d'améliorer ses outils de développement web, mais en aval cette fois ci en proposant un framework de développement web pour PHP5. Un framework est un espace de travail modulaire, un ensemble de bibliothèques permettant le développement rapide d'une application.
On pense à PEAR, un ensemble de classes suivant des conventions de développement et installable depuis un outil en ligne de commande. ZF est plus cohérent et plus restreint. Par exemple, il n'y a pas deux classes qui font le même travail. Le suivi est donc beaucoup plus exigeant par rapport à PEAR.
L'ensemble des classes de ZF est réparti en deux grosses parties : ZF Core et ZF Incubator. On aura vite compris la distinction. Dans le premier cas ce sont les classes fonctionnelles, stables et maintenues tandis que le second cas contient les classes ayant vocation à rejoindre Zf Core à terme.
ZF Core est lui même réparti en composants répondant à différentes problématiques. Par exemple la problématique de l'authentification et de l'autorisation propose les paquets Zend_Acl, Zend_Authentication et Zend_Session et leurs classes respectives. Ainsi de suite pour l'accès aux bases de données, l'i18n & la l10n, le MVC et quelques autres.
À noter que l'accès aux bases de données utilise l'abstraction PDO ou certaines extensions spécifiques de PHP (tel Mysqli). Le but du ZF n'est pas d'implémenter une nième abstraction du SGBDR, mais de fournir une implémentation de la représentation et de conception de requêtes, transitions modèle relationnel-modèle objet, etc.
Le gros avantage que l'on peut trouver à ZF par rapport à certains frameworks (par exemple symphony), c'est qu'on est loin d'une usine à gaz. La découpe en composants permet d'utiliser ceci sans cela, avec une flexibilité qui rappelle furieusement celle de PEAR. L'arborescence de l'application imposée par MVC est très flexible et très légère. Il est très facile de choisir son moteur de modèle (par défaut c'est PHP, bien sûr) pour opter pour le tout aussi connu que lourd Smarty.
Zend a vraiment fait jouer la communauté. Fort de l'énorme popularité de PHP tant chez les petits bidouilleurs de scripts infâmes et bardés de failles de sécurité que chez les professionnels. Les contributions sont nombreuses. Le site est orienté pour attirer les contributeurs. Cependant, il faut noter que Zend garde les rênes du projet et les contributeurs doivent signer un accord de licence des contributeurs permettant de formaliser les contributions en vue de se protéger d'attaques juridiques telle celle de SCO. Les contributeurs ont et gardent leurs droits sur la contribution. Le ZF est distribué sous licence New BSD, licence approuvée par l'OSI, mais qui pose problème selon la FSF, voir l'article Le problème de la licence BSD sur le site du projet GNU.
Assez rapidement, ZF a été utilisé malgré son état alpha. De fait, certaines évolutions ont cassé la compatibilité ascendante, mais des paramétrages permettent malgré tout de faire tourner une application conçue avec ZF 0.8beta dans un environnement avec ZF 1.0.0 moyennant peu de changement de code (notamment au niveau de l'implémentation du MVC).
ZF serait-il déjà victime de son succès ?
Aller plus loin
- Zend framework (8 clics)
- Communauté francophone de développeurs Zend (6 clics)
- Téléchargements (3 clics)
- Feuille de route (3 clics)
- PHP (2 clics)
- QEDwiki, un exemple d'utilisation de ZF (Flash) (2 clics)
# mouais
Posté par Éric (site web personnel) . Évalué à 10.
Mettre "à la suite de Ruby On Rails" dans le titre c'est chercher les coups. Je ne me lancerai pas dans une argumentation sur Ruby On Rails mais ZF c'est un ensemble de briques élémentaires à peine collées ensemble. On est très loin d'un framework intégré et complet. C'est d'ailleurs à la limité entre une bibliothèques de composants et un framework. Comparer ça à Ruby On Rails (ou même à symfony ou Plone) c'est aller plus que vite en besogne.
Ce qu'ils font est bien, même si ça va assez lentement par endroits et que le résultat n'est pas très "sexy" mais c'est encore loin des autres solutions intégrées.
Note tout de même parce que je suis étonné de trouver ça ici : on parle bien de "new BSD", autrement appelée "BSD modifiée". Le texte de la FSF à propos du problème BSD c'est justement pour l'"ancienne" BSD avec la clause de publicité. Il n'y a aucun problème avec cette licence (même si certains préféreront peut être un copyleft).
[^] # Re: mouais
Posté par or zax . Évalué à 9.
Le seul est intérêt de ZF est de rappelé au monde que PHP 5.X n'est plus un simple langage de script mais peut être un véritable environnement OBJET de développement. Sur ce point là ZF est une très bonne chose.
[^] # Re: mouais
Posté par totoro . Évalué à 0.
C'est pas un peu trop dès le Lundi matin ?
[^] # Re: mouais
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
On peut faire des choses très propres en objet avec PHP5.
Certes, il manque peut être quelques trucs par rapport à d'autres langages objets super avancés (namespace par exemple, mais ça viendra dans PHP6), mais le minimum est là et bien là, et suffit déjà largement à faire des trucs convenables. On a pas toujours besoin de l'artillerie lourde des autres langages pour faire un bon soft.
[^] # Re: mouais
Posté par yellowiscool . Évalué à 7.
L'esprit est pas orienté objet dans php. Il suffit de constater l'énorme liste de fonctions, avec un nom différent pour chaque action.
Envoyé depuis mon lapin.
[^] # Re: mouais
Posté par or zax . Évalué à 7.
Par contre depuis PHP 5.X je ne fais que de l'objet au quotidien sur des applications grands compte à forte audience (centaines de milliers d'utilisateurs), çà tient la charge, le code se structure facilement et est maintenable, grâce à l'utilisation de framework notamment.
[^] # Re: mouais
Posté par cgo2 (site web personnel) . Évalué à 6.
Selon moi c'est clairement une couche rajoutée à l'arrache par dessus ; il n'y a qu'à voir tous les problèmes d'implémentations (mais d'après la doc, c'est pas des bugs, c'est des *features*), par exemple :
- Impossible de dériver une méthode statique (parceque pas de late static binding), ce qui supprime un paquet de possibilités de conception objet
- $this qui change quand ça lui plait (dans certains cas, quand on appelle une méthode d'une classe A à partir d'une méthode d'une classe B, $this dans la classe A pointe sur... B)
- $this qui n'est rien d'autre qu'une variable vaguement protégée : si on essaye de l'assigner directement ($this = 'toto') on obtient une erreur, par contre il est possible de la modifier en passant par une référence, ou avec certains fonctions comme extract...
Bref, c'est pas encore au point.
[^] # Re: mouais
Posté par choon . Évalué à 0.
Blague à part, le coté objet rajoutée sur une base fonctionnelle,c'est ça qui est chouette... besoin de bricoler un truc en 10 lignes et en 2 minutes? Tu peux. Besoin de plus de méthode? Tu peux aussi :-)
C'est aussi un langage qui permet d'apprendre en douceur... des scripts crados mais simples à comprendre au début, puis une meilleure organisation et le monde de l'objet si on souhaite aller plus loin.
Je ne suis pas en train de dire que tout est parfait mais quand même... ça va dans le bon sens. PHP5 a amorcé un virage vers des pratiques plus saines, ça s'accentuera encore avec PHP6.
[^] # Re: mouais
Posté par CrEv (site web personnel) . Évalué à 6.
Le problème c'est que trop souvent le passage à la deuxième étape (du code propre quoi) est limité / oublié
Alors qu'avec un bon langage objet bien fait et simple (tout le monde a compris que je parlais de ruby ;) ) on est tout de suite dans la deuxième étape, tout en faisant des choses simples.
[^] # Re: mouais
Posté par choon . Évalué à 1.
Pourriware is not a crime. ;-)
[^] # Re: mouais
Posté par yellowiscool . Évalué à 3.
C'est orienté objet, rapide, et clair.
Au passage, le fichier est automatiquement fermé à la fin du thread. Ruby permet aussi de coder spécialement.
Envoyé depuis mon lapin.
[^] # Re: mouais
Posté par CrEv (site web personnel) . Évalué à 3.
Pour moi, Ruby c'est du perl en plus simple et plus beau ;-)
Sérieusement, je conseil à tout le monde de regarder ruby. Je ne dis absolument pas que tout le monde doit coder en ruby, mais le modèle objet de ruby est assez sexy et vraiment intéressant.
Et on a je trouve justement un langage dans lequel on peut coder vite et bien (ruby étant assez succint).
ben en fait presque...
pour moi, un bon code doit être tant que possible un beau code
l'avantage de commencer en écrivant du code propre, est qu'on en prend assez vite l'habitude et donc on continue a faire des choses propres. Ca n'empèche pas de faire du code un peu roots mais ça doit être vraiment limité.
Le problème de commencer par du code sale mais qui marche est qu'on a aucune raison d'écrire proprement puisque ça marche... et changer ensuite de façon de coder n'est pas forcément simple.
Le résultat que j'en ai vu, c'est des fichiers h/cpp assez halucinant :
dans le même .h : 300 lignes de defines suivit des définitions de 11 structures et 7 classes (dont l'une d'environ 700 lignes sans commentaires, tous les attributs étant en plus public évidemment).
Le .cpp correspondant fait un peu plus de 46000 lignes, avec des fonctions de plusieurs milliers de lignes, des imbrications type :
if / while / if / if / switch / switch / if / switch
et des fonctions prenant 21 paramètres.
Alors oui ça marche (c'est en prod) ... mais putain que c'est crade !
Pour moi un code doit être beau, se lire relativement facilement (ça dépend évidemment des algos derrières mais si on en fait abstraction ça doit être facile à lire) et compiler sans erreurs ni warnings
/me a fini son petit moment evangeliste de beau code ;-)
[^] # Re: mouais
Posté par choon . Évalué à 0.
Et que fais-tu du plaisir d'apprendre ? C'est pourtant une vraie bonne raison.
[^] # Re: mouais
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
/me retourne se pendre avec des méthodes de 4000 lignes à modifier...
[^] # Re: mouais
Posté par choon . Évalué à 5.
;-)
[^] # Re: mouais
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: mouais
Posté par choon . Évalué à 2.
[^] # Re: mouais
Posté par romain . Évalué à 2.
Au minimum.
[^] # Re: mouais
Posté par jmny . Évalué à 2.
[^] # Re: mouais
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 0.
Tel que tu décris ce processus, c'est tout à fait normal. Ça s'appelle le polymorphisme.
[^] # Re: mouais
Posté par cgo2 (site web personnel) . Évalué à 2.
C'est simplement une "feature" liée (selon moi) à l'implémentation légèrement foireuse de $this, de la gestion du contexte et des méthodes statiques (encore elles).
Documenté par ici : http://fr3.php.net/manual/fr/language.oop5.basic.php
Après, peut-être que tu vas m'expliquer que c'est tout à fait normal, mais là comme ça, je vois pas...
[^] # Re: mouais
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
C'est vrai que ce que tu décris pourrait paraître un bug par rapport à d'autres langages objets. Pour moi effectivement, $this ne devrait pas avoir d'existence dans une méthode statique, puisque ce n'est pas une méthode d'un objet instancié.
Mais bon, si ils déclarent dans PHP que ça se passe autrement, pourquoi serait-ce un mal ? Surtout si ladite méthode est explicitement déclarée avec "static" ? (et donc le développeur, sachant le comportement de $this, sait à quoi il s'attend puisqu'il s'agit effectivement d'une méthode statique)
[^] # Re: mouais
Posté par or zax . Évalué à 1.
C'est une chose qui relève plus d'un problème de mentalité chez php que d'un problème objet, php encourage un laxisme navrant dans le language, j'apprécie les capacités techniques de php et son modèle objet par contre de base ils partent du principe que même si un développeur écris n'importe quoi il faut que çà marche.
[^] # Re: mouais
Posté par or zax . Évalué à -1.
* Pour le deuxième point je demande à voir sur un exemple concret. Car l'affirmation me parait grosse
* pour le fait de changer $this par extract forcément si tu voulais savoir qu'un langage çà se casse, je te fais des exemples équivalent en JAVA, C++ quand tu veux.
Enfin le modèle objet n'est pas une surcouche vu que c'est le moteur objet de Zend sur lequel se repose PHP, le modèle objet est écris à un niveau plus que l'implémentation même du PHP.
Il n'empêche que point de vue ergonomie d'utilisation de modèle objet, je préfère d'autres langages que le php (ruby par exemple) mais ce n'est qu'une question de goût
[^] # Re: mouais
Posté par Antoine . Évalué à 3.
Tu oublies que dans certains langages objets pas totalement bridés (*) , une classe est aussi un objet. Donc dériver une méthode statique (plus exactement une méthode de classe) est tout à fait normal.
Enfin c'est rigolo de voir des gens qui parlent de "POO" en restreignant toujours leur horizon à la sémantique de langages comme Java ou PHP.
((*) exemple : Python)
[^] # Re: mouais
Posté par CrEv (site web personnel) . Évalué à 2.
[^] # Re: mouais
Posté par or zax . Évalué à 2.
[troll]
Et un langage qui ne gère pas la notion d'entité sans état correctement (classe) est un langage qui bride bien beaucoup je trouve.
[/troll]
[^] # Re: mouais
Posté par Antoine . Évalué à 3.
Sauf que pour le coup tu n'as rien démontré.
[^] # Re: mouais
Posté par or zax . Évalué à 0.
l'intérêt d'un objet est de rattacher des traitements à des états propres à chaque localité (du fait de l'existence des attributs), une classe statique est une entité qui ne peut avoir qu'un seul état à un moment donné.
La conséquence est que l'on a pas besoin de se rattacher à une instance pour manipuler l'état en cours. L'absence d'instance fait que l'état est disponible de façon globale de n'importe où.
Cette accessibilité globale fait que la surcharge ou l'héritage sur une entité à un seul état possible (élément statique) n'a pas de sens, car n'ammène aucune flexibilité supplémentaire :
Tu as besoin de récupérer une fonctionnalité statique ? Elle est disponible depuis n'importe quel endroit du code, donc héritage inutile.
Tu as besoin de personnaliser une fonctionnalité statique ? tu appelles ta fonctionnalités statique récupère le résultat et le retravaille, donc surcharge inutile.
l'intérêt de l'héritage et de la surcharge est de pouvoir factoriser et personnaliser des fonctionnalités sous forme hiérarchique sur toutes les états existant d'une entité, car tu gardes dans tes attributs d'instance, l'état spécifique à chaque instance tout en récupérant tes fonctionnalités déjà écrites.
Bref c'est du basique de POO.
[^] # Re: mouais
Posté par Antoine . Évalué à 3.
Tsss...
une classe statique est une entité qui ne peut avoir qu'un seul état à un moment donné.
Une classe n'est "statique" que 1) si le langage en a décidé ainsi, ou 2) si l'idéologue (toi en l'occurence) a décidé qu'il devait en être ainsi.
Cette accessibilité globale
Une classe n'est pas nécessairement globale (sauf dans ton monde à toi, bis repetita).
L'absence d'instance fait que l'état est disponible de façon globale de n'importe où.
Pardon, mais là où je me place une classe est une instance d'une métaclasse. Donc la supposée "absence d'instance"...
Bref, tout ça pour dire que tu as ta vision très particulière de la programmation "orientée objet" et tu as du mal à accepter que certaines implémentations ne s'y conforment pas. Un cours magistral ne vaut que s'il n'est pas contredit par la réalité.
[^] # Re: mouais
Posté par or zax . Évalué à 0.
Maintenant que des implémentations font plus le concept de base, tant mieux, il faut évoluer, mais tout ajout ne devient pas quelque chose d'utile et géniale parce que c'est 'nouveau'. C'est génial quand cela apporte une valeur ajouté dans les problématiques que l'on rencontre dans la conception d'application efficace, maintenable et pérenne.
Je n'utilise pas un langage pour faire un étalage de syntaxe histoire que la programmation soi plus fun, un langage est un outil qui doit à travailler mieux, et plus vite.
Maintenant si je me trompe et que cet ajout à une réelle valeur ajoutée, expliques moi, je ne demande qu'à comprendre, en attendant, j'ai argumenté mes propos.
Prend le cas du Ruby, il a certains aspects qui peuvent paraitre exotique dans son implémentation de l'objet, mais ces spécificités se sont révélées souvent utiles pour mieux architecturer l'application. En plus d'autres facteurs totalement irrationnels de l'ordre du goût personnel, font que c'est mon langage préféré niveau objet.
Par rapport au python qui est en soit un super langage, tu présentes certaines spécificités comme un plus, explique en quoi c'est un plus ? Si c'est juste pour dire sur le papier python fait çà que tel autre langage ne fais pas ... intérêt zéro, si par contre cela apporte un mécanisme qui simplifie l'implémentation de certains design pattern, alors super !! Ce truc est génial.
Donc les implémentations des langages c'est le dernier de mes soucis, tu présentes quelques choses de spécifiques, explique en quoi cette spécificité est un plus et non un simple argument de l'ordre "qui a la plus grande".
[^] # Re: mouais
Posté par Éric (site web personnel) . Évalué à 4.
Java n'est pas "le concept de base".
Que le statique d'une classe soit en fait une instance d'autre chose (la méta classe), ça découle directement que la classe est un objet à part entière. C'est au contraire en plein dans le concept objet que de pouvoir faire tout ça.
Ce n'est pas parce que Java a asséché l'objet en ne gardant qu'une partie que c'est la philosophie objet qui veut ça.
Si spécificité il y a par rapport au modèle objet, c'est plutot Java qui l'a (vu que Java a fait le choix de ne pas tout mettre en objet mais de présenter aussi des concepts informatiques "en dur" : types primitifs, classes, interfaces, etc.).
D'ailleurs Ruby n'est en rien "spécial" de ce côté là. Les langages qui permettent de représenter les classes sous forme objet sont légion.
[^] # Re: mouais
Posté par or zax . Évalué à 2.
Je suis d'accord et partage ton avis sur tous les points.
[^] # Re: mouais
Posté par Antoine . Évalué à 3.
mais tout ajout ne devient pas quelque chose d'utile et géniale
Je n'ai pas dit que tout était génialement utile, je répondais à l'origine à ta grosse connerie selon laquelle, je cite, "une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO". Que tu t'arc-boutes sur un discours abstrait et péremptoire ne me donne pas envie de continuer cette discussion.
Quant à savoir pourquoi dériver une méthode de classe peut présenter une utilité, tu le découvriras bien un jour en quittant les discours creux et en programmant pour de vrai.
[^] # Re: mouais
Posté par or zax . Évalué à 2.
"une méthode statique est une méthode appartenant non pas à un objet mais à une classe, donc la dériver c'est un contre sens en POO", c'est mon opinion, tu ne l'as partage pas, tant mieux et il faut de la diversité de discours je ne suis pas contre, par contre tu as contre argumenté par rapport à l'implémentation d'un langage ce qui est à côté du propos.
Et ma grosse connerie elle a été argumenté contrairement à ta position d'offusqué !
Alors tu peux essayer de jouer au grand par ton ton condescendant, tu n'en rendras que plus creuse ta position.
[^] # Re: mouais
Posté par totoro . Évalué à 3.
Ça veut dire que php est un langage fonctionnel comme Haskell ? Ou ça veut juste dire que PHP est conçu pour être adapté à sa fonction ?
PS:
Tant pis si je me fais encore moinsser hein ;)
[^] # Re: mouais
Posté par reno . Évalué à 2.
Je ne pense pas que tu te fasse moinsser pour une demande d'explication sur une phrase pas très clair..
[^] # Re: mouais
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: mouais
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: mouais
Posté par windu.2b . Évalué à 5.
Et il faudrait aussi penser à "Objetiser" certains lots de méthodes: fichiers, images, BDD (bon, pour ça y a PDO)...
Devoir se trimballer un $fp, ça va 5 minutes...
[^] # Re: mouais
Posté par Éric (site web personnel) . Évalué à 7.
> constructeurs, ce qui n'est pas rien!
La surcharge n'est pas un problème d'architecture objet, c'est un problème d'architecture des langages statiques.
C'est vrai que ça peut être sympa dans certains cas mais dans la grande majorité, quand tu as un langage à typage faible dynamique, tu n'en simplement pas besoin.
> Et il faudrait aussi penser à "Objetiser" certains lots de méthodes
Ca avance mais c'est vrai que là il y a encore du boulot pour proposer des objets qui cachent tout ça.
[^] # Re: mouais
Posté par or zax . Évalué à 5.
Ensuite que tu pointes une ressource par une variable $fp, un objet ou autre cela change rien, par contre si tu structures ton code correctement en objet, tu n'as pas cette problématique de te le trimballer en permanence
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mouais
Posté par Bozo_le_clown . Évalué à 5.
http://fr.wikipedia.org/wiki/Python_%28langage%29
Sinon la primeur des paramètres nommés revient plutôt à tcl.
[^] # Re: mouais
Posté par totoro . Évalué à 3.
Sans allez dans une conception très poussée de la notion d'objet comme Smalltalk, on est encore loin de Java ;)
[^] # Re: mouais
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
De toute manière, php, c'est du perl simplifié qui a 10 ans de retard sur perl. Honnètement, je n'ai jamais vu l'intérêt de ce langage. Tu peux faire aussi simple en perl et aussi bien plus puissant. Autant le python a une syntaxe qui plait à certain et ruby a une vrai valeur ajoutée, autant php n'a eu q'une seule valeur ajoutée : easyphp qui installait php + mysql sur Windows simplement.
[^] # Re: mouais
Posté par Gniarf . Évalué à 1.
ah ben si tu ne le vois toujours pas, on ne peut vraiment rien pour toi
[^] # Re: mouais
Posté par Antoine . Évalué à 4.
Ce qui fait la force de PHP, c'est son intégration native en environnement Web. Mais cette même intégration avec un langage comme Ruby ou Python serait tout de même beaucoup plus agréable.
[^] # Re: mouais
Posté par Gniarf . Évalué à 3.
...soupçons confirmés en lisant plus un article sur l'histoire de Java : plusieurs équipes s'en sont occupées, chacune prenant un gros bout à sa charge, avec au final une API pas tout à fait homogène
[^] # Re: mouais
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: mouais
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Cela ne veut pas dire pour autant que le Zend Framework n'est pas intéressant. Mais pour moi il n'a de framework que le nom.
[^] # Re: mouais
Posté par jmny . Évalué à 2.
http://framework.zend.com/manual/fr/zend.controller.modular.(...)
celle ci est customisable, mais permet de l'implicite au niveau de la récupération des vues, et des controlleurs.
je dirais plutôt qu'il y a une manière recommandé d'utiliser le framework, et donc une organisation sous entendu. Dans ce cas on peut réellement l'appeler framework. Mais on peut aussi très facilement en utiliser une partie, ou modifier son comportement, et pour séduire des développeurs php, c'est une obligation.
On peut donc l'utiliser en framework ou en librairie, partiellement ou entièrement.
[^] # Re: mouais
Posté par or zax . Évalué à 3.
Le framework impose une architecture, car l'un des objectifs d'un framework est d'enlever au maximum le travail d'analyse au développeur. C'est pour cela par contre que tu as des frameworks spécialisés, framework web, appicatif, réseaux etc ...
Si tu peux faire ce que tu veux ce n'est plus un framework.
Zend propose pleins de fonctionnalités et de classes, pour aider sur pleins de choses, mais n'a pas de norme imposé, mais une logique globale.
Le principe de framework universelle est un peu un contre sens par rapport au but d'un framework, qui est spécialisé pour un sous ensemble d'application.
ZF est plus une sorte de méta-framework, et serait une excellente base pour créer un framework.
[^] # Re: mouais
Posté par jmny . Évalué à 3.
Mais le ZF impose une architecture,
- si tu utilise Zend_Controller_* , cela implique que tu utilise le pattern MVC
- si tu utilise Zend_Log, le framework t'impose l'utilisation de writers, de filters et formatters
- si tu utilise Zend_Session, le namespace est imposé
maintenant, tu peux utiliser la partie MVC et directement les sessions PHP. Grossomodo tu pends les contraintes/aides du framework que tu souhaite, pas toutes en bloc, et ca j'aime. J'ai pu ainsi utiliser le MVC mais aussi continuer à utiliser $_SESSION sans que le MVC en patisse.
donc je pense que tu ne peux pas faire ce que tu veux, cependant tu peux utiliser q'une partie du framework.
je pense surtout qu'il manque des couches "haute niveau" qui utilise les briques de base du framework, mais il faut un debut à tout :)
[^] # Re: mouais
Posté par Éric (site web personnel) . Évalué à 3.
En même temps les sessions c'est un des seuls trucs qui justement ne méritait pas qu'on y fasse une abstraction via une classe utilisateur. Le set_save_handler contient déjà tout ou presque. Là ça complexifie pour pas grand chose.
[^] # Re: mouais
Posté par jmny . Évalué à 2.
peut - être que certaines personnes ont trouvé un avantage a cette gestion des sessions, particulièrement sur un projet multi dev.
[^] # Re: mouais
Posté par or zax . Évalué à 1.
MVC est une extension parmis d'autres, donc adieu la normalisation imposé d'un framework.
Ce que je critique n'est pas la qualité de la technologie qui est superbe mais le fait que l'on appel "framework" quelque chose qui n'est pas un framework.
Le problème est que dire que l'on utilises un framework cela fait bien, donc on appel tout et n'importe quoi un "framework". Surtout que dans beaucoup de cas un framework n'est pas justifié, et c'est à ce marché là que répond ZF.
[^] # Re: mouais
Posté par ethtezahl . Évalué à 4.
Par exemple, une authentification avec mise en session plus gestion des droits, je le fais en quelques lignes, alors que le ZF en demande bien plus.
Mais je pense que ce framework est fait pour être étendu, je suis d'ailleurs actuellement en train de réaliser ce projet.
Sinon, je préférais la forme de Zend_Filter du début, et je trouve que Zend_Db a bien gagné en rapidité ;-)
[^] # Re: mouais
Posté par rhizome . Évalué à -1.
Sinon, moi je dis chapeau au développeurs PHP qui arrivent à faire de chouettes applis (mediawiki, etc.) avec un tel langage.
[^] # Re: mouais
Posté par Damien ARISTODEMO (site web personnel) . Évalué à 1.
tsss...
[^] # Re: mouais
Posté par jmny . Évalué à 2.
(a propos de wiki dokuwiki est une perle, lui aussi en php)
# Framework PHP
Posté par dovik (site web personnel) . Évalué à 8.
Autre framework que l'on peut citer (puisque son auteur est trop humble pour le citer lui même) :
Jelix : http://jelix.org/
[^] # Re: Framework PHP
Posté par Axel . Évalué à -3.
Ou alors il en a trop honte !
[^] # Re: Framework PHP
Posté par Obi MO (site web personnel) . Évalué à 7.
Pour l'avoir évalué et utilisé à divers stades de maturité, je pencherai plutôt pour l'humilité. Y'a pas à dire, c'est du beau code, pratique et efficace, malgré les légitimes bugs et trous de jeunesse (vivement la 1.0). Ce qui ne m'a pas empêché de faire des vrais projets avec (rien de public cependant). Le développement est actif et les patches que j'ai envoyés ont été rapidement intégrés. Pour moi, c'est le meilleur !
[^] # Re: Framework PHP
Posté par Axel . Évalué à 0.
[^] # Re: Framework PHP
Posté par Laurent J (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: Framework PHP
Posté par Gniarf . Évalué à 3.
# >> Python et Plone ?!?!
Posté par Loïc Ibanez . Évalué à 3.
Même si ce satané Zope est absolument inclassable et tient tout autant de l'IDE, du Framework que de la Forge en ligne. Zope, ovni ou précurseur ? Le débat est ouvert.
[^] # Re: >> Python et Plone ?!?!
Posté par Émilien Tlapale . Évalué à 4.
[^] # Re: >> Python et Plone ?!?!
Posté par or zax . Évalué à 2.
[^] # Re: >> Python et Plone ?!?!
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 2.
Plone est un site web prêt à l'emploi qu'il est possible de personnaliser en ligne et un framework de développement pour ceux qui souhaitent avoir d'autres fonctionnalités que celles proposées par défaut.
[^] # Re: >> Python et Plone ?!?!
Posté par lezardbreton . Évalué à 1.
[^] # Re: >> Python et Plone ?!?!
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 3.
[^] # Re: >> Python et Plone ?!?!
Posté par Sébastien Douche . Évalué à 3.
Oui clairement, avec Web Objects de Next (sorti aussi en 96), qui permet de développer une application Web un peu comme une application classique, au détriment d'une prise en main plus complexe que PHP 2 et 3 ou ASP (on doit penser objet, MVC, utilisation d'un ORM par défaut, la notion d'héritage à l'éxécution....).
Et puis, dans le monde Python, on faisait pas de pub. Il faut remonter à 2005/2006 pour voir un véritable début de communication (refonte du site web, création d'une ml marketing...) avec comme exemple RoR. Et c'est bien dommage, Python s'est fait bouffé par PHP alors qu'il avait bien plus d'atouts. Et Zope Corp. est le plus mauvais élève en la matière, avec un produit révolutionnaire, des core devs impliqués dans la vie de l'interpréteur, Zope est resté opaque (peu de doc, pas de livre...) et méconnu par beaucoup de monde, même dans le monde Python.
Et ca continue avec Zope 3, qui est une refonte from scratch. Y'a pas mal d'idées fort intéressantes, qui ne se trouvent pas dans les RoR, Tg, Django, qui sont "des versions modernes" de Zope 2 (dans l'esprit).
Bref, OVNI ou précurseur, les 2 mon capitaine. Et ca risque de pas trop changer, sauf si Plone arrive à démontrer la puissance du produit (ce qui est plutot bien parti avec Plone 3) sur les 2 prochaines années.
[^] # Re: >> Python et Plone ?!?!
Posté par _p4_ . Évalué à 3.
Je dirais plutôt que php s'est imposé dans le monde du développement web pour ses atouts propres. Au début quand il est arrivé le développement web se résumait à des scripts perl en cgi, or le modèle lamp a fait beaucoup pour la démocratisation des outils de développement web. A cette époque python n'était pas du tout sur les rangs comme un language utilisable facilement pour faire du web. Aujourd'hui python est une alternative très crédible, ce qui n'a pas toujours été le cas.
Quant à Zope ca n'est pas non plus pour rien qu'il est "resté opaque": courbe d'apprentissage longue, très mal documenté, et aussi gros consommateur de ressources.
A mon sens Zope n'est en rien comparable à des Rails ou Django: on a là un serveur d'applications et non un framework mvc, la base objet amenant un fonctionnement radicalement différent. Les bonnes idées se trouvant dans Zope sont contrebalancées par la lourdeur de l'ensemble: beaucoup de couches imbriquées, beaucoup de mécanismes à connaitre. Et apparement ca ne s'arrange pas dans Zope 3: la philosophie est vraiment différente d'un "convention over configuration", dans le sens ou Zope 3 est conçu comme un ensembles de composants qu'il faut lier ensemble en se paluchant pleins de fichiers de conf xml. Ceci dit plein de bonnes idées dans Zope 3 d'après ce que j'ai entendu.
Pour conclure sur une touche positive, je suis bien d'accord pour dire qu'aujourd'hui python rox pour le développement web.
[^] # Re: >> Python et Plone ?!?!
Posté par Éric (site web personnel) . Évalué à 3.
Je confirme, et l'atout de PHP est encore inégalé : pouvoir faire tourner facilement des serveurs mutualisés de manière simple. PHP avec feu son safe mode et son open base dir est vraiment un avantage.
(Oui, je sais que ces fonctions ne sont pas la panacées et que c'est souvent troué, mais il n'empêche que si PHP s'est démocratisé c'est grace à plein de serveurs gratuits qui se reposaient là dessus).
Allez faire du gros mutualisé en Ruby ou en Python .. c'est faisable mais c'est une toute autre affaire.
[^] # Re: >> Python et Plone ?!?!
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sinon, refait un tour du coté de perl car perl, c'est un peu plus que des petits scripts CGI. Cela fait 10 ans que perl fait de l'objet avec des namespace... Je te conseille de faire un tour sur le CPAN pour voir ce que signifie un développement communautaire.
Sinon, pour l'autre débat du thread : zope. Personnellement, je n'aime pas du tout et autour de moi, les gens ont aussi horreur de ce truc. C'est peut être très puissant mais je fais un blocage total sur la ZMI et l'édition en mode web.
[^] # Re: >> Python et Plone ?!?!
Posté par _p4_ . Évalué à 3.
Personne n'a gagné ni perdu, les technologies comme les besoins évoluent c'est tout. Le web s'invente au fur et à mesure. Php va faire son temps, comme les autres.
[^] # Re: >> Python et Plone ?!?!
Posté par Éric (site web personnel) . Évalué à 6.
> php + mysql sous Windows. php a gagné via Windows et non via
> UNIX. C'est là que python et perl ont perdus.
PHP a commencé à être populaire avant le haut débit et avant easyphp. Easyphp a beaucoup apporté mais je persiste, ce qui a permis tout ça c'est bien les possibilités d'hébergement mutualisé en masse. Sans ça ça aurait fait une belle jambe à l'époque d'avoir un easyphp local.
> Sinon, refait un tour du coté de perl car perl, c'est un peu plus que des petits scripts CGI.
J'ai dit le contraire ?
Mais perl c'est aussi une syntaxe très discutable pour la plupart des gens et un hébergement pas si simple. Bref, on retire les deux raisons qui font que php est populaire.
Ca n'empêche pas qu'on peut faire des gros trucs bien avec (et on les fait), comme dans n'importe quel langage, mais on n'est pas du tout sur le même créneau que PHP.
[^] # Re: >> Python et Plone ?!?!
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: >> Python et Plone ?!?!
Posté par Éric (site web personnel) . Évalué à 2.
Déjà le langage actuel n'a plus grand chose à voir avec ce qu'il était au départ. Donc juger de la syntaxe de php 3/4/5 sur ce que ça a pu être au niveau du début non public de PHP, ça ne me parait pas pertinent.
Après non, justement, PHP a été écrit en Perl au départ. S'il y a eu un interpréteur de créé sur Perl c'est forcément *justement* pour ne pas taper du Perl.
[^] # Re: >> Python et Plone ?!?!
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Pour ce qui est de l'origine de php, pour l'avoir connu et pour avoir réalisé des sites en perl avant que le php n'existe, je lisais du code php sans aucun apprentissage alors que lire du python (ou du ruby) sans aucun apprentissage que le perl n'est pas aussi évident que cela.
Je connais plein de gens qui ont développé des sites en php sous Windows et qui ne voulait pas entendre parler du Perl, plus par effet de mode que par réelle conviction puisqu'il n'avait jamais fait une ligne de perl. Lorsque tu leurs montrait qu'il y avait une abstraction DBI pour attaquer n'importe quelle base de données plutôt que les fonctions merdiques du php de l'époque, cela ne changeait rien à leur fonctionnement. Idem si tu allait faire un tour sur le CPAN... D'ailleurs, la plupart n'était pas programmeur pour un sous et n'avaient pas la moindre notion de sécurité. Par exemple, toutes les requêtes sur la base de données étaient faites en 'admin' avec tous les droits, même pour de simple SELECT.
Bref, je reste persuadé qu'il a manqué à Perl un easyphp à une époque et c'est vraiment dommage car on a un langage de script en plus qui n'apporte pas grand chose aujourd'hui, mais bon, c'est un avis personnel. C'est comme pour les moteurs de tous ces langages, les spécialistes feraient mieux de tous bosser sur Parrot que de multiplier les différents moteurs plus ou moins performant.
Mais bon, There Is More Than One Way To Do It !
[^] # Re: >> Python et Plone ?!?!
Posté par choon . Évalué à 2.
à priori ça va sauter avec php6
[^] # Re: >> Python et Plone ?!?!
Posté par Antoine . Évalué à 3.
Remplacé par quoi ?
[^] # Re: >> Python et Plone ?!?!
Posté par Taku . Évalué à 0.
Par une nécessité de rigueur.
[^] # Re: >> Python et Plone ?!?!
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Bon debarras le safe_mode !
open_basedir reste par contre, et c'est déjà bien pour sécuriser un compte web.
[^] # Re: >> Python et Plone ?!?!
Posté par Antoine . Évalué à 3.
Disons qu'il faut régler préalablement les droits d'accès à certains répertoires.
Sinon le safe_mode_gid était un bon compromis (en conjonction avec le sticky bit - chmod g+s sur les répertoires).
open_basedir reste par contre
Ok. Mais il faut penser à désactiver toutes les fonctions dangereuses (ce que le safe mode faisait automatiquement si je ne m'abuse).
[^] # Re: >> Python et Plone ?!?!
Posté par Éric (site web personnel) . Évalué à 3.
Seulement le safe mode, pas l'open basedir
[^] # Re: >> Python et Plone ?!?!
Posté par Bozo_le_clown . Évalué à 5.
http://softwareengineering.vazexqi.com/files/pattern.html
# ORM ?
Posté par choon . Évalué à 1.
[^] # Re: ORM ?
Posté par jmny . Évalué à 2.
[^] # Re: ORM ?
Posté par choon . Évalué à 1.
[^] # Re: ORM ?
Posté par jmny . Évalué à 2.
ezPDO prend la main sur la BD (il créait même les tables), donc c'est délicat :
- d'utiliser autre chose que ezPDO pour acceder à ta base.
- d'utiliser ezPDO sur une base de donnée existante
ezPDO utilise une unique table pour faire persister les relations entre objets, donc tu peux difficilement dépasser les 20 millions de relations sous mysql 3.2x (d'après moi).
je voulais gérer un id unique par objet ou pour toute la base je ne sais plus, et cela posait pb , je n'avais pas de moyen simple de le faire. A vérifier.
les points positifs :
- à l'époque, la communauté était assez réactive
- c'est cool si tu ne veux voir que des objets (la base se génère automatiquement)
perso j'avais besoin d'attaquer la BD directement pour des stats avancées, et je voulais permettre le développement de module sans ezPDO (ct dans le cadre d'un CMS), et c'etait délicat. J'ai donc mis de coté cette solution.
[^] # Re: ORM ?
Posté par choon . Évalué à 1.
ça à priori tu peux (cf http://ezpdo.net/blog/?p=5)
# Prado
Posté par ohmer . Évalué à 1.
D'ailleurs, la version 3.1 vient de sortir en stable hier.
Perso, je ne développe plus d'applications Web PHP sans ce framework depuis que je l'ai essayé.
[^] # Re: Prado
Posté par BAud (site web personnel) . Évalué à 2.
# *khof* *khof*
Posté par Misc (site web personnel) . Évalué à 4.
Comment dire, "qui fonctionnent partout", les gens oublient le merdier des incompatibilités entre version de php, ainsi que les nombreux hacks requis pour adapter les softs à la configuration du serveur ?
Quand aux "solutions simples et élégantes", c'est vrai que le fait de rajouter i à chaque fontion de matching est "élégant" et pas du tout piégeux. Et que la cohérence des fonctions ( avec ou sans _ ), la duplication des fonctions, etc, tout ça le rends "simple" et "élégant", comme le rappelle ce lien http://tnx.nl/php.
Php a des avantages, la facilité ( car visiblement, tout le monde arrive à en faire ), le fait qu'il soit pensé pour offrir un systéme de template web à des users sans avoir à leur donner les droits admins, la capacité de limiter les users au niveau des opérations, etc, mais faut pas non plus essayer de nous faire prendre des vesies pour des lanternes.
[^] # Re: *khof* *khof*
Posté par Damien ARISTODEMO (site web personnel) . Évalué à 1.
Quels "hacks" requis pour adapter les softs a la configuration du serveur ?
A part le fameux register_globals quasiment mort maintenant et déprécié depuis longtemps.. Après, si les serveurs ont une configuration de php vraiment différente d'un à l'autre, faute aux serveurs. Mais personelement, je n'ai jamais eu besoin a recourrir à de telles pratiques bizaroides pour faire fonctioner mes programmes de serveur à serveur.
Encore une foi,c'est personel, mais je trouve que rajouter "_" uniquement pour les fonctions dites "magiques" c'est réellement coérent. Tu parlai peut-être d'autre chose ?
Puis concernant la "duplication des fonctions". moi j'emploi plutôt le terme de "proffusion" de fonctions, certaines en effets relativements similaires, et parfois aussi des alias, mais qui pour moi sont un atout, et permettent une plus grande clarté pour peu que l'on conaisse un peu / suffisament le language et les-dites fonctions, même si il est vrai, un débutant ne conaissant pas spécifiquement php peu s'embrouiller dans les noms.
[^] # Re: *khof* *khof*
Posté par jmny . Évalué à 2.
moi non plus, pour le principe ;-p
non, plus sérieusement, je ne connais pas bien python et pas dutout ruby, mais en java, le probleme des incompatibilités entre version de java ou entres serveurs , ou entre systeme ... existe aussi. et en php (je suppose que c'est pareil en JAVA) il suffit de peu de chose pour éviter ces galères (register_globals en est en effet une grosse partie ...).
[^] # Re: *khof* *khof*
Posté par e-t172 (site web personnel) . Évalué à 7.
Les magic quotes, cette "géniale" fonctionnalité qui :
- Si activée, brise le principe des "données pures" : tu te retrouve avec des chaînes echapées en entrée, ce qui fait que certaines fonctions vont retourner des données bizaroïdes (par exemple, strlen() ne te renverra pas vraiment le nombre de caractères contenus dans la variable).
- Si activée et que tu veux restaurer des données pures, tu dois avant toute chose prendre toutes les chaînes passer en entrée et les déséchapper à la main avec stripslashes() > HACK qui pue (et complètement débile quand on y pense : on est obligé de refaire en sens inverse ce que PHP a fait automatiquement, quelle logique implacable !)
- Si un code n'a été prévu pour s'adapter à la configuration des magic quotes du serveur, alors il n'y a aucune chance pour qu'il survive à une migration sur un autre serveur de configuration différente (apparation de bugs tels que des chaînes échapées envoyées au client ou pire de failles de type SQL Injection)
Il y en a d'autres des options de config qui modifient le comportement de PHP et peuvent faire qu'un script qui fonctionne très bien sur un serveur crashera lamentablement sur un autre, il suffit de consulter la liste des options dans le manuel de PHP pour s'en apercevoir.
[^] # Re: *khof* *khof*
Posté par choon . Évalué à 2.
et il n'y a plus de problème.
[^] # Re: *khof* *khof*
Posté par e-t172 (site web personnel) . Évalué à 5.
Tu as lu mon message ? Je dénonçais justement la logique implacable des magic quotes qui fait que si elles sont actives, tu dois refaire à l'envers ce que PHP a fait automatiquement, quelle avancée !
[^] # Re: *khof* *khof*
Posté par choon . Évalué à 2.
[^] # Re: *khof* *khof*
Posté par Éric (site web personnel) . Évalué à 4.
Mais oui le "il n'y a qu'à rajouter 30 lignes de script et analyser côté utilisateur toutes les données en entrées pour faire l'inverse de PHP, le tout à insérer au démarrage de chaque script PHP avant le code applicatif", c'est je pense justement ce que le monsieur plus haut appelle un "hack".
Surtout que le hack en question il est très pénible, chacun fait le sien et en associant des composants entre eux j'ai vu plus d'une fois des projets qui lançaient deux fois l'opération.
Dire qu'il n'y a plus de problème quand tu as à ajouter ce genre de chose, c'est aller un peu vite.
[^] # Re: *khof* *khof*
Posté par choon . Évalué à 1.
$_REQUEST je m'en fous, je l'utilise jamais, je ne l'utiliserai sans doute jamais, je ne travaille avec personne qui l'utilise ou qui l'utilisera et je ne l'ai jamais rencontré dans aucune des librairies que j'ai pu utiliser.
Si tu vas par là tu peux aussi rajouter $_COOKIE.
ok --> *Je* n'ai plus de problême. Et non c'est pas pénible, c'est fait une fois pour toutes. Et non je n'ai pas besoin d'inclure ça dans chaque script php... juste dans UN script, l'index.
Ce que je veux dire c'est que oui les magic_quotes c'est chiant, mais non ça suffit pas pour jeter le bébé avec l'eau du bain, d'autant que le tir sera corrigé.
[^] # Re: *khof* *khof*
Posté par Antoine . Évalué à 1.
[^] # Re: *khof* *khof*
Posté par lezardbreton . Évalué à 3.
[^] # Re: *khof* *khof*
Posté par choon . Évalué à 1.
Par contre le fait de mettre ça dans une classe permet d'appeler cette méthode sans avoir à inclure à la mimine préalablement le fichier la contenant puisque l'autoload s'en occupe.
Je ne crois pas qu'on puisse faire de même avec une "simple" fonction mais si c'est le cas ça m'intéresse aussi.
[^] # Re: *khof* *khof*
Posté par benoar . Évalué à 3.
[^] # Re: *khof* *khof*
Posté par Bozo_le_clown . Évalué à 9.
[^] # Re: *khof* *khof*
Posté par Éric (site web personnel) . Évalué à 5.
Rien que le magic_quotes_gpc par exemple (encore un truc qui n'aurait jamais du exister)
> Tu parlai peut-être d'autre chose ?
Il parlait probablement de (par exemple) isset() plutot que is_set() alors qu'on a is_string() et non isstring().
La cohérence des fonctions est effectivement un *gros* problème de PHP. Parfois avec les mêmes paramètres ou des paramètres similaires, des fonctions proches les mettent dans un ordre différent. Parfois c'est retourné en valeur de retour et parfois via un paramètre par référence. Résultat on code toujours avec une doc sur le côté pour les prototype, ou un IDE qui fait la complétion.
[^] # Re: *khof* *khof*
Posté par Damien ARISTODEMO (site web personnel) . Évalué à 0.
Pour ce qui est des incohérences de noms de fonctions, il est indéniable qu'il en existe, et peut-être plus qu'ailleurs, je ne serai pas de mauvaise foi sur ce point la :)
Ceci-dit, une foi en tête les 2 ou 3 noms de fonctions problematiques, plus de probleme. en tout cas *je* ne code plus avec la documentation tout le temps sous le nez et les problemes isset/is_set -like n'en sont pas pour moi.
Enfin bon, bref. je ne pense pas qu'il s'agisse de vrais probleme. Vrais problemes pour qui ne connait pas trop ce language oui mais c'est tout.
Les vrais problemes sont plutot les limitations côté objet AMHA.
[^] # Re: *khof* *khof*
Posté par choon . Évalué à 1.
[^] # Re: *khof* *khof*
Posté par Jérôme FIX (site web personnel) . Évalué à -1.
* is_string() est une fonction, on peut faire : is_string(<une fonction qui va bien>)
* isset n'est pas une fonction, mais une structure du langage et on ne peut l'appeler qu'avec des variables (pas de résultats de fonction), isset(<une fonction qui va bien>) renverra une erreur
Finalement la différence de syntaxe a peut etre une raison ?
http://fr.php.net/isset
http://fr.php.net/is_string
[^] # Re: *khof* *khof*
Posté par choon . Évalué à 1.
C'est quand même bien fait linuxfr...
[^] # Re: *khof* *khof*
Posté par Moonz . Évalué à 2.
# Symfony
Posté par Grégoire Hubert . Évalué à 4.
symFony :o)
Zend, à ce que j'en ai vu, ressemble plus à une boite à outil pour développeur. Symfony est un véritable framework. Il est libre et architecturé autour de méthodes de développement professionelles éprouvées. Mélange de RoR, Django (entre autres) avec la facilité d'hébergement et la rapidité du PHP, il est par exemple utilisé par Yahoo sur certains de ses sites grand publique.
Pour finir, le livre (sous licence libre), écrit par les auteurs du framework, est disponible sur leur site.
# codeigniter
Posté par Jean-Philippe (site web personnel) . Évalué à 3.
http://codeigniter.com/
Compatible php 4 et 5, il est très leger et peut utiliser les bibliothèques du pseudoframework Zend :)
[^] # Copix
Posté par Brice Favre (site web personnel) . Évalué à 1.
Des plugins permettent l'utilisation des classes ZF et les classes ezComponents.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.