Développeur : Zend Framework 1.0.0 : PHP à la suite de Ruby on Rail
Posté par Étienne Bersac (Jabber id, page perso, ). Modéré le 02 juillet 2007.
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.
![[en]](../images/en.png)
Zend framework (1181 hits)![[fr]](../images/fr.png)
Communauté francophone de développeurs Zend (913 hits)-
Téléchargements (212 hits)
-
Feuille de route (193 hits)
-
PHP (141 hits)
-
QEDwiki, un exemple d'utilisation de ZF (Flash) (420 hits)
> Lire la dépêche (119 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #847520.
Run by 
Cette page a été générée par Templeet en 0.0941s (dont 0.0118 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
>> Python et Plone ?!?!
Heu... si on veut comparer à Ruby et RoR ce serait plutôt Python+Zope, nan ?
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.
Montre moi ton code, je te dirais qui tu es.
[^]Re: >> Python et Plone ?!?!
Je sais pas du tout ce que c'est que ce nouveau bouzin en PHP, mais juste histoire de citer Django, Turbogears, Nevow et compagnie :)
[^]Re: >> Python et Plone ?!?!
Je ne connais pas bien Zope, on me l'a souvent décris plus comme un serveur d'application qu'un framework. Pour ceux qui connaissent contrairement à moi, c'est une affirmation juste ?
[^]Re: >> Python et Plone ?!?!
Zope est un serveur d'application et un framework de développement. Par contre ce n'est pas un IDE (à moins que vi et ed soient des IDE).
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 ?!?!
C'est aussi un IDE, vu qu'il fournit des outils basiques d'édition des scripts depuis l'interface d'admin. D'ailleurs, tout le tutorial est basé là-dessus et je ne me rappelle plus de la possibilité de passer outre cet IDE.
[^]Re: >> Python et Plone ?!?!
C'est bien ce que je disais: un IDE va beaucoup plus loin qu'un simple éditeur, sinon vi et ed (et dd) sont des IDE. Zope n'est pas un IDE, il est juste orienté TTW (Throught The Web) pour l'administration quotidienne.
[^]Re: >> Python et Plone ?!?!
Précurseur ? Si je te dis que la 1ere version est sortie en 96 (libéré fin 98), tu en penses quoi ? :).
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 ?!?!
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 ?!?!
> Je dirais plutôt que php s'est imposé dans le monde du développement web pour ses atouts propres.
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 ?!?!
php a gagné des parts de marché avec easyphp qui installait en 3mn php + mysql sous Windows. php a gagné via Windows et non via UNIX. C'est là que python et perl ont perdus.
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 ?!?!
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 ?!?!
> php a gagné des parts de marché avec easyphp qui installait en 3mn
> 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 ?!?!
La syntaxe du php est la même que celle du Perl, tout du moins à l'origine. Donc la syntaxe n'est pas un argument recevable pour ma part. Par contre, pour l'herbergement, je suis d'accord, avec php, l'herbergement Perl n'a pas suivis.
[^]Re: >> Python et Plone ?!?!
> La syntaxe du php est la même que celle du Perl, tout du moins à l'origine.
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 ?!?!
Nous sommes d'accord je pense pour dire que php s'éloigne petit à petit du perl et cela est normal. Le php5 notament qui introduit une couche objet.
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 ?!?!
à priori ça va sauter avec php6
[^]Re: >> Python et Plone ?!?!
a priori ça va sauter avec php6
Remplacé par quoi ?
[^]Re: >> Python et Plone ?!?!
Remplacé par quoi ?
Par une nécessité de rigueur.
Moi j'aime les fourmis !
[^]Re: >> Python et Plone ?!?!
par rien. Le safe_mode est grosse daube, le cauchemar des développeurs dés lors que l'on veuille manipuler des fichiers dynamiquement. (y a qu'à lire les notes de releases des projets phares en PHP, qui souvent déconseillent l'utilisation du safe mode parce que ça provoque des problèmes de lectures/ecritures de fichiers, à cause de droits &co).
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 ?!?!
y a qu'à lire les notes de releases des projets phares en PHP, qui souvent déconseillent l'utilisation du safe mode parce que ça provoque des problèmes de lectures/ecritures de fichiers, à cause de droits &co
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 ?!?!
> à priori ça va sauter avec php6
Seulement le safe mode, pas l'open basedir
[^]Re: >> Python et Plone ?!?!
Il faut le comparer à Django ou Turbogears qui sont des frameworks qui supportent le pattern Convention over Configuration
http://softwareengineering.vazexqi.com/files/pattern.html