Articles précédents : Développeur
- [15] CamelBones 1.0.0b5
- [56] Gorm 1.0 est disponible
- [94] Sortie du noyau 2.6.14
- [116] Rendre GNOME rapide
- [82] Flash player 8 recherche son ingénieur linux
- [16] Le projet BBClone cherche un repreneur
- [3] Préparation de l'atelier Netfilter 2005
- [6] Nouvelles du noyau : Git et modèle de développement
- [47] FFmpeg et MPlayer : Appel au dons pour un nouveau serveur
- [56] Bilan du sommet 2005 des développeurs du noyau Linux
Liens connexes
- PHP.net (644 hits)
- ChangeLog (397 hits)
- Téléchargement (382 hits)
- Documentation en français (463 hits)
- Association Française des Utilisateurs de PHP (990 hits)
- Nouvelles fonctionnalités du futur PHP6 (830 hits)
Dépêche modérée par
Dépêche éditée par
Outre les habituelles corrections de bugs (environ 400 !), les nouveautés du moteur Zend2 devrait permettre d'obtenir encore de meilleures performances grâce entre autre à une gestion plus fine de la mémoire. Le ChangeLog nous apprend aussi que beaucoup de modules ont été mis à jour dont MySQLi, PostgreSQL, le module de manipulation des tableaux, SOAP ou encore SPL (Standard PHP Library).
Autre grosse nouveauté de PHP 5.1 est (enfin!) l'introduction d'une nouvelle interface objet appelée PDO (PHP Data Object) permettant d'accéder de manière unifiée aux systèmes de bases de données les plus utilisés avec PHP (MySQL, PostgreSQL, SQLServer, Firebird, Sybase, SQLite, DB2, ODBC) sans avoir à passer par des classes d'abstraction écrites en PHP tel que PearDB ou AdoDB.
Mise à jour : Une version 5.1.1 est déjà disponible. Pas de grandes nouveautés à part quelques correctifs d'anomalies et de régressions, ainsi que la suppression de la classe native Date pour ne pas rentrer en conflit avec le paquet PEAR du même nom. Il est fortement recommandé de migrer rapidement en 5.1.1. Merci à J.Smith pour l'information
PHP.net (644 hits)
ChangeLog (397 hits)
Téléchargement (382 hits)
Documentation en français (463 hits)
Association Française des Utilisateurs de PHP (990 hits)
Nouvelles fonctionnalités du futur PHP6 (830 hits)
> Lire la dépêche (46 commentaires, moyenne: 2,7).
On estime qu'un tiers des sites Internet utilise PHP dans le monde et que 46% des sites français l'utiliserait (Source : Livre blanc de l'AFUP).
Bonne et mauvaise nouvelle
L'intégration de PDO est une bonne et une mauvaise nouvelle à la fois.
Une bonne nouvelle car on a enfin une interface unifiée d'accès au SGBD intégrée dans PHP.
Une mauvaise car PDO est loin d'être complet et quasiment inutilisable dans des projets conséquents, c'est dommage que ce soit PDO qui ait été retenu alors qu'il y avait pléthore de projets bien lus avancés.
-
[^]Re: Bonne et mauvaise nouvelle
Posté par Dinofly (page perso, ) le 25/11/2005 à 13:13. (lien). Évalué à 4.Tu peux détailler un peu ce qu'apportaient les autres projets plus avancés ?
J'ai beaucoup aimé la présentation de PDO au forum PHP 2005 alors s'il y a mieux ça m'intéresse :-)--
Je connais bien l'algèbre de Boole, et j'ai même vu tous ses flims.-
[^]Re: Bonne et mauvaise nouvelle
Posté par DPhil (page perso, ) le 25/11/2005 à 13:37. (lien). Évalué à 6.On a tout d'abord ADODB-ext., dbx, DBDO ( qui fait du mapping OR en plus )
Avec PDO, on a très peu d'accès au meta données, ce qui oblige à les récupérer d'une autre façon ( façon qui est souvent dépendante du SGBD, on perd donc l'abstraction )
Les objets retournés avec PDO sont des objet standards ( comme avec mysql_fetch_object ), ça ne fait pas vraiment avancer le schmilblik en terme de programmation objet.
Un binding avec libgda ( gnome-db ) aurait été à mon avis plus opportun.
Maintenant, ça reste quand même une bonne chose qu'on ait une interface intégrée et objet de surcroit pour l'accès aux SGBD.-
[^]Re: Bonne et mauvaise nouvelle
-
[^]Re: Bonne et mauvaise nouvelle
Posté par Éric (Jabber id, page perso, ) le 27/11/2005 à 16:18. (lien). Évalué à 4.> On a tout d'abord ADODB-ext., dbx, DBDO ( qui fait du mapping OR en plus )
Les buts d'ADODB ou DBDO ne sont pas les mêmes.
- ADODB est une abstraction de base de données
- DBDO est un mapping objet-relationel
- PDO est une API unifiée
On ne demande pas à PDO de pouvoir avoir une instruction unique pour mysql et oracle (le but d'adodb), on lui demande juste que l'instruction soit à passer de la même façon.
Ne pas être aller plus loin pour fournir un minimum d'abstraction est à mon avis une erreur mais c'est un choix qui se défend tout à fait.
> Un binding avec libgda ( gnome-db ) aurait été à mon avis plus opportun.
Là dessus on est d'accord. Il me semble que quelqu'un a commencé à travailler la dessus. Par contre j'ai cru comprendre que ça ne deviendrai jamais une solution poussée par PHP à cause du nombre de dépendances et de leur portage sur tous les systèmes où tourne PHP.
-
-
Interprété ou compilé ?
Les nouveautés du moteur Zend2 devrait permettre d'obtenir encore de meilleures performances grâce entre autre à une gestion plus fine de la mémoire.
Question simple : Le moteur Zend2 compile t-il le code PHP pour de meilleurs performances et sinon pourquoi ne le fait-il pas ?
-
[^]Re: Interprété ou compilé ?
Posté par DPhil (page perso, ) le 25/11/2005 à 13:41. (lien). Évalué à 5.Comme dans presque tous les langages de script actuel, PHP est compilé pour tourné dans une sorte de machine virtuelle.
Par contre, le script doit être recompilé à chaque exécution à moins d'utiliser un cache d'op-code ( le code produit par la compilation ).-
[^]Re: Interprété ou compilé ?
Posté par Laurent J (page perso, ) le 25/11/2005 à 14:19. (lien). Évalué à 10.et pour répondre à la question qui ne saurait tarder, "mais pourquoi ils n'incluent pas un cache d'opcode ?"
- parce que la société Zend, qui est à l'origine du moteur, vend ce système de cache d'op-code (non libre), c'est pourquoi elle ne l'a pas inclus directement dans zend (ba oui, faut bien qu'ils bouffent les developpeurs de zend ;-) ). Du coup, il y a eu d'autres projets de système de cache qui ont été crée, libres.
- il y en aura un fourni nativement dans PHP6 normalement.-
[^]Re: Interprété ou compilé ?
Posté par Alexandre DATH (page perso, ) le 25/11/2005 à 16:34. (lien). Évalué à 6.Le Zned Optimizer n'est certe toujours pas libre, mais par contre, maintenant il est gratuit :
http://zend.com/store/products/zend-optimizer.php-
[^]Re: Interprété ou compilé ?
Posté par swix () le 25/11/2005 à 16:58. (lien). Évalué à 5.Oui, mais ca n'est pas nouveau, c'est forcement gratuit, car il permet de décoder les scripts encodés avec les autres softs Zend.
Le produit le plus utile (et couteux) est la Zend Platform (avant: Zend Accelerator). Et en moins couteux, il y a eAccelerator qui fonctionne très bien ( http://www.eaccelerator.net/ )-
[^]Re: Interprété ou compilé ?
Posté par skuld () le 25/11/2005 à 17:39. (lien). Évalué à 1.Et en moins couteux, il y a eAccelerator qui fonctionne très bien ( http://www.eaccelerator.net/ )
Merci pour l'URL. Le pire, c'est que ça marche ce truc.--
Cette signature n'existe que dans votre esprit dérangé
http://goddess-gate.com/dc2/index.php/fr (français)
http://goddess-gate.com/dc2/index.php/en (english)-
[^]Re: Interprété ou compilé ?
Posté par swix () le 26/11/2005 à 12:26. (lien). Évalué à 2.Oui, je l'utilise en production sur pas mal de serveurs (php 4.x). Par contre le dev se limite actuellement à des bugfixes, vu que le créateur de projet (sous le nom de mmcache) s'est fait "récupèrer" par Zend et ne bosse plus que pour eux :-/.
-
-
-
[^]Re: Interprété ou compilé ?
-
-
[+] [^]Re: Interprété ou compilé ?
Posté par Encolpe DEGOUTE (page perso, ) le 25/11/2005 à 16:35. (lien). Évalué à -4.C'est bien, bientôt PHP aura les foncitonnalités de Zope.
-
[+] [^]Re: Interprété ou compilé ?
Posté par Loïc Ibanez () le 26/11/2005 à 10:51. (lien). Évalué à -3.Alors il faut qu'il se dépêche, car la sortie de Zope 3.0 va sûrement faire du bruit...
Exaspéré par les performances de J2EE et les carences de PHP dès qu'il faut développer des applications complexes (ou alors il faut piocher dans une multitude de librairies plus ou moins abouties), je fais partie de ceux qui pensent que Zope a les atouts pour mettre tout le monde d'accord.
Il suffit de quelques minutes d'utilisation pour constater qu'une application sous Zope va vite, vraiment vite...--
Montre moi ton code, je te dirais qui tu es.-
[+] [^]Re: Interprété ou compilé ?
Posté par Stéphane TRAUMAT (page perso, ) le 26/11/2005 à 11:10. (lien). Évalué à -1.mmm je suis toujours impréssionné par ce genre de commentaires, nous développons des applications J2EE depuis un certain temps déja et on a jamais eu de problèmes de performances, on développe vite, bien et les perfs sont largement au RDV.
Et quand à Zope, je n'ai pas vraimetn vu l'équivalent des choses que j'aime dans Java/J2EE (JSF, Hibernate, Spring, Eclipse, JMS, JDBC...)-
[^]Re: Interprété ou compilé ?
Posté par Nicolas (page perso, ) le 26/11/2005 à 13:47. (lien). Évalué à 0.Que l'on utilise zope ou java il faut juste prévoir une machine avec beaucoup plus de ressources (mémoire notament)
p.s: Et mince j'ai marché dedans. Je suis déjà dehors.-
[+] [^]Re: Interprété ou compilé ?
Posté par Stéphane TRAUMAT (page perso, ) le 26/11/2005 à 14:39. (lien). Évalué à -2.Pas plus que php :)
J'oublais JTA qui est une des choses que j'adore chez J2EE :)-
[^]Re: Interprété ou compilé ?
Posté par Loïc Ibanez () le 26/11/2005 à 18:56. (lien). Évalué à 1.Je n'ai rien contre Java en général, je constate juste que TOUS les sites en jsp ou autre rament avec un modem 56k ( je teste toujours les applis web avec un 56k ). Alors que TOUT ce que j'ai vu réalisé en Zope est fluide et rapide. Pour le développement, Java est sûrement plus agréable, mais pour la performance il n'y a vraiment pas photo. La différence est suffisemment éloquente pour que je prie tous les soirs que la version 3 de Zope soit moins "uzine à gaz" que les précédentes...
--
Montre moi ton code, je te dirais qui tu es.-
[^]Re: Interprété ou compilé ?
Posté par Stéphane TRAUMAT (page perso, ) le 26/11/2005 à 19:05. (lien). Évalué à 0.et beh, ca, c du test... ton test ne prend même pas en compte le nombre d'utilisateurs du site, l'infrastructure réseau (débit) et la (les) machines qui hébergent l'application...
Je trouve que des sites comme l'ANPE ou http://java.sun.com/ qui tournent sur une platefome Java tournent hyper bien.-
[^]Re: Interprété ou compilé ?
Posté par Loïc Ibanez () le 26/11/2005 à 21:12. (lien). Évalué à 0.Mea culpa, je me suis lancé dans un troll sans rappel. J'ai fait mes tests sur la même machine. Il s'agissait d'un test basique : requête SQL et LDAP et affichage des résultats dans une page à l'intérieur d'une balise div CSS1. C'est vrai que je n'ai testé ni le nombre d'utilisateurs ni la stabilité, ni la montée en charge. Reste qu'au niveau perf... il n'y avait pas photo... Et vraiment j'essaie d'être objectif parce que je trouve que Zope est quand même une sacrée uzine à gaz. Je tue le troll Zope/J2EE que j'ai invoqué...
--
Montre moi ton code, je te dirais qui tu es.
-
[+] [^]Re: Interprété ou compilé ?
Posté par Cyril PIERRE de GEYER (page perso, ) le 27/11/2005 à 22:16. (lien). Évalué à -1.>Je trouve que des sites comme l'ANPE ou http://java.sun.com/ qui tournent sur une platefome Java tournent hyper bien.
En même temps vu que le site de l'ANPE est fait en partie avec PHP c'est normal que ca tourne bien ;)
http://solutions.journaldunet.com/0504/050422_anpe_spip_agor(...)-
[+] [^]Re: Interprété ou compilé ?
Posté par Stéphane TRAUMAT (page perso, ) le 28/11/2005 à 07:58. (lien). Évalué à -1.D'après ce que j'ai lu, c'est la partie éditoriale dont tu parles ? Oui, spip est très bien pour mettre en ligne du texte ;)
Pour plus d'infos : http://www.sopragroup.com/templates/page.php?lang_code=FR&am(...)
On apprend quand même qu'il y a 180 000 connexions par jour, plus de 16 000 sessions simultanées aux heures de pointe :) C'est pas mal.-
[^]Re: Interprété ou compilé ?
Posté par Cyril PIERRE de GEYER (page perso, ) le 28/11/2005 à 19:35. (lien). Évalué à 3.>On apprend quand même qu'il y a 180 000 connexions par jour, plus de 16 000 sessions simultanées aux heures de pointe :) C'est pas mal.
C'est pas mal c'est vrai.
Maintenant si on regarde du coté de alltheweb qui supporte 9 million de pages vues et pres de 30 millions de requêtes par jour on est sur une autre planète.
Une autre planette servie par ... JAVA ? non non PHP !
http://www.zend.com/store/products/cache-case-study.php
Ceci dit ça ne sert a rien de denigrer/rabaisser les autres technos libre, on devrait plutôt faire front commun.
Amicalement,
Cyril
-
-
-
[^]Re: Interprété ou compilé ?
Posté par Ontologia (page perso, ) le 28/11/2005 à 10:37. (lien). Évalué à 2.Pour une fois qu'il y a quelque chose qui marche à l'ANPE (je parle en connaissance de cause)...
ok, je --->[]
-
-
[^]Re: Interprété ou compilé ?
Posté par Gmooron (page perso, ) le 26/11/2005 à 21:00. (lien). Évalué à 4.Euh ...
56k ou pas 56k, ça change quoi au temps de génération de la page ?
Rien-
[^]Re: Interprété ou compilé ?
Posté par Loïc Ibanez () le 26/11/2005 à 22:31. (lien). Évalué à 3.Ça ne change en effet rien au niveau de l'exécution du script côté serveur, mais ça permet de se mettre à la place du client et de se poser la bonne question : la vitesse est-elle supportable ou pas ? C'est peut-être subjectif, mais un client se moque éperdument de savoir qu'il y a 100000 requêtes simultanées sur le serveur. ou qu'une base contient 2 millions d'enregistrements. Il veut SA réponse, et tout de suite, sachant qu'au bout de 20s en moyenne, il clique sur reload et maudit son service informatique...
--
Montre moi ton code, je te dirais qui tu es.-
[^]Re: Interprété ou compilé ?
Posté par Stéphane TRAUMAT (page perso, ) le 27/11/2005 à 10:31. (lien). Évalué à 3.Qu'un utilisateur fasse ce genre d'erreur de raisonnement, c'est compréhensible. Mais qu'un développeur choisisse et se fasse une opinon sur une technologie en se basant sur la vitesse de téléchargement d'un site qu'il a pas fait avec un modem 56K.. c'est un pru ridicule.
-
[^]Re: Interprété ou compilé ?
Posté par Loïc Ibanez () le 27/11/2005 à 15:26. (lien). Évalué à 1.Seigneur c'est ma faute, ma très grande faute... J'avais fait ce test il y a deux ou trois ans. A l'époque le ministère de l'intérieur annonçait publiquement son choix de Zope ( peu connu ) alors que le monde entier avait les yeux rivés sur Tomcat, Jboss, Jonas... Je m'étais alors interressé à Zope (v. 2.7) et j'avais réalisé un test somaire, à partir d'une bdd SQL de 60000 enregistrements et d'un annuaire LDAP de 700 noms. J'avais écrit et testé 2-3 requêtes basiques. C'était brut, rapide. Rien n'était optlmisé. N'empêche, depuis je crois très fort en Zope et j'affronterai mon Troll les yeux dans les yeux :-).
--
Montre moi ton code, je te dirais qui tu es.
-
-
-
-
-
-
-
-
[^]Re: Interprété ou compilé ?
Posté par Julien (page perso, ) le 27/11/2005 à 11:48. (lien). Évalué à 2."Il suffit de quelques minutes d'utilisation pour constater qu'une application sous Zope va vite, vraiment vite..."
Tu rigoles la j'espère ... ?
-
-
-
-
Ptite correction orthographique
Désolé avec ça, mais ça m'agace :
les nouveautés du moteur Zend2 devraient permettre d'obtenir d'encore de meilleures performances grâce entre autres à une gestion plus fine de la mémoire.
(...)
PHP est un langage interprété créé en 1994 par Rasmus Lerdorf. (...) le moteur fut réécrit et publié en 1997 sous le nom PHP3 signifiant PHP Hypertext Preprocessor. PHP4 est sorti en 2000 (...) un grand nombre de nouveautés telles qu'une nouvelle orientation résolument objet ou le support simplifié et amélioré des technologies XML. (...)
-
[^]Pendant qu'on y est
Posté par Philip Marlowe (Jabber id, ) le 25/11/2005 à 13:54. (lien). Évalué à 10.Corrigeons la correction :
les nouveautés du moteur Zend2 devraient permettre d'obtenir d'encore de meilleures performances
ou
des performances encore meilleures, ça sonne même mieux.
PHP6
"PHP6 est déjà sur les rails avec de nombreuses nouveautés"
En particulier le tant attendu support unicode natif (autrement urgent que le support des objets, mais c'est un avis perso).
Et ça, c'est vraiment une bonne nouvelle qu'on attendait depuis longtemps :-D
Non pas que le support unicode natif, ce soit un truc qui se fait tout seul (et je parle pas des problèmes de perfs qu'ils auront à résoudre).
Date, je casse tout #2
Il faudrait peut-etre attendre, Derick Rethans nous l'a refait, il a active du code qui n'aurait jamais du l'etre avant la RC6 (avant derniere version de test). Du coup, on se trouve avec une nouvelle classe interne Date... et vide.
Cela risque de poser problemes a beacoup de monde, une 5.1.1 est envisigee, dans les 2-3 jours.
-
[^]Re: Date, je casse tout #2
-
[^]Re: Date, je casse tout #2
Posté par Pierre Tramonson () le 27/11/2005 à 17:59. (lien). Évalué à 1.Heu si je ne m'abuse en RC on ne s'amuse plus à ajouter / enlever du code hors correction de bug non ?
-
[^]Re: Date, je casse tout #2
Posté par Éric (Jabber id, page perso, ) le 30/11/2005 à 15:26. (lien). Évalué à 4.toi tu n'as jamais vu comment se passe les décisions dans le projet PHP.
Grosso modo on parle bien d'un nouveau code, non fini, qui est contesté publiquement par certains (principalement par paj qui poste plus haut), dont n avait dit qu'il ne serait pas intégré, et qui a été ajouté sans annonce publique dans la dernière RC (rc6) qui a précédé d'une petite semaine la release publique.
Pour l'anecdote le release master a même donné sa conclusion en sous entendant fortement que les problèmes survenus suite à cet ajout ont pour cause un manque de test de la rc6 de la part des détracteurs (et pas de l'ajout de dernière minute)
Malheureusement ce n'est pas chose si rare. Des trucs énormes comme ça on en a vu plein dans PHP. Grosso modo tant que ça plait à la dizaine de personnes qui chapottent PHP, ça passe. Que ce soit testé, complet, intelligent, réfléchi, contesté ou pas n'influe que très peu.
-
Et Oracle ??
Je désespère de faire fonctionner correctement l'API OCI8 dans PHP 4.3.10 de Debian et l'instant client livré par Oracle... l'ensemble crashant en beauté avec corruption de pile dans l'interpréteur PHP.
Alors quand je vois que même PHP 5.1 fournit une API qui ignore Oracle (pas dans la liste présentée en tout cas), je me dis que je ne suis pas au boût de mes peines.
Bien sûr si quelqu'un a réussi à compiler PHP 4.3.10-15 Debian Sarge 3.1 avec le support OCI8 (classique ou instant client), je suis preneur de la solution. Merci d'avance.
-
[^]Re: Et Oracle ??
Posté par PierreJ () le 25/11/2005 à 18:01. (lien). Évalué à 2.pdo_oci est peut-etre ce que tu as manque.
Il y a eut bcp de travail fait pour le support Oracle,
http://pecl.php.net/package/PDO_OCI
et
http://pecl.php.net/package/oci8
Par contre tu peux commencer a oublier php4...
-
[^]Re: Et Oracle ??
Posté par PierreJ () le 25/11/2005 à 18:10. (lien). Évalué à 5.Petite erreur, le package oci8 fonctionne avec php4, donc bonne nouvelle.
Si tu as des problemes ou des requetes, je te suggere de poster sur la liste pecl-dev de php, les auteurs Antony et Wez sont tres reactifs.-
[^]Re: Et Oracle ??
Posté par Yves Martin () le 28/11/2005 à 07:49. (lien). Évalué à 1.Merci pour la piste, je fais chercher...
-
-
"PHP6 est déjà sur les rails"
Ah non je proteste, c'est Ruby qui est sur les rails :-)
Le numéro que vous avez composé est imaginaire.
Veuillez tourner votre téléphone de 90 degrés et recomposer.
upload progress monitor
Toujours aucune possibilité de fabriquer une barre de progression d'upload sans bidouiller ? (càd sans patcher php, ni ajouter du perl)
C'est dommage de ne toujours pas intégrer un truc comme http://pdoru.from.ro . Surtout pour beaucoup de projets qui permettent d'uploader des fichiers, mais pas de savoir le temps que ça prend ni l'avancement.
-
[^]Re: upload progress monitor
Posté par Mildred (Jabber id, page perso, ) le 26/11/2005 à 14:22. (lien). Évalué à 8.Question bête, ce ne serait pas au navigateur de le faire ?
Car lui, il sait tout du fichier envoyé ... non ?-
[^]Re: upload progress monitor
Posté par baud123 (Jabber id, page perso, ) le 29/11/2005 à 23:11. (lien). Évalué à 3.non : c'est breveté !
:-p /o\
http://swpat.ffii.org/pikta/txt/ep/0394/160/
-
-
[^]Re: upload progress monitor
Posté par Ymage (Jabber id, ) le 26/11/2005 à 15:45. (lien). Évalué à 2.Ce n'est pas un manque de PHP mais du fait que le protocole HTTP est synchrone et que PHP est executé côté serveur.
Donc même si un jour PHP proposait une solution, ce serait forcément un détournement du fonctionnement du protocole.
La solution dont tu parles n'est d'ailleurs rien d'autre qu'une bidouille. Je ne suis pas partisan de l'intégration de ce type de bidouille au sein de PHP ni même d'un autre langage.
Rien ne t'empêche d'utiliser Ajax pour trouver une solution.



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.