Stéphane Mariel, auteur du Cahier du programmeur PHP 5, nous donne son point de vue sur les grandes nouveautés et les apports de cette dernière version de PHP.
Il en ressort que PHP est sur la bonne voie pour concurrencer J2EE et .Net, et présente désormais des avantages non négligeables pour les équipes de développement.
Stephane Mariel est coutumiers des cahiers du programmeurs puisqu'il a déjà écrit un ouvrage sur le couple PHP & PostgreSQL.
Résumé de l'intervention d'Eric Daspet
Lors de la dernière rencontre AFUP Eric Daspet, co-auteur du livre "PHP5 Avancé" a présenté les nouveautés techniques de PHP5. Un résumé est disponible sur le site de l'AFUP. Les slides Oo.org seront également bientôt disponibles.
Notons qu'Eric Daspet sera présent au Forum PHP 2004 ou il animera une session sur XML.
Aller plus loin
- Interview de Stephane Mariel (19 clics)
- Résumé de la rencontre AFUP : PHP 5 (17 clics)
- Forum PHP 2004 (5 clics)
# Le php
Posté par blenderman . Évalué à 3.
C'est si simple ! je réalise meme certains script linux en php alors que je devrais utiliser le bash ! :)
Allez bonne nuit, il est temps pour moi !
[^] # Re: Le php
Posté par XHTML/CSS inside (site web personnel) . Évalué à 5.
Et il est possible de faire des trucs assez efficaces : j'ai programmé l'intranet de ma boîte, avec gestion de divers types de factures, accès avec gestion de droits, gestion des frais de la boîte, versions imprimables, etc... sans trop me prendre la tête.
La patron qui n'était pas très chaud à cette idée le reconnait lui-même : il n'arrive plus à s'en passer et gagne un temps fou.
[^] # Re: Le php
Posté par tene . Évalué à 7.
- c'est du PHP5?
- que penses-tu de la maintenabilité de ton code?
- combien de temps un développeur tiers prendrait pour comprendre ton code/design/modèle/...?
- tu as déjà utiliser J2EE ou .NET?
- comment ton application supporte-t-elle la montée en charge?
- quelle base de donnée? mysql?
[^] # Re: Le php
Posté par XHTML/CSS inside (site web personnel) . Évalué à 7.
-Ce n'est pas du PHP 5 (quoique le PHP4 c'est du PHP5 !)
-Le code est assez facile à maintenir (le max de temps qu'une erreur nous ait pris est de 20 mn... la secrétaire avait fait une connerie...)
J'estime que quand les erreurs/oublis/rajouts/suppressions sont rapides à trouver, le système (prog et langage) est bien adapté aux besoins.
-Le code n'est pas trop dur à comprendre pour qqu'un qui a l'habitude en PHP. Les seuls trucs un peu "sioux" sont des bidouilles en PHP pour générer du javascript pour certaines améliorations de l'ergonomie (listes déroulantes qui interagissent entre elles pour simplifier le boulot de l'utilisateur par exemple), mais rien d'insurmontable.
-je n'ai que quelques rudiments en Java, et je n'ai jamais utilisé .NET (je pratique par contre l'ASP qui est amha bien moins souple à maintenir que du PHP... et moins riche !)
-Elle peut encaisser une légère charge sans souci, mais elle n'est pas prévue pour encaisser de très grosses charges ama.
-la base de données est en effet mysql (je n'avais pas besoin d'une grosse artillerie point de vue base, mysql suffisait amplement).
Mon sentiment est que PHP a de très bonnes possibilités dans des petites/moyennes applications. (pour les grosses applis, je ne sais pas, donc je m'abstiendrai de dire qqch)
A mon sens, il faut encore laisser murir ce langage, mais il faut lui laisser sa relative simplicité (c'est ce qui m'a intéressé au début, et c'est encore ce qui plait à beaucoup).
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 7.
La question est surtout de savoir si le code est facile à maintenir par une tierce personne. Enfin celà ne vient pas trop du langage mais plutôt de la façon dont est architecturé la solution et la doc qui va avec.
je pratique par contre l'ASP qui est amha bien moins souple à maintenir que du PHP... et moins riche !
ASP c'est vieux de 5 ans, maintenant c'est ASP.NET, et celà n'a pas grand chose à voir, surtout question richesse et souplesse.
Mon sentiment est que PHP a de très bonnes possibilités dans des petites/moyennes applications. (pour les grosses applis, je ne sais pas, donc je m'abstiendrai de dire qqch)
Voilà, je crois que tu as tout à fait raison : PHP est limité aux petites et moyennes applis web et ne joue pas du tout dans la même cour que J2EE et .NET dont l'étendue des possibilitées est bien plus grande. Il ne faut pas se leurer, ces plateformes n'ont pas le même objectif, et essayer de rendre PHP aussi puissant que ces 2 autres plateformes reviendrait à enlever la simplicité qui fait la force de PHP.
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Je rajouterais juste qu'à l'époque de l'asp, je faisais en parralèle du PHP et le php était déja en avance ;)
http://about.me/straumat
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 1.
Vi enfin tu connais Microsoft, quand ils ont un train de retard sur un marché porteur, ils rattrapent le train et bien souvent vont loin devant, les autres courrent derrière ;)
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
C a d, je me rapproche de ce qui se fait, j'y colle et je l'etends... et tant pis si au passage je nique la norme ( cf html, css... )
Quand aux autres qui courrent derrière... il me sembl qu'ils courent dans certains domaines après linux, ils courrent après J2EE, ils courrent après oracle, ils courrent après PHP....
http://about.me/straumat
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 1.
Il n'y a qu'un des 4 points où je suis d'accord : Oracle. Pour J2EE, je penses que le train est largement rattrapé : après ce qui fait la différence c'est ce qui tournent dessus. Pour PHP, je vois pas trop en quoi ils courrent derrière... Ils l'ont fait, mais ce n'est plus nécessaire. Pour Linux, je ne rentrerai pas dans le troll, je dirais juste qu'il est vrai que Microsoft courrent après une certaine forte de communauté, pour le reste celà dépend des secteurs. Enfin on s'éloifne du sujet là :)
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
PHP : http://www.afup.org/article.php3?id_article=2(...) est un exemple...
Et oui, php est très utilisé, je ne compte meme plus le nombre de web agencies et pme qui développent avec PHP... ils ont tous balancé l'ASP depuis longtemps.
Linux... ca serait trop long à répondre... par exemple, dans le domaine des serveurs web : Il y a un bon retard qui ne semble aucunement se réduire... IIS est un autre produit MS à la traine.
http://about.me/straumat
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 2.
Je crois que si PHP a tant de succès c'est aussi frâce à l'ensemble constitué avec Apache et MySQL. MS se trouve dans une position bizzare : ASP était pourri par rapport à PHP, du coup ils sont repartis de 0 : résultat une solution libre a fait ses preuves et est devenu en quelque sorte une référence, ASP.NET étant jeune et basé sur une plateforme inconnue. Mais là encore, même si ASP.NET est pour moi techniquement au dessus (c'est surtout de celà que je parlais quand on parlait de trains), les arguments marketings ne remplaceront pas une communauté... Enfin je penses que dans les solutions d'entreprise MS a de bonne chances de réussir à implenter ASP.NET, celà va à mon avis croître avec l'adoption du framework .NET : les programmeurs seront alors familiers avec cette plateforme, la transition et l'interaction avec ASP.NET sera alors très simple et naturelle.
Pour Linux, j'aurai commencé par la même situation que toi, puis j'aurai montré la part du desktop pour montrer que dans d'autres domaines... :)
[^] # Re: Le php
Posté par Temsa (site web personnel) . Évalué à 2.
Néanmoins, j'ai testé des sites comme dabs.com (fait apparament en vb.net), la présentation bug un peu (il me manque le bas des pages dans les listes de produits), il est globalement lent, et sur certaines page j'ai eut droit a de belles erreur .NET.
Dabs.com ont apparament repris le look "standard" .Net (si j'ai bien compris, les onglet par exemple sont des composants "standard"), un copain ayant travaillé en .Net cet été m'a dit "ça c'est du .net" alors que je naviguais dessus... J'espere que tous les sites .net ne vont pas se ressembler!
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 1.
Nan sérieux me dis pas que tu juge la qualité d'une plateforme à l'utilisation qu'en fait un mauvais programmeur :)
Pour l'histoire des onglets, ben en fait faut comprendre ce qui est dispo dans .NET : tu as à ta disposition un ensemble de "widgets" prédéfinis, qui se programment exactement comme leurs équivalent dans les applications lourdes. Celà permet de concevoir très rapidement un site web avec des briques de bases, d'ailleur celà peut se dessiner de la même manière sous Visual Studio, la seule différence venant de l'interface, qui est du HTML.
Bien entendu, celui qui recherche la productivité seulement, peut se contenter de cette solution. Mais après libre au développeur de modifier les paramètres par défaut pour relooker entièrement son site. Tu retrouves le même concept dans le monde Java depuis peu, en moins abouti cependant.
Solution 2 : tu ne tient pas du tout compte de ces composants, et tu te refais une interface avec des composants de moins haut niveau, ou directement à base de HTML comme tu le ferais en PHP.
Il faut bien voir que ce n'est qu'un des aspects de ASP.NET, cet aspect ne permet pas d'avoir un contrôle total sur le code généré, les widgets prédéfinis générant automatiquement le code associé (heuresement, sinon je verrais pas l'intérêt)
[^] # Re: Le php
Posté par pasBill pasGates . Évalué à 0.
Pour PHP, J2EE et serveurs web, tu utilises la quantite de gens qui l'utilisent pour juger de si c'est bien ou pas.
Si tu veux, je te fais une liste de 200 pages ou MS est le plus utilise, ca ne voudra pas dire que c'est la meilleure solution pour autant tu en conviendras...
[^] # Re: Le php
Posté par Éric (site web personnel) . Évalué à 4.
Il ne dit pas la même chose que toi : il dit qu'il ne connait pas donc s'abstient de juger. Toi tu dis "c'est pas bon". Il me semble qu'il y a une nuance importante (un fossé ?).
> PHP est limité aux petites
> et moyennes applis web et ne joue pas du tout dans la même cour
> que J2EE et .NET
Je ne conteste pas encore, je demande simplement "pourquoi ?" et "où sont tes arguments ?"
Il y a effectivement des fonctionnalités très avancées en Java qui ne sont pas présentes en PHP. Maintenant le nombre d'application Web en ayant *besoin* est à ma connaissance *très* limité.
je cherche donc à comprendre un peu ton affirmation.
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
les messages asychrones...
Imagine, tu as un site web à gros volume... quand un mec valide son caddie, tu crées la commande, envoie un mail de confirmation, génère des commandes fournisseurs....
En php, tu fais ça dans la page.. 2 problèmes :
- Le mec risque d'attendre longtemps son résultat
- si 10000 mecs passent commande en même temps le site est mort...
Avec J2EE, je gère des messages asynchrones, c a d que je crée la commande dans la page résultat et le client voit aussitot que c'est bon... le numéro de commande est envoyé dans une ville d'attente et les envois de mail, les commandes fournisseurs et tout le reste est traité quand le tour du message est arrivé
Avantages :
- l'utilisateur obtient sa page résultat plus vite
- tu gères la montée en charge.
http://about.me/straumat
[^] # Re: Le php
Posté par Hardy Damien . Évalué à 1.
ajouter une entrée dans une file d'attente ça reste dans ses possibilité (bdd / fichier ...).
C'est juste un choix d'architecture ...
Dam
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Là, c normalisé, ca fonctionne, c transactionnel et tout le reste...
Tu peux toujours réinventer la roue mais c plus sympa de réutiliser... surtout qu'il y a plein de produits qui existent pour ça et qu'ils sont interopérables
http://about.me/straumat
[^] # Re: Le php
Posté par hex . Évalué à 1.
Pas forcément.
Tu peux utiliser le toolkit Spread pour faire du messenging :
http://pecl.php.net/package/spread(...)
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Le php
Posté par hex . Évalué à 1.
http://www.spread.org/JMS4Spread/(...)
[^] # Re: Le php
Posté par Cali_Mero . Évalué à 2.
http://www.phpit.net/articles/how-to-jms-php(...)
[^] # Re: Le php
Posté par Éric (site web personnel) . Évalué à 5.
Maintenant il est où ton problème ?
- l'envoi du mail ? rajouter un mail dans une queue c'est très rapide, ce n'est pas un problème et c'est le boulot du serveur de mail que de gérer sa queue pour l'envoie et gérer la charge mail.
- l'insertion dans la Bdd ? en général les sgbd qui sont fait pour supporter ce genre de volumes en nombre de connexions acceptent des instructions "delayed" ou des choses du genre, ce n'est donc pas un énorme problème non plus.
- l'interface avec les fournisseurs ? c'est vague, en général ça revient à appeler un programme qui fait son propre boulot, ou faire une requête sur le SGBD. Ce n'est pas ça non plus qui pose grand problème.
Si réellement tu as un problème de ce coté là tu fais une file avec ton SGBD ou avec un programme externe qui gère la file de commande. Tu n'as peut être pas un objet qui s'appelle "asynchrone" et qui présente une méthode toute jolie mais ça ne prend pas deux heures à faire.
Et comme je le répète, quand bien même ton exemple poserait problème, vu le nombre de gens qui ont besoin de gérer 10000 commandes simultanément via une interface Web ... ça voudrait dire que Java peut tout à fait être réservé à une niche très réduite, 99.99% du Web restant avec un outil simple comme PHP, même pas capable de gérer une dizaine de millier de commande simultanées ;)
> - tu gères la montée en charge.
Grande question. Java "supporte" la charge, PHP permet une scallabilité. En PHP tu n'as pas tout ce qui est résident en mémoire, tout ce qui est commun, transactionnel et tout ça. Le propre du modèle c'est que pour monter en charge il suffit de rajouter un serveur en parralèle, et l'essentiel des problèmes de concurence ou de charge se retrouvent coté SGBD. Comme les bons SGBD savent aussi se gérer en cluster avec plusieurs frontaux ... il n'y a pas de réels problèmes de scalabilité.
[^] # Re: Le php
Posté par tene . Évalué à 4.
Ca dépend ce qu'il y'a derrière
"l'envoi du mail ?"
Marrant, on vient d'implémenter l'envoie dans un thread, ça prenait 5 secondes, bcp trop long. Maintenant c'est mieux... dommage que java (1.3) ne propose pas de pool de thread en standard d'ailleurs.
"l'insertion dans la Bdd ?"
Si tu as la chance d'avoir une bd qui va bien, qui est proche de toi, et que tu es le seul à utiliser... pq la plupart des sites implémente une cache si la bd n'est pas critique? (bien que ce n'est pas la seule raison pour mette une cache)
"l'interface avec les fournisseurs ? "
Soyons moderne, c'est du webservice (ou ce que tu veux d'autre...) le délai commence à se compter en secondes!!
Cependant je comprends ton point de vue: PHP permet de tout faire (comme les CGI en C le permettent aussi d'ailleurs...). Cependant, offrir des solutions à la "t'as qu'à faire ça", alors que J2EE offre un framework "standard" de son côté... ça en fait hésiter plus d'un.
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Deux choses... ce n'est pas 5000 commandes par secondes toutes les secondes de la journée
et deuxièmement, le site ne sert pas qu'à faire des commandes, donc il y a de la charge de l'autre coté.
l'envoi du mail ? rajouter un mail dans une queue c'est très rapide, ce n'est pas un problème et c'est le boulot du serveur de mail que de gérer sa queue pour l'envoie et gérer la charge mail.
Je ne parle pas d'un email simpe...j'envoi parfois des mails très compliqué... numéro de suivi, liste des commandes en cours, vérification de l'encours, contact avec le service expedition.
- l'insertion dans la Bdd ? en général les sgbd qui sont fait pour supporter ce genre de volumes en nombre de connexions acceptent des instructions "delayed" ou des choses du genre, ce n'est donc pas un énorme problème non plus.
ah si tu pars du principe que tu as une BDD qui peut encaisser toutes les charges sans dégrader les performances du reste du site.. Beh en effet, balance lui tout dans la gueule
- l'interface avec les fournisseurs ? c'est vague, en général ça revient à appeler un programme qui fait son propre boulot, ou faire une requête sur le SGBD. Ce n'est pas ça non plus qui pose grand problème.
beh ça rajoute..
Je ne dis pas qu'il est impossible de faire ça sans messagerie asychrones.. je dis juste que ca réduit la charge.
Autre avantage... des trucs comme JMS permettent de réduire le couplage des développements.. (nottament entre développeurs / ou équipes de développeurs)
Pour mon exemple, on va créer une file d'attente "commandesCrees"...
Le développeur qui génère le mail s'abonne à cette liste et génère ces emails..
L'équipe de développeur qui s'occupe du réaprovisionnement s'abonne lui aussi et développe son système...
Tout le monde peut donc développer indépendament.
http://about.me/straumat
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 2.
Moi je confirme ce qu'il dit et justement j'étend au domaine qu'il ne connait pas pour mieux répondre au sujet posé par cette dépêche :) C'est bien parcqu'il y a un fossé que j'ai voulu précisé...
Je ne conteste pas encore, je demande simplement "pourquoi ?" et "où sont tes arguments ?"
Mes arguments sont essentiellement basés sur ce que permet la plateforme en elle-même :
il suffit de regarder l'ensemble des APIs disponibles : PHP est principalement orienté web alors que les 2 autres plateformes peuvent à peu près servir à tout. Hors dans les grosses applications il faut parfois intégrer son application web à d'autres solutions métiers, et, surtout dans le cas de J2EE, l'existant est parfois énorme : l'intégration est naturelle, le site web devenant une des interfaces de la solution globale.
C'est aussi pour celà que je dis qu'ils ne jouent pas dans la même cour : leur domaines d'applications ne sont pas du tout les mêmes, on peut très bien envisager de faire une application multimédia en .NET alors qu'en PHP voilà quoi... PHP est limité au Web et tout ce qui tourne autour plus ou moins directement.
[^] # Re: Le php
Posté par Éric (site web personnel) . Évalué à 4.
Oui PHP n'est pas fait pour une application multimédia. Mais comme tu dis on parle de frontaux Web. Développer un module PHP qui charge une lib C et en appelle les fonction, c'est l'histoire de quelques heures au plus. Je ne te dis pas de gérer ta logique métier en PHP, mais d'utiliser PHP pour ce qu'il sait faire : un frontal Web (éventuellement un peu plus loin si c'est plus simple vis à vis de l'existant mais on sort de son domaine de prédilection). Rien n'empêchera après de connecter ton PHP à des objets COM/RPC ou Java et d'en utiliser les méthodes.
Effectivement, ils auraient du rajouter dans la news "concurrents *dans le domaine Web*". Mais quand je vois le nombre de sites Web avec du J2EE de partout qui sont de véritables monstres pour faire quelque chose de super simple en PHP .. ça me fait un peu mal. Mis à part quelques exceptions, la plupart des sites Web "pourraient" tout à fait être fait en PHP. (attention, je n'ai pas dit que les autres langages sont à jeter pour autant, mais au moins il s'agit d'une alternative valable).
[^] # Re: Le php
Posté par Volnai . Évalué à 4.
Probablement rien. On peut aussi tout faire en C avec des cgi. Dirais tu pourtant que les CGI c'est aussi bien que php ?...
Mon avis a moi, c'est que l'avantage de Java est que les API sont normés. C'est à dire que si je sais écrire un truc qui accede a une base de donné avec un pool et JDBC en utilisant le standard J2EE, à priori je devrait pouvoir comprendre le code de la grande majorité des code d'accés BD de l'ensemble des applications java existantes. La connection à une base etant quelque chose de trivial en php, on va aller plus loin et parler de la gestion des objets persistants, autrement dit les EJB. C'est pareil, c'est normalisé ce truc (on dit normé ptet?). En php tu peut le faire aussi, mais il n'y aura pas 2 programmeurs qui feront ca pareil, il mettrons plus longtemps à le faire (reinventé la roue, toussa), et si j'arrive derrière je mettrais 3 ans avant de comprendre leur code. Avec J2EE, c'est prevu pour, c'est precis, et en bonus on est plus sur de la qualité du code (tout ceux qui reinvente la roue ne sont pas des genies).
[^] # Re: Le php
Posté par Éric (site web personnel) . Évalué à 1.
Ca a du bon et du moins bon, c'est une philosophie. Ca permet à un mauvais programmeur de faire n'importe quoi. Ca permet aussi à un bon architecte de choisir son outil ou de faire une solution simple qui correspond à ses besoins.
Après l'avantage de PHP c'est que c'est globalement simple. On n'a pas le contrecoup d'une appli en C comme tu en parles. Si PHP a justement un avantage par rapport à Java sur lequel tout le monde s'accorde c'est sa simplicité. Malgré le fait qu'il co-existe 10 roues différentes, pour un soft bien codé (je ne parle pas de la myriade de bout de code PHP qu'on trouve sur le net ni des phpnuke & co) le code PHP est facilement compréhensible. En Java des fois c'est assez lourd donc il faut explorer quelques temps.
On a les avantages (choix) sans les désavantages (relecture). Les deux seuls problèmes arrivent sur les gens comme moi qui prennent 10 ans pour faire un choix, ou les gens qui codent mal par nature (et ceux là feront effectivement n'importe quoi)
[^] # Re: Le php
Posté par Emmanuel Hugonnet (site web personnel) . Évalué à 2.
La tu limites Java a J2EE et pire encore tu limites le web en Java a J2EE hors il suffit dans 90% des cas d'un simple container de servlets et en plus tu peux lui plaquer plein de roues : par exemple JDO, Hibernate, JDBC au lieu des EJBs, les containers legers a la Spring, etc.... Bref le choix est aussi present et heureusement sinon y aurait pas d'architectes applicatifs en Java :p
Moi je pense que l'avantage de J2EE c'est qu'on a un meilleur support chez les applis proprio et une meilleure interoperabilite avec le reste du SI en 'natif' via des interfaces standards.
[^] # Re: Le php
Posté par TImaniac (site web personnel) . Évalué à 2.
Il ne suffit pas comme tu dis de faire un wrapper vers une libc, parcque tu oublies que PHP se veut portable, et là c'est beaucoup plus délicat : il faut vraiment que tu prennes tes doigts et que tu codes, ca se fait pas en 5 minutes une plateforme de la taille de J2EE ou .NET
Effectivement, ils auraient du rajouter dans la news "concurrents *dans le domaine Web*"
Voilà voilà, mais celà n'a justement pas été précisé, et c'est ce que je regrette : certains vont croire que .NET ou J2EE ne permettent que de faire des appli web (dans le cas de .NET j'en ai même vu qui croyait que c'était uniquement pour faire des Web Services...), d'autres qui vont croire que PHP va être la solution miracle pour concurrencer les 2 autres plateformes, avec la simplicité en plus. Alors que cet atout, la simplicité, n'est valable que parcque PHP est limité à un domaine bien particulier...
[^] # Re: Le php
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Si je puis me permettre de répondre à sa place, est-il possible de développer en PHP des composants et de les intégrer ensuite dans un serveur d'appli qui va gérer la sécurité, le messaging, les transactions (parfois même distribuées), la persistance, les pools de connection, les annuaires, etc...
Je ne vois donc pas où est le mal en disant que ces plateformes ne jouent pas dans la même cour.
Rien n'empêchera après de connecter ton PHP à des objets COM/RPC ou Java et d'en utiliser les méthodes.
Interessant ça. Une URL à me proposer?
Mais quand je vois le nombre de sites Web avec du J2EE de partout qui sont de véritables monstres pour faire quelque chose de super simple en PHP
Là tu as parfaitement raison, les architectures mal dimensionnées sont devenues une vraie plaie, mais qui doit-on accabler?
[^] # Re: Le php
Posté par Éric (site web personnel) . Évalué à 5.
Plein .. la connectivité c'est LE point fort de PHP. PHP est surtout fait pour gérer des frontal Web, et se connecter avec une application ou un autre composant qui gèrera le métier.
- utilisations d'objets COM et composants .NET sous Windows : http://www.php.net/manual/en/ref.com.php(...)
- utilisation d'objets .NET avec Mono : http://pecl.php.net/package/mono(...)
- utilisations d'objets Java (PHP4 uniquement) : http://www.php.net/manual/en/ref.java.php(...)
- utilisation d'une librairie partagée (en C ?) arbitraire : http://pecl.php.net/package/ffi(...)
- utilisation de code et d'objets Perl : http://pecl.php.net/package/perl(...)
- utilisation de code et d'objets Python : http://pecl.php.net/package/python(...)
Plus génériques :
- par XML-RPC : http://www.php.net/manual/en/ref.xmlrpc.php(...)
- par SOAP : http://fr.php.net/soap(...)
Ca donne déjà un bon panel des possibilités (j'ai ouie dire aussi d'un connecteur ruby mais il n'a pas l'air de se trouver officialisé sur PHP, PEAR ou PECL).
Dans l'optique inverse on peut intégrer PHP comme langage de script d'une plus grosse application (à la manière d'ActivePerl et autres) : http://pecl.php.net/package/PHPScript(...)
L'extension Java n'a pas été portée vers PHP5 mais Sun a décidé de faire toutes ses implémentations de référence pour son futur JSR avec PHP. Sun s'est donc engagé avec Zend pour réaliser la connectivité complète PHP/Java (dans les deux sens). C'est à priori un gage de sérieux et de pérénité pour les interractions avec Java (le temps qu'ils fassent l'implémentation PHP5).
Coté plus applicatif on a aussi des connecteurs vers pas mal de trucs. Au dernier forum PHP on avait une entreprise qui exposait ce qu'elle a fait sur son intranet : un frontal PHP qui se connecte à leur ERP SAP pour le piloter et fournir des interfaces Web pour les trucs utilisés.
L'idée est là : pas de refaire l'application Java ou de refaire un ERP, mais de faire rapidement un frontal très simple qui utilise des connecteurs pour chercher la logique métier. PHP s'occupe alors de la partie Web (et uniquement de la partie Web) en évitant de monter tout un J2EE et des concepts complexes là où ce n'est pas nécessaire.
> mais qui doit-on accabler?
Pas le langage certes, mais quand on me dit que ça ne gère pas X, Y, Z ... la question est souvent "oui, mais vous en avez vraiment besoin ? si vous repartez sur quelques petites lignes simples au lieu de faire une grosse architecture monstre, vous n'en auriez peut être pas besoin.
[^] # Re: Le php
Posté par MuadDib (site web personnel) . Évalué à 1.
En se qui concerne la monté en charge, se n'est pas que le langage qui est à prendre en compte. On peut très bien avoir un site web avec plusieurs millions de connexions écrit en PHP. Y a qu'à voir les site de la Française de Jeux (http://www.fdjeux.com/jeux/loto/loto_d_tirage1.php(...))
Imagine toi un soir de tirage de gros lot. Les serveurs déguste, j'en sais quelque chose, j'ai un ami qui maintient infrastructure serveur chez eux.
C'est comme pour le J2EE. J'ai travaillé sur une application J2EE installer sur 14 serveurs SUN. La c'est vraiment l'infrastructure qui permet les perfs.
Je pense que le choix du langage se fait en fonction des équipes en place et de la structure de ces équipes.
Exemple : Avec Struts tu peux organiser tes équipe comme suis :
Donc tu as 4 équipes distincte.
Je ne c'est pas si en PHP on peut faire les mêmes séparation, mais si c'est possible, le choix sera :
Quelle sont les languages que connaissent les gens de mes équipes ?
Donc y pas de Troll ;-)
[^] # Re: Le php
Posté par tene . Évalué à 2.
C'est perso ce que je reproche le plus à PHP: difficile de se faire des composant *bien* isolé et facile d'emploi... un truc du genre custom tags à la java ou mieux webcontrols ferait du bien à PHP. Surtout vu sa communauté.
Pour ce qui est de maintenir l'application, je suis plus exigeant que toi: 20 minutes pour un bug, tu y rajoutes les test et le temps de mep... ça peut devenir long pour une appli critique. (tiens tu debug comment ton PHP? à l'époque j'avais pas trouvé grand chose, mais j'ai peu cherché et je connais très peu le PHP)
En fait c'est essentiellement niveau abstraction que je reproche des choses à PHP: que faire par exemple si tu veux changer de base de donnée? Changer de mot d'authentification? Changer le layout de tes pages? (boulot que tu vas vouloir refiler à un infographistes... enfin ce sera le cas si t'es aussi bon que moi en design :p).
Concernant ta conclusion je suis plutôt d'accord avec toi: pour une petite ou moyenne appli, il offre de bon service, et est rentable niveau temps investi. Cependant, J2EE et ASP.NET (surtout ce dernier) deviennent de plus en plus accessible... Si tu as l'occasion, le temps et une machine windows, je te conseille de jeter un oeil à Visual Web Developer Express Edition (à télécharger depuis msdn.microsoft.com).
[^] # Re: Le php
Posté par Gabriel . Évalué à 0.
Et...tu saurais où trouver les paquets debian?stp?
ok je vais faire du php ------>[dehors]
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Ca commence à me rappeller le fameux " Ohla, vous embettez pas, utilisez vb + access ! "
Perso, pour ma boite, la rentabilité d'un contrat ne dépend pas tant du temps de dev que de la maintenance et de l'évolutivibilité
http://about.me/straumat
[^] # Re: Le php
Posté par Damien Pobel (site web personnel) . Évalué à 1.
Généralement tu emploies une classe d'abstraction genre PEAR::DB ou AdoDB, et tu as juste à changer un paramètre qui se trouve généralement défini par un fichier de config. je vois pas où est le problème...
[...] Changer de mot d'authentification? [...]
j'imagine que tu parle de mot de passe, même réponse que précédement, c'est la config de l'application et tu définis ça à un seul endroit.
Changer le layout de tes pages? (boulot que tu vas vouloir refiler à un infographistes... enfin ce sera le cas si t'es aussi bon que moi en design :p).
Si l'appli est bien faite, la présentation est séparé du code "métier". La tu as différentes manière de procéder ( création de blocs XHTML avec positionnement en CSS ou XML+XSLT+CSS ...)
Bref tout ça pour dire, que le langage n'a qu'une petite influence et que ce qui compte, c'est une conception propre. On ne conçoit pas une grosse appli web comme sa page perso!
La seule chose, c'est qu'un langage peut inciter ou non à faire des trucs pas propres, et là faut bien avouer que PHP permet certaines "bidouilles" qui finissent par nuire plus qu'autre chose...
Et puis je pense aussi que la simplicité de PHP lui nuit beaucoup. quand je vois le nombre de gens autour de moi qui disent connaitre PHP juste par ce qu'il sont capable d'insérer du code dans une page HTML et qu'ils ont fait leur site perso à grands coups de bout de PHP parsemés dans le code HTML forcément ça donne une mauvaise image. Phénomène quasi inexistant avec J2EE ou .NET.
https://damien.pobel.fr
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Sauf que tu es limité... dans tes classes d'abstractions, tu as souvent très peu de méthodes.. par exemples, tu n'as pas de fonction de découverte de ta base .. style la liste des tables
j'imagine que tu parle de mot de passe, même réponse que précédement, c'est la config de l'application et tu définis ça à un seul endroit.
En J2EE, peu importe ton appli, tu n'as pas de fichier de config spécifique.. tu peux définir les rôles et les utilisateurs à coté... ca te rend indépendant.
Si l'appli est bien faite, la présentation est séparé du code "métier". La tu as différentes manière de procéder ( création de blocs XHTML avec positionnement en CSS ou XML+XSLT+CSS ...)
Sauf que j'ai très rarement vu de MVC en php mais je vais me renseigner.
http://about.me/straumat
[^] # Re: Le php
Posté par Damien Pobel (site web personnel) . Évalué à 1.
Tu veux parler de ça : http://phplens.com/adodb/reference.functions.metatables.html(...) ou http://pear.php.net/manual/en/package.database.db.db-common.getlist(...) ? ;)
En J2EE, peu importe ton appli, tu n'as pas de fichier de config spécifique.. tu peux définir les rôles et les utilisateurs à coté... ca te rend indépendant.
Une fois de plus c'est le choix entre prédéfinir directement dans framework (J2EE) ou de laisser l'utilisateur faire sa tambouille (PHP), on en revient à ce que j'évoquais plus haut, en PHP c'est reporter sur la conception de l'appli, c'est qui fait que c'est simple pour l'utilisateur lambda puisque c'est le concepteur définit le truc comme il le sent (parfois mal :)
Chaque approche a ses avantages et ses inconvénients...
Sauf que j'ai très rarement vu de MVC en php mais je vais me renseigner.
Peut être justement parce qu'on croit que PHP n'est pas bon pour de gros projet (où le MVC est nécessaire) et que pour les plus petits projets ou on utilise PHP, MVC n'apporte que lourdeurs et complications inutiles.
J'ai trouvé ça sinon http://www.phpmvc.net/(...) mais je sais pas ce que ça vaut...
https://damien.pobel.fr
[^] # Re: Le php
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Pour la sécu.. ok, mais je pense que l'informatique va de plus en plus vers l'idée de "je redéveloppe pas tout".. la persistence des données, les messages asynchrones, la sécurité, le pool des connexions devraient être des "commodités" mais je suis d'accord que ca complique la chose.
Pour MVC.. voila, bien sur ca existe mais combien de gens font du mvc avec PHP ? j'en connais pas beaucoup...
on peut aussi faire des tests unitaires avec PHP mais combien en font ? en java, ce sont deux choses devenues communes.
http://about.me/straumat
[^] # Re: Le php
Posté par XHTML/CSS inside (site web personnel) . Évalué à 2.
Donc vraiment pas dramatique (en tout cas dans ce cas précis).
Perso, je n'aime pas entendre "Java ça pue c'est lourdingue" ou "PHP/Mysql c'est trop limité pour gérer telle appli", à chacun son domaine d'excellence.
Par contre, je jetterai un oeil à .NET un de ces 4, ne serait-ce que par curiosité...
[^] # Re: Le php
Posté par nooky59 . Évalué à 2.
Celà permet de faire du debugage pas à pas avec des EDIs exploitant DBG.
En commercial, il y a ZendStudio et en Open Source PHPEclipse qui se base sur la plateforme Eclipse commence à être pas mal (je n'ai pas testé la dernière version, par contre sous Eclipse 3, le debugger pas à pas ne marchait pas).
[^] # Re: Le php
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 2.
http://www.xdebug.org/(...)
[^] # Re: Le php
Posté par blenderman . Évalué à -2.
# ca sent le fud :)
Posté par Stéphane Traumat (site web personnel) . Évalué à 10.
C'est vrai que PHP est une excellente plateforme mais il y a des choses qui me manquent...
Traitements asychnrones, API d'accès aux données uniformisées, framework MVC à la struts, tests unitaires plus "ancrés"...
Mais j'aime beaucoup PHP, quand j'ai un site à faire qui n'est pas une appli qui doit évoluée, c'est mon choix !
http://about.me/straumat
[^] # Effectivement ca sent le fud :)
Posté par ptitatou . Évalué à 5.
Par contre sur sur l'évolutivité d'une appli PHP, je ne suis que moyennement d'accord. Effectivement, à première vu d'autres solutions peuvent sembler meilleures mais avec PHP, en faisant attention a écrire "proprement" (ndlr : j'entent par la "pas comme un type qui copie 3 ligne de tutoriels pour rendre son site dynamique" ne trollez pas !) et en séparant vraiment style (CSS) cadrage (HTML) et fonctions (PHP) ont obtient des solutions qui sont plutot simple à faire évoluer.
--
xHTML, CSS, PHP, SQL, mais que faut il de plus ... emacs pour coder le tout ...
[^] # Re: Effectivement ca sent le fud :)
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
Meme si c'est plus lourd, je préfère avoir un fichier qui correspond aux données de mon formulaire, une page html ou le graphiste fait ce qu'il fait et un fichier ou je réalise l'appel aux fonctions métiers.
http://about.me/straumat
[^] # Re: Effectivement ca sent le fud :)
Posté par - - . Évalué à 3.
et on peut tout autant construire une solution MVC similaire avec php
mais soit ! il manque à php5 ,non pas un "pear" plus complet, mais un framework MVC fournit de base dans toute distrib.
le problème des solutions mvc est leur lourdeur insoutenable (désolé mais quand on a besoin de faire des sites d'accés à une base de donnée en entreprise on a pas , pour une foule de raisons excellentes je vous l'assure, le loisir de faire du code dans les rêgles de l'art, avec mr java, mr le formalisme etc ).
PHP est avant tout un langage souple et rapide et il me parait vain de l'encenser ou de le critiquer à l'orne de concepts qui ne concernent pas la majorité de ses utilisateurs.
cela dit un framework objet et complet en option serait formidable.
patience et raison comme toujours dans le monde des logiciels libres.
[^] # Re: Effectivement ca sent le fud :)
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Pas besoin de règle de l'art, juste respecter quelques trucs... une feuille de style CSS, un MVC, des tests unitaires et le temps que tu perds au début, tu le regagnes facilement sur la distance.
Je dis juste qu'il manque quelques trucs à php ;) mais c pas forcément une bonne idée de les mettre. Car si PHP a réussi, c certainemetn du en partie à sa simplicité.
http://about.me/straumat
[^] # Re: Effectivement ca sent le fud :)
Posté par duckvador . Évalué à 4.
http://www.mojavi.org(...)
"Mojavi is an open-source MVC (model-view-controller) framework for PHP, licensed under the LGPL. Developing with Mojavi enables you to easily divide your web application into tiers, allowing for independent development."
J'utilise personnellement mojavi 2.0, qui n'est pas php 5 ready. Il donne les bases d'un framework complet et bien fait.
La version 3.0 en cours de développement intégre toutes les nouveautés de php5.
D'aprés moi, ce projet devrait intégrer le framework officiel de php.
[^] # Re: Effectivement ca sent le fud :)
Posté par Éric (site web personnel) . Évalué à 2.
Tu peux aussi faire de pareilles bêtises en C ou dans n'importe quel langage, on ne l'a jamais reproché au langage.
Certes, beaucoup de gens codent n'importe comme en PHP, mais ce n'est en rien une contrainte du langage. Tu peux tout à fait séparer facilement les diverses couches. La plupart des framework te l'imposent, mais même sans quelques coups d'inclusions et c'est réglé.
[^] # Re: ca sent le fud :)
Posté par Gniarf . Évalué à 4.
sinon, il suffirait de demander à n'importe quel gourou de secte son avis sur l'existence des petits hommes verts et on pourrait commencer à préparer leur venue sur Terre...
[^] # Re: ca sent le fud :)
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Mais autant je ne donnerais pas mon point de vue sur le dev en .net ( par contre je peux vous dire mon point de vue sur l'asp mais ca serait pas très poli ), j'éstime que j'ai fait assez de php et de java pour pouvoir donner mon avis sur les deux ;)
http://about.me/straumat
[^] # Re: ca sent le fud :)
Posté par Gniarf . Évalué à 4.
Stéphane Mariel, auteur du Cahier du programmeur PHP 5, nous donne son point de vue sur les grandes nouveautés et les apports de cette dernière version de PHP.
Il en ressort que PHP est sur la bonne voie pour concurrencer J2EE et .Net, et présente désormais des avantages non négligeables pour les équipes de développement.
il manque un "Stéphane Mariel estime que" dans la deuxième phrase.
[^] # Re: ca sent le fud :)
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: ca sent le fud :)
Posté par - - . Évalué à 1.
s'il regressait et était de moins en moins utilisé on pourrait dire 'il est sur la mauvaise voie', mais ce n'est pas le cas.
bref, cela n'a rien d'extraordinaire de dire "il est sur la bonne voie".
[^] # Hors sujet...
Posté par Lefuneste . Évalué à 1.
Bah, nos dirigeants ont bien demandé leur avis aux spécialistes de l'appropriation^W la propriété intellectuelle quant à la pertinence des brevets logiciels...
Ensuite, forts d'un avis aussi "éclairé", ils sont allés les soutenir auprès du conseil des ministres européen...
[^] # Le théorème du lampadaire
Posté par Gabriel . Évalué à 3.
Quand les "dirigeants" choisissent des gens, experts, cadres, pour qu'ils donnent leur avis ou pour qu'ils agissent, ils savent déjà ce que ces personnes pensent en général.
Si un journaliste demande son avis à un expert de l'insécurité, il va dire qu'il y a de l'insécurité.
Si ton patron engage un directeur des ressources humaines qui te semble dur à vivre, c'est qu'il veut virer. S'il prend un gars ouvert et qui s'intéresse surtout à l'humain, aux autres, c'est qu'il cherche à engager.
Si nos dirigeants demandent leur avis aux experts des brevets logiciels, ils auront un avis favorable aux brevets logiciels.
C'est une variation autour du théorème du lampadaire. Soit une personne qui fait tomber ses clés le soir dans la rue. elle doit chercher ses clés en dessous du lampadaire. Pas parce qu'elle a laissé tombé ses clés à cet endroit mais parce que c'est là qu'elle peut chercher.
[^] # Re: ca sent le fud :)
Posté par dinomasque . Évalué à -1.
http://www.bide-et-musique.com/song/3359.html(...)
Oui oui, c'est bien Sa Sainteté et euh ... ben je ->[]
BeOS le faisait il y a 20 ans !
[^] # Foutaises !
Posté par Olivier G. . Évalué à 7.
(hop une ligne au Business Loto :)
Ce n'est peut-être pas un FUD, mais en tous cas ça sent le publi-reportage marketeux pipeau à plein nez... Eh bien oui, peut-on s'attendre à ce qu'un article, relatant un entretien avec l'auteur d'un livre chez Eyrolles, sur le site d'Eyrolles, soit objectif ? C'est juste un article qui fait partie du "plan produit" du bouquin...
Ce n'est guère différent de la pseudo interview du type de LDLC sur le site de Crosoft où il disait que grâce à Ms il est devenu beau, intelligent, et le tout pour moins cher...
[^] # Re: Foutaises !
Posté par Gabriel . Évalué à 0.
Java, avec les ejb, les jsp, les jsf, a souvent un peu, beaucoup, déçu. .net je ne connais pas - j'ai entendu de asp.net, le langage qui permet de faire des pages web, autant d'éloges, que de critiques(on lui reproche d'être n'importe quoi)
Deuxio : au moins ici tu peux dire ce que tu penses. Tu vas me dire: ici tu peux dire ce que tu penses de m$. Oui, mais c'est hors du spectre de m$. Alors qu'ici, on est en plein pays php.
[^] # Re: Foutaises !
Posté par Nelis (site web personnel) . Évalué à 3.
Ok pour les EJB, mais Servlet/JSP est une réussite, JMS est génial, JDBC, JTA, JNDI, JDO, JAX* etc sont tous vraiment très bon. A côté de ça, tu as aussi les projets indépendants : Hibernate, Spring, Tapestry, et j'en oublie des tas.
Même JSF, malgré sa jeunesse est prometteur.
Faut arrêter de dire n'importe quoi.
[^] # Re: Foutaises ?
Posté par Gabriel . Évalué à 2.
- C'est une manière de donner faire aux doigts aux développeurs : <c:out value="${objet.variable}" /> pour un <?=objet.getVariable() ?> Et sans parler des jsp:useBean...
- C'est compilé, recompilé, tout ça pour voir l'effet sur la page de ton changement dans l'agencement de ce qui est généré. C'est franchement long, comme cycle tu ne trouves pas? Alors qu'il s'agit juste d'afficher deux trois trucs, de générer un tout petit bout de html de rien du tout. En ce sens je préfère php pour le dev de html généré dynamiquement. Mon rêve, personnellement c'est bien d'ailleurs de générer le html avec php, mais en utilisant des objets java.
- ça permet de faire trop de choses. Par exemple, des accès bases alors que c'est pas le lieu de le faire. Ok, il suffit de ne pas l'utiliser; et après tout cela permet de donner du travail à ceux qui ne connaissent que Cold Fusion, mais du point de vue architectural c'est pas tip top.
Et s'il existe des projets parallèles, type tapestry, Velocity et autres, pour générer des vues c'est peut-être que la cause n'est pas entendue, non?
Côtés positifs, c'est vrai il y en a pas mal : Et en premier lieu, les taglibs. ça c'est quelquechose de merveilleux! A cause de cela d'ailleurs j'en reste aux jsp pour générer mes micro pagettes... Il faut ajouter aussi la cohérence du tout.
jsf, prometteur? Oui, si tu as un outil pour en générer. Sinon, c'est la tendinite assurée. (façon moqueuse de dire que tu ne pourras pas avoir toujours la main sur le code)
Et puis c'est orienté jsp et justement le modèle événement s'éarticule mal avec les jsp - cf un article dans onjava.com: http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html(...)
[^] # Re: Foutaises ?
Posté par Nelis (site web personnel) . Évalué à 3.
Euh ... Si tu veux tu peux écrire <%= objet.variable %> ...
- C'est compilé, recompilé, tout ça pour voir l'effet sur la page de ton changement dans l'agencement de ce qui est généré. C'est franchement long, comme cycle tu ne trouves pas? Alors qu'il s'agit juste d'afficher deux trois trucs, de générer un tout petit bout de html de rien du tout. En ce sens je préfère php pour le dev de html généré dynamiquement. Mon rêve, personnellement c'est bien d'ailleurs de générer le html avec php, mais en utilisant des objets java.
Personnellement ça ne me gêne pas que ça soit compilé, c'est plus lent la première fois que la page est accédée mais après c'est très rapide vu qu'il n'y a plus de parsing à faire ...
- ça permet de faire trop de choses. Par exemple, des accès bases alors que c'est pas le lieu de le faire. Ok, il suffit de ne pas l'utiliser; et après tout cela permet de donner du travail à ceux qui ne connaissent que Cold Fusion, mais du point de vue architectural c'est pas tip top.
Et s'il existe des projets parallèles, type tapestry, Velocity et autres, pour générer des vues c'est peut-être que la cause n'est pas entendue, non?
Sur ces deux points, je ne comprends pas ton point de vue: c'est normal que tu puisses faire ce que tu veux à partir d'un JSP, c'est une classe ... Je ne vois vraiment pas le problème, si tu veux coder comme un bourin c'est ton affaire ....
Concernant le deuxième point, tu as vu le nombre de browser, d'éditeur texte, de suite office, d'OS, ... qui existe ? Aucune cause n'est entendue. Et c'est tant mieux.
[^] # Re: Foutaises ?
Posté par Gabriel . Évalué à 2.
Personnellement ça ne me gêne pas que ça soit compilé, c'est plus lent la première fois que la page est accédée mais après c'est très rapide vu qu'il n'y a plus de parsing à faire ...
Quand c'est en ligne pas de souci c'est très rapide. Mais C'est quand tu développes que c'est pénible, et ça rallonge le temps de développement.
Je ne vois vraiment pas le problème, si tu veux coder comme un bourin c'est ton affaire .... je suppose que tu voulais dire : "c'est l'affaire de ceux qui codent comme des bourrins"? ;-)
[^] # Re: Foutaises ?
Posté par Nelis (site web personnel) . Évalué à 3.
[^] # Re: Foutaises !
Posté par Gabriel . Évalué à 2.
Pas par rapport à la masse énorme de ce qui a été apporté - effectivement, tous les acronymes, tous ces projets, et tous ces patterns aussi, qui préexistent à java ok mais qui sont largement utilisés et travaillés par la communauté: inversion of control, service locator, dao et compagnie.
[^] # Re: Foutaises !
Posté par Olivier Meunier (site web personnel) . Évalué à 3.
Pas forcemment mais de là à jeter le bébé et l'eau du bain il y a un pas que tu franchis allègrement.
Juste un ou deux rappels :
Le site, la marque, le logo de la Libriairie Eyrolles sont clairement identifiés, ça parle de livre, on est sur un site de libraire, ça me semble logique. Personne n'est pris en traître.
eyrolles.com est le site de la *librairie* Eyrolles et si tu regardes bien on y vend toute sorte de livres d'autres marques. Après, je ne dis pas qu'il est pas plus facile de s'entretenir avec un de nos auteurs...
Par contre, je suis assez d'accord sur le fond, cette interview n'a rien à faire sur une telle news mais vu la sécheresse du contenu de la dite news, ça a servi à meubler.
Quant à la qualité du contenu, je ne jugerai pas le boulot d'une collègue en public.
[^] # Re: Foutaises !
Posté par Éric (site web personnel) . Évalué à 3.
L'interview n'est pas là pour lui demander si Eyrolles est le meilleur ou si son bouquin est le plus beau (ce qui le rapprocherait du cas LDLC/MS que tu site), mais pour parler de PHP le langage.
Autant si tu achètes son livre ça peut l'intéresser, autant si tu choisis PHP au lieu de java, ça ne rapportera rien à Eyrolles (contrairement à MS qui y gagnera si tu suis ce que dit LDLC).
[^] # Re: ca sent le fud :)
Posté par Éric (site web personnel) . Évalué à 2.
ça existe, il y en a plusieurs. Ceci dit struts il y a beaucoup de gens qui en sont revenus.
Il manque effectivement quelques choses comme les objets transactionnels partagés par toutes les requêtes, les traitements asynchrones ...
Mais au final jusqu'à présent je n'ai jamais vraiment renoncé à PHP à cause de ça. J'ai toujours pu faire sans facilement.
# PHP != J2EE
Posté par Nelis (site web personnel) . Évalué à 10.
Quand on a une application d'entreprise relativement complexe avec integration avec des backend, message queue & co, PHP n'est pas une option, à moins d'être suicidaire.
Souhaitons longue vie à PHP (je crois qu'il n'y a pas de soucis à se faire) et arrêtons de mélanger tout ...
[^] # Re: PHP != J2EE
Posté par gabriel . Évalué à 0.
Le monde ne changeras pas dés qu'on annonce php et java sur la meme page web !
PHP et J2EE ??? à la rigueur php et java mais effectivement on ne peut pas dire qu'un language est le meme "scope" qu'une spécification décrivant le comprtement d'un serveur d'application, une convention de nommage, une méthode d'accés aux données etc etc etc etc. Php pour ceux qui comprenne pas c'est un langage ;-)
Quand on a une application d'entreprise relativement complexe avec integration avec des backend, message queue & co, PHP n'est pas une option, à moins d'être suicidaire
ah bon ? je ne vois pas en quoi cela peut déranger avec ce ----> "langage " <----- ... encore on aurait parler de perfs, de portabilité, de sécurité à l'execution etc. pour info, avec une appli " complexe " 250go/an de données la seule chose qui m'as fait passer de php à java c'est qu'en php il n'y as pas de serveur d'application, à part des serveur web le reste c'est le desert. c'est la d'ailleurs qu'on touche le fond du probleme ! le jour ou une boite comme sun ( normal aussi), ou ibm viendra supporter php je suis sur que nous pourrons voir tout un tas d'applis se developper. Pour ceux qui n'auraient pas suivi, un projet qui me semble prometteur http://www.vl-srm.net/(...)
Et pour ceux qui se plaignent encore que php a des manques rien ne vous empeche de participer? c'est pas la foule sur les listes php-dev et pecl-dev et je vous garantis que la traffic est faible.
Et pour ceux qui veulent du framework, meme combat surtout que des solutions intérréssantes existe déjà.
à suivre ...
++
[^] # Re: PHP != J2EE
Posté par Nelis (site web personnel) . Évalué à 3.
Parfois la mauvaise foi de certains atteint des sommets.
Même pas la peine que je réponde au reste ...
[^] # Re: PHP != J2EE
Posté par gabriel . Évalué à -1.
C'est bien ce que j'entendais mais ca reste tout de meme un language avec son runtime. limiter le terme plateforme à php c'est un peujuste. tu me dis Lamp, la je vois plateforme
et pour la mauvaise fois, je trouve que c'est bien de porter un jugement sur soi meme ;-)
rappel : c'est une débat pas un pugilat !
[^] # Re: PHP != J2EE
Posté par Nelis (site web personnel) . Évalué à 4.
[^] # Re: PHP != J2EE
Posté par gabriel . Évalué à -1.
j'ai bien compris ce que tu avait dit mais ce que je vois c'est que tu laisse planer l'impréssion que php n'est pas adpaté pour des applications complexes c'est vrai et pas vrai.
vrai car le language est mature est assez modulaire ( voir pecl et certaines extensions) c'est faux car il lui manque un environement d'éxécution assurant la persistance d'objet, de code, de données etc etc comme tomcat jboss etc etc. c'est la que srm apporte un plus.
il manque aussi des ide et des outils digne de ce nom pour le developpeur.
sans rancune ... :-)
[^] # Re: PHP != J2EE
Posté par nooky59 . Évalué à 4.
Commercial => ZendStudio
Libre => PHPEclipse qui progresse
[^] # Re: PHP != J2EE
Posté par Stéphane Brunner . Évalué à 4.
-------> []
[^] # Re: PHP != J2EE
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 2.
plateforme PHP (langage + API)
C'est bien ce que j'entendais mais ca reste tout de meme un language avec son runtime. limiter le terme plateforme à php c'est un peujuste. tu me dis Lamp, la je vois plateforme
Sur le livre blanc PHP français ( http://afup.org/docs/wp.pdf(...) ) en page 9 il y a un schéma qui montre l'architecture de PHP. On peut y voir que PHP peut être vu avec de nombreux systèmes, extensions et applications.
Il y a à mon sens une difficulté certaines a définir PHP. On ne peut pas dire qu'il s'agit d'un langage car ce serait réducteur (il est possible de coder en objet et en script). De plus en parlant de langage on mets de coté l'impressionnant nombre de briques logicielles et extensions possibles.
La dénomination qui est la plus proche est a mon avis le terme de plateforme.
Ensuite il faudrait s'accorder sur ce qu'est une plateforme parce que chacun a sa définition ;)
Cyril
PS : Tout a fait d'accord sur le fait qu'on débat et que tout agressivité est sans intérêt ;)
[^] # Re: PHP != J2EE
Posté par gabriel . Évalué à 0.
est la phrase complete. effectivement, on devrait tous s'accorder sur le terme plateforme ( tout comme framework) avant de chausser les gants de boxes ! mais j'ai remis juste dans le contexte de plateforme j2ee, .net et ..... php. ( sur trois, deux sont des spécifications ).
C'est dans ce sens que je pense que ce terme est un peu juste. J'en crois le dernier livre traitant de web services et donnant un apercu des differentes plateformes d'intégration. On y voyait j2ee, .net et ... Lamp.
Meme si ne se voit pas je ne défends ni l'un ni l'autre j'essaie juste de comprendre et de remettre les choses à leur vrai place.
[^] # Re: PHP != J2EE
Posté par matli . Évalué à 5.
J'ai des questions concernant PHP: existe-t-il des projets permettant de gérer des pools de connexions vers des bases de données? Parce qu'en standard, c'est un process http = une connexion, et si ça va bien avec Mysql, ça ne va pas du tout avec Oracle. Par contre, avec la mise en pool des connexions, on s'aperçoit qu'il faut beaucoup moins de connexions vers la base que de process traitant les requêtes, et le résultat au niveau des perfs est énorme.
Autre question sur PHP: peut-on faire des redirections "internes", c'est à dire qu'on arrive sur un premier PHP et on est ensuite rediriger vers d'autres PHP en fonction de différents paramètres. Je trouve cette façon de faire vraiment pratique. Par exemple, en Perl, avec mod_perl, le navigateur appelle un cgi qui fera tous les traitements sans cracher le moindre gramme de HTML, puis on redirige en interne vers un Apache::ASP ou autre qui va récupérer les attributs en session et afficher. Il s'agit bien sûr de MVC, tout comme en Java avec Servlet/JSP (celui qui ne fait que l'un ou l'autre n'a rien compris).
[^] # Re: PHP != J2EE
Posté par Tof . Évalué à 1.
http://www.php.net/manual/en/ref.mysql.php(...)
C'est pour moi l'un des avantages majeurs de php, sa documentation.
Clair, concise, qui mets en avant tous les dangers/risques d'erreurs liés à l'utilisation d'une fonction...
Et les commentaires sur le site sont tres souvent utiles, aussi.
[^] # Re: PHP != J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
Car on a une API normalisée.. donc si tu as un pool, il fonctionne indépendament de la base de données utilisée..
avec php, tu es dépendant de la base de données
http://about.me/straumat
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . Évalué à 3.
Qu'en est-il de se que tu fais passer dans cette API ? le SQL n'est standard que sur le papier. En pratique il y a plein de différences suivant les serveurs, même dans les gros connus.
Et pour vous qui parlez de super appli qui ont besoin de super fonctionnalités super avancés, vous avez probablement un code SQL qui est adapté à votre SGBD pour exploiter au mieux les fonctionnalités.
Une API commune c'est très bien, d'ailleurs PHP5 est en train d'évoluer vers ça avec PDO (que j'espère voir dans PHP 5.1) ... mais ça n'est certainement pas suffisant pour disqualifier un langage vu que de toutes façons, sauf si tu te contentes de choses basiques ou de fonctionnalités non optimisées, il te faudra revoir tplus que la simple API quand tu changes de SGBD.
Ceci dit des wrappers qui offrent une API commune à plusieurs BDD, ça existe aussi en PHP (mais tu as la liberté de l'utiliser ou pas)
[^] # Re: PHP != J2EE
Posté par Nelis (site web personnel) . Évalué à 0.
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: PHP != J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
que tu es pas à savoir que pour mysql c'est mysql_connect, pour interbase, c autre chose... à chaque base tu réapprends...
De plus, des outils comme hibernate te permette de développer avec beaucoup moins de SQL ( juste pour accéder aux données suivant des critères ) et de façon indépendante de la BDD
http://about.me/straumat
[^] # Re: PHP != J2EE
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 1.
Par contre il est illusoire de dire que tu peux changer comme ca de base car chacune a ses particularités (MySQL a une propriété auto_incremente que n'a pas postgresql par exemple, il faut utiliser des séquences). Donc soit on se restreint a un jeu SQL réduit pour que ca fonctionne partout soit cela implique des modifications.
Ceci dit utiliser une classe d'abstraction est un plus pour faciliter une éventuelle migration.
Dans le temps j'ai travaillé pour une société de sécurité qui est passé de Oracle vers PostgreSQL. Ils avaient utilisé une classe d'abstraction aussi cela nous a prit une apres midi pour faire le changement (tests inclus).
[^] # Re: PHP != J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
ET CA MARCHE :)
http://about.me/straumat
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . Évalué à 2.
Bref, ça existe aussi
[^] # Re: PHP != J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
J'aimerais pouvoir écrire en php des trucs du style
maCommande.ajouterArticle(monArticle) :)
Sans avoir à faire de sql
http://about.me/straumat
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . Évalué à 2.
Pour utiliser des objets abstraits sans SQL tu as je crois au moins une classe dans PEAR. Dans le framework que j'utilise on commence développer ce genre d'outil. Il y en a d'autres qui ont mené cette politique depuis le début et qui sont amha assez avancé pour que tu n'ai pas trop de critiques.
Ce que tu cherches est probablement http://pear.php.net/package/DB_DataObject(...) (ce n'est certainement pas l'implémentation la plus avancée mais comme c'est du PEAR, c'est probablement celle qui sera la plus mature à terme)
[^] # Re: PHP != J2EE
Posté par hex . Évalué à 1.
http://www.binarycloud.com/index.php/Storage/EntityDefinitionFormat(...)
[^] # Re: PHP != J2EE
Posté par Éric (site web personnel) . Évalué à 4.
> de gérer des pools de connexions vers des bases de données?
> Parce qu'en standard, c'est un process http = une connexion
Un process apache = une connexion. Par contre PHP sait garder la connexion activée dans le process apache quand le script se termine. Et apache gère très bien son pool de processus HTTP ...
L'un dans l'autre la fonctionnalité est bien présente (même si moins élégante).
Sinon les middleware qui permettent de gérer des pool de connexion sont légion, si tu es capable d'installer un serveur d'app Java tu es capable d'installer un petit middleware qui va gérer ça indépendament très très bien.
> Autre question sur PHP: peut-on faire des redirections "internes",
> c'est à dire qu'on arrive sur un premier PHP et on est ensuite
> rediriger vers d'autres PHP en fonction de différents paramètres.
if ($param == 2) {
include('autre.fichier.php') ;
}
[^] # Re: PHP != J2EE
Posté par Gabriel . Évalué à 3.
Sur quels système peut-on faire touner php?
par ex, Je sais qu'on peut faire tourner php sur as400 - et ainsi faire des appels système. Est-ce que quelqu'un a déjà essayé php sur as400?
[^] # Re: PHP != J2EE
Posté par Pooly (site web personnel) . Évalué à 0.
pourquoi pas J2ee sur mon 386 tant qu'on y est.
[^] # Re: PHP != J2EE
Posté par Gabriel . Évalué à 1.
Et puis php sur as400 pour générer du html c'est aussi bête que j2ee sur as400 pour générer du html, à la fin l'utilisateur est content ou pas content, point.
Enfin, si tu veux du vrai n'importe quoi il y a atari web server, et pourtant ça marche. http://kl.net/atari/(...) (enfin ça a marché longtemps, maintenant je ne sais plus)
[^] # Re: PHP != J2EE
Posté par nooky59 . Évalué à 2.
mdr !!! ;o)
Mais sérieusement, si ma mémoire est bonne, Linux doit pouvoir tourner sur AS400 et peux être même un BSD.
me combat surtout que des solutions intérréssantes existe déjà.
à suivre
Donc PHP sous AS400 n'est pas une utopie.
Par contre de réels appels systèmes directement... Je ne sais déjà pas si c'est possible en PHP. Ca passe éventuellement par un module PHP effectué en C.
# Contradiction dans les dires
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 1.
C'est interessant parceque si on regarde les faits c'est vrai que c'est bien pour ce type d'applications mais que sur les plus gros sites en terme de volumétrie c'est du PHP qui est utilisé et ce depuis plusieurs années. ( source : livre blanc afup ainsi que le livre blanc de la société globalis).
Je ne conclue pas je vous laisse ce soin ;)
[^] # Re: Contradiction dans les dires
Posté par Pierre Tramonson . Évalué à 1.
Je veux réaliser une application de salle de marché, je la fais en PHP ?
Je veux avoir une chaîne de traitement batchs gros volume, c'est PHP qu'il me faut ?
Je veux une application client lourd, tiens si je la faisais en PHP ?
Mais je veux bien les URL où consulter tes sources.
[^] # Re: Contradiction dans les dires
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 2.
A chaque problématique sa solution.
Voici les liens :
- http://www.afup.org/docs/wp.pdf(...)
- http://www.phpindex.com/download/PHPEnFrance_V2.0.pdf(...)
Le premier reprend le tableau visible ici (http://afup.org/article.php3?id_article=2(...)).
Le second est parfois un peu indigèste mais il offre des comparaisons temporelles interessantes. L'analyse des plus gros sites en terme de volumétrie se base sur une autre methode que je juge un peu moins pertinente (car les sites audités sont forcément clients) mais ca a l'interet de donner +/- les mêmes résultats que l'analyse de l'association francaise des utilisateurs de PHP.
[^] # Re: Contradiction dans les dires
Posté par Pierre Tramonson . Évalué à 2.
Bon en fait ce que je voulais dire, c'est que lorsque je cherche une solution technique qui présente à la fois un aspect web (site internet ou intranet) et toute l'intégration de ce site dans un SI (alimentation batchs, interfaces avec d'autres applications, outils d'admin, appels RMI/CORBA, connexions EAI...), je pense plutôt à J2EE en premier, puis .NET puis PHP, malgré toutes mes affinités à utiliser PHP :)
Bien sur PHP est très adapté à la réalisation de sites (frontend et backend), mais lorsqu'on cherche à proposer une solution "globale" (même si le terme est un peu pompeux), au moins pour une application de taille respectable, je ne crois pas que PHP permette de faire tout ce que font les deux autres mastodontes ci-dessus.
Mais je pense que PHP peut tirer son épingle du jeu en multipliant l'interopérabilité avec les plateformes J2EE / .NET et les outils les plus utilisés en entreprise.
[^] # Re: Contradiction dans les dires
Posté par hex . Évalué à 1.
Pour un client windows, je citerais winbinder. En gros tu fais tes écrans avec n'importe quel éditeur de boîtes de dialogue (format .rc), winbinder intercepte les messages envoyés aux contrôles, et appellle ton code php.
C'est du pre-alpha certes, mais ca marche, et c'est moins lourd que php-gtk (moins portable aussi puisque windows only).
http://winbinder.sourceforge.net/(...)
[^] # Re: Contradiction dans les dires
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
Un développeur qui va choisir les bons patterns, développer des solutions évolutives, choisir des technos novatrices... c'est pas donné :)
--
Co Auteur du futur livre JOnAS live
http://www.sourcebeat.com/TitleAction.do?id=9(...)
http://about.me/straumat
[^] # Re: Contradiction dans les dires
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 1.
Alors qu'en fait PHP est extremement complet et le maitriser pleinement demande ... beaucoup de temps.
Bien développer demande une certaine rigueur que n'ont pas tous les développeurs.
[^] # Re: Contradiction dans les dires
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Contradiction dans les dires
Posté par crusher . Évalué à 3.
Comparer un langage de page web avec un ensemble de spécifications qui comprend notamment un serveur d'application, un serveur MoM (JMS), et où la partie web n'est qu'une facette est un peu une gageure.
Cela m'étonne un peu venant de ta boite qui se dit partenaire de ObjectWeb sur JONAS...
[^] # Re: Contradiction dans les dires
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Mais PHP et J2EE ont le même but " permettre de résoudre des problèmes " et dans la problématique évoquée ' développement de sites web ", PHP et J2EE sont en concurrence !!!
Il est donc important de comparer les deux choses...
Et si tu relis bien mes postes, tu verras que j'ai déja expliqué les JMS, JDBC... bref, l'utilité d'avoir des specs.
Et oui, nous preferons de loin J2EE, nous contribuons à JOnAS, je modère la ml francophone et j'écris même un bouquin dessus :
http://www.sourcebeat.com/TitleAction.do?id=9(...)
Il ne faut pas refuser les comparaisons, il faut discuter avec les gens.
http://about.me/straumat
[^] # Re: Contradiction dans les dires
Posté par Gabriel . Évalué à 5.
C'est quoi le titre de la news déjà?... "php 5 futur concurrent de j2ee et .net ?" .
Sérieusement, quand leMonde.fr, yahoo et beaucoup d'autres choisissent php, quand on voit la croissance de ce langage/de cette plateforme, avec son modèle de diffusion propre, il y a de quoi se poser des questions sur les frontières entre ces différents langages.
D'où il ressort - cf plus haut - que php manque peut-être de certaines fonctionnalités, mais pour être plus précis, php ne les a pas en standard et celui qui utilise php doit faire un effort pour aller chercher, qui une API pour les logs, qui une api pour les messsages asynchrones, etc. D'où il ressort que tu peux faire du php crade mais que c'est beaucoup plus difficile pour le java. Et que tu peux faire du php avec plein de fonctionnalités mais c'est plus compliqué que php.
Un point aussi qu'on n'a pas soulevé, les briques sont en général plus évoluées en php qu'en java et ont des communautés plus importantes. Entre phpNuke (ou postNuke, ou ...) et la version jboss Nukes, tu trouveras plus d'activités du côté php. Idem avec les wiki, les forums... (Avec les boutiques c'est plus compliqué.)
Et en général, les fonctionnalités développés, inventées seront plutôt côté php. Donc pour un intranet ou un site de news - petite moyenne ou grande dimension, php peut être le choix évident.
Bref, plus de potentiel dans le code côté j2ee, plus de potentiel dans les fonctionnalités côté php?
[^] # Re: Contradiction dans les dires
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
pour les wiki, on ale magnifique xwiki et jspwiki.. on a aussi de très bon projet qui sont plus avancé que php ...
http://www.laszlosystems.com/demos/(...)
http://jakarta.apache.org/lucene/docs/index.html(...)
http://www.infoglue.org/(...)
...
voila :)
http://about.me/straumat
[^] # Re: Contradiction dans les dires
Posté par Gabriel . Évalué à 3.
Lazlo, open source depuis 10 jours, non?
infoglue : je ne connaissais pas mais ça m'intéresse à fond! Une appli utilisée par des danois et des néerlandais (http://www.infoglue.org/infoglueDeliverLive/ViewPage.action?siteNod(...)) ne peut être que bonne. cf. typo3
(oui j'ai des critères assez bizarres!)
Je veux dire plus simplement qu'un langage c'est aussi une culture : celle de java, ce sont des design patterns , des librairies, des implémentations, des architectures. Celle de php c'est des fonctionnalités, des inventions venues de l'utilisateur plus que du codeur. Et dans les deux communautés on ne parle pas des mêmes choses.
Ce n'est pas une règle absolue, tu trouveras aussi des bons cms ou des wiki (à la jspwiki) ou des blogs en open source java. Mais la communauté est en général plus petite.
C'est promis j'arrête de troller et je retourne bosser un peu, j'ai une la mise en ligne vendredi ;-)
[^] # Re: Contradiction dans les dires
Posté par Gabriel . Évalué à 2.
http://www.phppatterns.com/(...)
Le site de Harry Fuecks où il a regroupé une série d'étude sur l'implémentation des design patterns en php.
où j'avais vu à l'époque par exemple la difficulté à implémenter le singleton.
Qu'en est-il mantenant avec php5?
[^] # Re: Contradiction dans les dires
Posté par Éric (site web personnel) . Évalué à 2.
Le problème en question est réglé (c'est grosso modo *la* plus grosse amélioration de PHP5). On a des méthodes statiques, des attributs statiques, les objets sont bien des références ... implémenter un singleton en PHP5 c'est 10 lignes de code :
class monSingleton {
static $instance ;
static function getInstance() {
if (!isset(self::$instance)) {
self::$instance = new monSingleton ;
}
return self::$instance ;
}
}
$objSingleton = monSingleton::getInstance() ;
[^] # Re: Contradiction dans les dires
Posté par Nelis (site web personnel) . Évalué à 2.
Je vous dire, si deux threads arrivent en même temps dans le getInstance(), comment faire pour que l'instance ne s'initialise pas deux fois ?
[^] # Re: Contradiction dans les dires
Posté par Éric (site web personnel) . Évalué à 2.
C'est vrai que j'aurai du préciser.
Si tu veux faire un singleton global, il faudra stoquer/lire tous ses attributs en base de données (tu auras plusieurs instances mais quand tu utilises les attributs, tu utilises la bases de données (qui elle est globale).
[^] # Re: Contradiction dans les dires
Posté par Nelis (site web personnel) . Évalué à 3.
Quel est l'intérêt d'un singleton s'il est au niveau de la requête (càd un thread) ? Pourquoi ne pas simplement créer une instance locale de la classe ?
[^] # Re: Contradiction dans les dires
Posté par Éric (site web personnel) . Évalué à 3.
En fait des développeurs pas cher il y en a plein, le problème c'est qu'en PHP comme tu as la possibilité de faire n'importe quoi ... beaucoup le font. Si tu veux quelque chose de correct il faudra *chercher* le développeur correct.
Et ça pas de secret, le bon développeur, qu'il fasse du java ou du php, son prix n'est pas si différent. (même si ça reste probablement un peu plus faible sur PHP parce qu'il a de la concurrence)
[^] # Re: Contradiction dans les dires
Posté par Cali_Mero . Évalué à 2.
Tout dépend la qualité du travail désirée... Tous les développeurs PHP ne se valent pas, loin s'en faut.
Merci de ne pas mettre tous les développeurs php dans la case "développeurs au rabais". Tu te tromperais lourdement...
Mais en effet, "un développeur php c'est facile et c'est pas cher" c'est une pensée qui fait son chemin dans l'esprit des décideurs. Ca les arrange bien d'ailleurs, ca leur permet de brader les compétences...
Un développeur qui va choisir les bons patterns, développer des solutions évolutives, choisir des technos novatrices... c'est pas donné :)
Tout à fait d'accord ici. Seulement, contrairement à ce que tu sembles suggérer, ce type de développeur n'est pas spécifique au monde java.
les bons patterns : http://www.phppatterns.com/(...)
les technos novatrices : php étant essentiellement un langage de glu, il est fréquent de devoir le faire cohabiter/communiquer avec différents supports/plate-formes parfois exotiques. Et les solutions ne manquent pas...
Et effectivement, cette compétence fait la différence à l'entretien et dans la pratique.
[^] # Re: Contradiction dans les dires
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Je dirais qu'il est plus facile de dévelopepr en php qu'en java et que donc, il y a plus de monde qui fait du PHP...la loi de l'offre et de la demande fait le reste !
mais l'aspect facile du PHP est un atout et je ne pense pas, je le repete, que les développeurs PHP sont de mauvais déevloppeurs
http://about.me/straumat
# Une question pour un non expert J2EE
Posté par elamapi . Évalué à 1.
Je connais trés bien PHP, ses subtilités ses forces et ses faiblesses (quelques années de dev dessus :) ).
Je dois donc avouer que je reste perplexe.
Apparement beaucoup d'entre vous trouve que PHP5 ne pourrait pas concurencer les plateformes J2EE.
A mon avis, il faudrait d'jà dire, PHP5 + APACHE + mysql/postgres/oracle pourrait concurencer les plateformes J2EE.
Ensuite, qui a t il y a de plus entre une application J2EE (au niveau technique) qu'un application developpée sur une plateforme PHP ne puisse faire.
Toujours a mon avis, rien, on peu arriver au meme resultat avec les deux.
Pourquoi ? parcequ'il ne s'agit que d'une question de norme. J2EE est "plus" normalisé que PHP , oui probablement. mais ca ne fait pas tout.
Un chef de projet conciencieux avec une bonne equipe de dev en PHP fera aussi bien si ce n'est mieu qu'une equipe de codeurs porcasse qui suit une norme.
Quand à l'interopérabilité, la notion d'objet distrubués, la notions d'objets,la montée en charge ....PHP (même la version 4) s'en sort TRES bien.
J'ai par contre une question, pourquoi reste t il facile , trés facile, d'ecrire quelque ligne de code pour faire une application en PHP alors que ca devient immédiatement monstrueux en J2EE ?
Et puisqu'on parle de normalisation, pourquoi est il facile (tres facile meme) d'installer une plateforme PHP sur n'importe quelle archi (celles que j'ai testé son WIn32/Linux/Free/Net/Open/Bsd/Sun) alors que ca releve de l'exploit de faire la meme chose avec les plateforme J2EE ?
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Maintenant, à mon avis, en suivant la norme J2EE, on peut obtenir facilement :
- Indépendance du support de stockage
- Gestion des montées en charge ( JMS & autres )
- Séparation claire suivant le modèle MVC
- possibilité d'exporter la logique métier pour qu'elle soit accessible par des application lourdes ou webservices
- facilité de mise en cluster
- test unitaires
- fichiers de configurations génériques pour le déploiement
- ...
Et beaucoup de choses ne seront pas à développer comme la sécurité, les meta frames, les filtres....
On peut obtenir certaines de ces choses avec PHP en utilisant des classes de différents endroits... mais avec J2EE, tout est fourni et normalisé, il ne reste plus qu'à choisir ton implementation ( Objectweb de préférences ;) )
Autre chose... J2EE ne s'installe pas sur un "système d'exploitation"... il est fait pour tourner sur une JVM..
Et il est très facile d'installer une implémentation de J2EE comme JONAS sur une JVM... en fait, tu détar ton archive, une variable d'environnement et c'est bon ! c'est plus facile que le trio apache php mysql :)
http://about.me/straumat
[^] # Re: Une question pour un non expert J2EE
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à 1.
En PHP 4 c'etait experimental mais avec PHP 5 c'est en cours de réalisation grace a une coopération de Sun, Zend et qq autres boites.
Bref on va finir par être tous des potes ? ;)
Sur ce thème je retrouve pas tous mes liens mais sachez que Zeev suraski, l'un des créateurs de PHP, va venir en causer au forum (http://www.afup.org/forumphp2004/sessions.php(...)).
++
[^] # Re: Une question pour un non expert J2EE
Posté par Éric (site web personnel) . Évalué à 2.
Pareil, en PHP tu peux poser tes fichiers PHP et utiliser direct. Il faut juste poser les binaires avant ;). Je ne dis pas que c'est pareil à la seconde près, mais en pratique c'est kifkif.
Du coté compatibilité des architectures et des systèmes, PHP n'a pas à rougir de Java tu sais. Je ne crois pas qu'on puisse vraiment faire un choix ou l'autre là dessus.
[^] # Re: Une question pour un non expert J2EE
Posté par elamapi . Évalué à 1.
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 0.
http://about.me/straumat
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Brunner . Évalué à 1.
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Une question pour un non expert J2EE
Posté par elamapi . Évalué à 0.
Apres l'install mon constat.
Ca rame grave , tout mon serveur rame, toute sa memoire est bouffé par java. Je suppose que c'est super puissant pour de supers applications sur de supers serveurs quadri xeons 2To de ram mais pour 98% des applications clients/serveurs que je connais, je vais rester sur php/apache/mysql
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Une question pour un non expert J2EE
Posté par elamapi . Évalué à -2.
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Tu abuses... tu as une base de données, des pools de connexions, un serveur web, les webservices, une interafce d'admin, des connecteurs, des files d'attentes...
http://about.me/straumat
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Brunner . Évalué à 0.
[^] # Re: Une question pour un non expert J2EE
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: Une question pour un non expert J2EE
Posté par hex . Évalué à 1.
Mais pourquoi dire cà ?
On peut très bien faire des web services en PHP. J'utilise NuSOAP et ca fonctionne très bien, je n'ai jusqu'à présent rencontré aucun problème d'inter-opérabilité (tests en mode rpc avec des clients VB6, .Net et Java).
http://sourceforge.net/projects/nusoap/(...)
Bref, personne ici ne remet en cause la puissance des plateformes J2EE ou .Net, mais PHP a lui aussi sa place en entreprise; ce n'est plus un langage jouet.
[^] # Re: Une question pour un non expert J2EE
Posté par Éric (site web personnel) . Évalué à 2.
D'où vient cette affirmation ?
Il y a une très bonne extension SOAP pour PHP5 que même un débutant pourrait utiliser. Il y a du SOAP et du XML-RPC depuis pas mal de temps en PHP4. Il n'y a franchement aucune raison d'exclure PHP pour faire du Web Service.
Le Web service c'est un grand nom pour la possibilité d'envoyer et recevoir des messages XML. Ce n'est pas tellement différent de ce que tu appelles "web dynamique". La seule différence réelle c'est la manière dont tu récupères la requête et lamanière dont tu formattes la réponse. A vrai dire le Web Service est un concept tellement simple que ça peut bien être codé dans n'importe quoi qui sait lire/écrire du XML.
[^] # Re: Une question pour un non expert J2EE
Posté par TImaniac (site web personnel) . Évalué à 2.
J'ai pas dit qu'on pouvait pas faire de web services en PHP.
J'ai dis que c'était pas fait pour. Nuance.
Ce que j'entend par là c'est que dans la pratique on peut effectivement faire de la communication SOAP avec à peu près n'importe quoi, et donc implémenter entre autre le protocole des Web Services tranquillement en PHP, je n'en doute absolument pas.
Ce que je veux dire c'est qu'un web services non trivial se contente rarement de renvoyer une bête réponse à l'utilisateur, et fait parfois (souvent ?) appel à une solution qui n'a absolument aucune intérêt à être implémenté en PHP par rapport à Java ou autre. C'est en ça que je dis que les Web Services en PHP voilà quoi. On peut mais c'est pas fait pour, et c'est surtout beaucoup plus confortable sur d'autres plateformes.
"PHP a d'ores et déjà gagné ses galons en matières d'applications Web, PHP 5 devrait être l'occasion de voir PHP gagner l'univers des Web services et des middleware applicatifs pour le moment chasse gardée de Java."
(tiré de l'interview)
Y'a un gros conditionnel dans la phrase, et les Web Services sans middleware applicatifs comme il dit, ben voilà quoi.
J'espère m'être mieux fait comprendre, je me rend moi même compte que mon post n'était pas clair.
[^] # Re: Une question pour un non expert J2EE
Posté par Gabriel . Évalué à 2.
De plus Si tu as - par exemple - un site de e-commerce qui génère des commandes, ce site peut être en php (jusqu'ici tout va bien? ;-) excuse moi je suis moqueur aujourd'hui parce qu'aujourd'hui le site dont je me suis occupé pendant longtemps - avec succès pour eux faut avouer - passe d'un websphere (sans ejb) intégré au back office à un commerce server 2000 détaché du back office donc...)
Et s'il génère des commandes, elles peuvent être réceptionnées par un serveur avec du php, ou du vb.net, ou du c compilé à la volée, xml-on-demand, ou de l'asp... (on me souffle dans l'oreilllette: non, pas de l'asp) Puis traitées en auto, par ce qu'on veut derrière, sap, solution maison...
Bref, php peut être aussi serveur de services webs si derrière la machine tourne. Mais, on est d'accord, php n'est toujours pas dans le moteur.
[^] # Re: Une question pour un non expert J2EE
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
# Who knows?
Posté par _p4_ . Évalué à 0.
Il apparait que le doute prévaut globalement quant à savoir si un environnement de type LAMP peut concurrencer J2EE sur des créneaux applicatifs importants en termes de complexité industrielle.
On pourrait voir python entre les deux: bon pour le web et aussi pour les applis classiques. Plus tempéré dans ce dileme, python n'est encore excellent ni dans l'un ni dans l'autre en temps qu'environnement de déploiement. Mais l'avantage c'est qu'il est bon dans les deux: plus puissant et homogène que le php, moins lourd que le java. Perso j'y crois plus qu'en java ou en php.
# Lequipe.fr
Posté par _alex . Évalué à 2.
un fond de linux , de sybase, puis un mélange d'xml et de java assaisoné au jboss, et pour finir du php.
# avis apres test de jboss
Posté par elamapi . Évalué à 0.
Cependant, il rest toujours plus complexe à integrer qu'un apache+php généralement préinstallé (ou facilement installable via apt,yum ou autre) a linux (il en va de meme pour windows avec easyphp msas ou autre).
Une fois l'installation faite, j'ai pu tester des petites choses (sur les deux environements).
- application basique (hello world).
- Petites applications client/serveur (chat, client irc, petit jeux réseau).
- liaison avec base de données (postgres/mysql/oracle 8i)
- test XMLRPC
plus quelques autres tests.
Mes impressions:
Si on reste avec un navigateur web coté client (pas d'applet java/pas de flash ou autre, juste des page web avec du javascript/vbscript/script) : On peut faire EXACTEMENT la meme chose avec une plateforme J2EE et PHP (sauf que globalement c'est plus simple a mettre en oeuvre en php).
La ou j'ai constaté un "petit" avantage à J2EE c'est si on crée une application web avec une applet coté client.
Le on se retrouve avec une jolie application client/serveur en mode connectée. L'interet, avoir des remonté d'info en temp reel ce que ne peut pas faire une page web.
Peut on faire la meme chose en PHP, oui, 2 solution.
La plus simple on utilise du flash (je sais c pas bien ca pu c pas libre) pour un résultat presque identique.
On utilise (comme en j2ee) une applet java qu'on fait communiquer avec du PHP (c'est un peu plus sioux mais ca fonctionne parfaitement).
Maintenant, que ce soit J2EE ou PHP j'ai lu de GROSSES aneries quant à l'indépendance vis à vis du serveur.
dans un cas comme dans j'autre, on reste "relativement" indépendant de la plateforme (mes applications php je les passes de windows à linux a linux4powerpc sans probleme) .
Mais dans un cas comme dans l'autre, on concerve les memes dépendances:
Filesystem: si vous stockez des fichiers sur le filesystem local vous aurez les contraintes dudis filesystem (la solution reste de tout stocker en DB, mais la c'est pareil en J2EE et PHP).
L'affichage d'application cliente avec applet/flash:
Pour avoir testé des applis graphique java/flash sous windows/linux/mac je peux vous jurer que j'avais des différences d'affichage (en particulier avec les police de caracteres), on peut eviter ca mais ca demande une gymnastique de plus.
Maintenant, je reste persuadé que PHP reste performant pour 98% des applications qu'un serveur J2EE.
Le développement d'une application J2EE reste TRES lourde et on peu faire la meme chose en PHP.
La seule chose que je concede (mais qui reste importante) c'est la normalisation: J2EE est plus "conforme" que PHP.
Mais je suis certain qu'une bonne equipe de dev avec un bon chef de projet peuvent se passer de cette "normalisation".
Quand à python, (j'ai lu ca dans un post plus haut) je n'en parle meme pas. Il ne joue pas dans la meme catégorie. Je suppose que l'auteur voulais parler de Zope & Co. Pour moi c'est inutilisable a grande echelle (sans parler des performances et de la difficulter d'integrer des Products généralement lié à des libs externes incompilables plus du fait que les products sont pour la majorité inutilisable d'une version de Zope a l'autre).
[^] # Re: avis apres test de jboss
Posté par zegor . Évalué à 1.
Dans quelle catégorie places-tu Python ?
Personnellement, après avoit fait pas mal de Perl et de PHP, je trouve ce langage vraiment excellent. Perl est très expressif mais peu maintenable et PHP est lent (2 à 3 fois plus lent que Perl et Python d'après mes benchs) et trop laxiste. Python est aussi facile à apprendre que PHP, aussi rapide que Perl, lisible et surtout polyvalent, permettant l'écriture de simples scripts à de grosses appli comme Zope.
Dire que Zope est inutilisable, c'est vraiment méconnaître le produit, qui est utilisé par exemple dans des ministères ou des grosses entreprises comme le CEA, le CNRS, la Nasa, VIACOM à de grandes échelles.
Pour moi, Python est le meilleur compromis entre rigueur et productivité et je pense qu'il sera de plus en plus utilisé en entreprise dans les prochaines années.
[^] # Re: avis apres test de jboss
Posté par elamapi . Évalué à 0.
Donc, premièrement python (le langage) n'est pas 2 à 3 fois plus rapide. en fait le gain de rapidité n'est quasiment pas perceptible.
Ensuite, je persiste, la maintenabilité, la clarté ne viennent pas du langage mais du programmeur.
Pour info, j'ai repris une appli zope d'un developpeur bordelique, j'ai bien cru que j'allais tout refaire tellement je comprenais rien. Mais ca m'est deja arrivé en C,C++,Java,Perl,PHP,Python,Fortran ou autre.
Ensuite, j'insiste, les plateformes Zope (pas le langage cette fois mais Zope), sur une meme machine son plus lentes, et la de tresssssssssss loin, qu'une plateforme apache/php (je ne parle meme pas du cas ou on veut utiliser des horreurs comme psychopg/zpygresql).
Bref, de toute facon le débat n'est pas la. Je parlais de J2EE et de PHP
[^] # Re: avis apres test de jboss
Posté par Philip Marlowe . Évalué à 0.
Ah bon ? Je dirais que ça vient des deux, et qu'un langage favorisant la maintenabilité et la clarté du code aide tous les programmeurs dans ces domaines, même ceux qui ne sont habituellement pas très inquiets de ce genre de choses. Bien sûr je peux me tromper.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.