J'ai trouvé qu'il serait une bonne idée d'en faire profiter la communauté. Je lui ai demandé son accord et voilà ... Petit comparatif JSP/PHP.
-------------------------
- php est un langage procédurale avec possibilité de faire de l'objet
jsp (donc java) est un langage full objet avec tous les avantages que cela
comporte en terme de rapidité de développement + de nombreux IDE
- en terme de système d'information, java possède beaucoup plus d'api que
php pour tous types de connexions à d'autres applicatifs ou protocoles :
cela permet de se greffer plus facilement à tout système d'information :
CICS, MQSeries, SNMP, tivoli, bases de données, corba, RMI, XMLRPC, FTP...
(la liste pourrait faire des pages et des pages)
--> notamment, java permet de faire tourner de réelle applications derrière
le serveur applicatif
- php peut se connecter à toutes les bases de données du marche mais les
interfaces sont propriétaires :
Pour ouvrir une connexion avec mysql : mysql_connect
Pour ouvrir une connexion avec oracle : OCILogon
Java à une interface d'abstraction de connexion au bases : JDBC (Java
Data Base Connectivity)
---> avantage par rapport à php : lorsque l'on change de base de
données, normalement, il n'y a pas besoin de changer le code de
l'application
- Toujours concernant les bases de données : php gère en natif un système de
pooling de connexion, ce système, quoi que relativement performant n'est pas
aussi performant que les systèmes de pool de connexion que l'on peut avoir en
java (plus de possibilité de configuration du pool)
- Les serveurs applicatifs java (respectant les spécifications servlet 2.2)
permettent bcp plus de choses :
meilleure gestion des sessions,
gestion de contexte
meilleure gestion du système de request
- Les serveurs applicatif java peuvent se greffer sur tous les serveurs WEB
du marche, php ne doit (a vérifier) que fonctionner avec Apache et IIS
- les serveurs applicatifs java peuvent fonctionner "in process" ou "out
process" : c'est a dire dans le même processus que le serveur web ou dans un
processus sépare, ce qui permet (dans le cas du out-process) de placer le
serveur web et le serveur applicatif sur des machines différentes : cela
permet d'avoir un système complet N-Tiers qui assure notamment du load
balancing et de la haute disponibilité a tous les niveaux.
PHP ne permet pas cette souplesse d'architecture, car il tourne
"in-process", (je crois que php possède maintenant un module lui permettant
de faire de l'out-process aussi, mais lorsqu'on l'utilise, je crois que
certaines fonctionnalités (par exemple la gestion des sessions) ne
fonctionnent pas
- au niveau du développement de l'application, java permet de manière plus
simple de respecter de design patern MVC (Model View Controler), un grand
nombre de framework de développement existent d'ailleurs pour faciliter et
respecter ce paradigme (voir les framework STRUTS et TURBINE de l'Apache
Software Foundation). Implémenter un MVC en php est pratiquement impossible,
car pas de possibilité de faire du code autrement que des des pages php,
alors que java permet de créer des servlets (Controler), des javaBeans
(Model) et des JSP (View) ce qui confère une grande souplesse de
développement (partages nette des taches et des compétences sur un projet).
- comme son nom l'indique (php = Personnal Home Page) permet le
développement plus rapide de petites applications web, mais en aucun cas de
vrai applications web scalable et fortement connectées. Des lors que le
projet commence a devenir gros, le PHP devient complexe a mettre en oeuvre.
- PHP nécessite un peu moins de ressource qu'un serveur applicatif java. Si
on résonne en revanche en terme de coût : les coûts induit (pour de gros
projet) par des développements php dépasse très rapidement le coût marginal
de la puissance machine nécessaire pour faire tourner la même chose en java.
En terme de rapidité d'exécution, les temps de réponses de JAVA sont
aujourd'hui équivalent a ceux de PHP, même si la ressource machine et
mémoire est supérieur pour JAVA.
- enfin, mais ça a son importance, JAVA est soutenu par un grand nombre de
TRES grand noms de l'informatique : SUN, IBM, ORACLE...
Si j'avais a donner une conclusion :
Pour de petits applicatifs qui n'ont vraiment aucune raison (même a long
terme) d'être connectée au système d'information de l'entreprise le choix
PHP semble s'imposer. Pour le reste, je conseille fortement JAVA...
Remarque : ce qui fait la force de JSP, ce n'est pas JSP lui même, mais
c'est JAVA, dont JSP est un moyen simple de fabriquer des pages HTML.
Car en terme pure, n'utiliser QUE du JSP, JSP tout seul n'a pas grand
avantages par rapport à PHP puisque globalement ils font la même chose :
mettre des lignes de programme dans une page HTML qui sera exécutée par le
serveur.
Bon, je m'arrete la,
Pardon pour les fautes.
Mantha
Aller plus loin
- tomcat (21 clics)
# Java c'est caca
Posté par Anonyme . Évalué à 0.
[^] # Re: Java c'est caca
Posté par Anonyme . Évalué à 0.
[^] # Re: Java c'est caca
Posté par Roger Rabbit . Évalué à 1.
Mais qu'ont tous ces gens contre java ?
[^] # Re: Java c'est caca
Posté par un nain_connu . Évalué à 1.
# PHP que sur Apache et IIS ????
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
[^] # Re: PHP sur IIS
Posté par Chadom (site web personnel) . Évalué à 1.
Il est alors utilisable "in-process" par IIS, et je pense meme qu'il doit etre possible de faire de la repartition de charge a travers MTS.
# Euh ...
Posté par Anonyme . Évalué à 0.
En tout cas j'ai développé en JSP ( pour un client ) ... et si on m'en donne l'occasion j'en referait pas ... de toutes facons je suis un decu de java en general ...
# Oui, mais...
Posté par Ludovic Boisseau . Évalué à 2.
[^] # Re: Oui, mais...
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
Pour revenir sur le MVC, le projet Velocity de Jakarta est bien plus propre que du JSP :
http://jakarta.apache.org/velocity/index.html(...)
sinon, en PHP, je cherche toujour comment utilisé une variable accessible depuis toutes les pages du site.
[^] # Re: Oui, mais...
Posté par Anonyme . Évalué à 0.
voir du coté de la phplib pour ta variable...
... il me semble qu'il y a un truc équivalent
[^] # Re: Oui, mais...
Posté par Yann Bloch . Évalué à 1.
http://xml.apache.org/cocoon2/index.html(...)
[^] # Re: Oui, mais...
Posté par Anonyme . Évalué à -1.
--
Nono
[^] # OTBD ?
Posté par Yann Bloch . Évalué à -1.
[^] # Re: OTBD ?
Posté par Anonyme . Évalué à -1.
Nono dit Corbier a la moustache
[^] # Cocoon 1 et 2
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
Par contre le 2 semble prometeur, mais j'arrive pas à l'installer. Je voudrais pas dire de connerie, mais il me semble que l'on peut utiliser du PHP pour generer le XML (qui sera ensuite mouliner avec un XSL par Cocoon 2)
[^] # Re: Cocoon 1 et 2
Posté par Nico . Évalué à 1.
[^] # Re: Cocoon 1 et 2
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
Si, avec Sablotron. Mais c'est plus complexe, avec Sablotron, tu concatene tout ton XML (ou tu utilises une fonction ou un objet) et tu le passes comme argument dans la moulinette Sablotron, ta page risque de contenir que du code. Avec la bidouille Cocoon2, ta page PHP genere du XML comme elle aurait geré du HTML, et c'est cocoon qui s'occupe du reste. Cocoon a besoin de data (le XML) et d'une feuille de style (le XSL), les datas peuvent etre dynamique et provenir de l'exterieur.
[^] # Re: Cocoon 1 et 2
Posté par Nico . Évalué à 1.
[^] # Re: Cocoon 1 et 2
Posté par Anonyme . Évalué à 0.
envoie à cocoon. Jusqu'à présent, ce handler
n'était pas chainé sur les résultats ...
en gros tu produis avec un script php du XML
et il te l'envoie sur ton navigateur. Maintenant,
tu repasses par le handler d'apache quelque soit
le type de données produites, donc si tu produis un fichier xml qui contient une feuille de style
cocoon2 applique cette feuille de style.
Théoriquement dans cocoon2, tant que tu produiras
des fichiers contenant une feuille xsl, tu pourras l'appliquer... ce qui moins lourd que dans cocoon 1 ou tu es obligé d'ajouter des ordres pour que cocoon1 réappliques ces feuilles de style en dynamique.
[^] # Re: Oui, mais...
Posté par Anonyme . Évalué à 0.
Notamment sur les db avec de nombreuses entrées.
sur un PII 300 j'ai du tricher sur les transformations XSL
[^] # Re: Oui, mais...
Posté par Anonyme . Évalué à 0.
une erreur 500 avec la stacktrace, il suffit de regarder le code généré et tu trouves la ligne
qui fait planter.
J'ai fait du JSP/servlet et je n'ai jamais eu de problème de debugging.
le tout est de savoir ce que l'on cherche et où on doit le chercher
NioTo
[^] # Re: Oui, mais...
Posté par gwenn cumunel (site web personnel) . Évalué à 1.
(hop -1)
[^] # Re: Oui, mais...
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
Les sessions sont propres à un utilisateur. C'est une variable disponible par tous les utilisateurs que je cherche. En java, c'est une variable "static", en ColdFusion une variable "application", ya pas d'equivalent en PHP?
[^] # Re: Oui, mais...
Posté par Étienne . Évalué à 1.
Et bien tu fait comme en Java, tu écrit une classe (au hasard Config, cf daCode) qui contient les différentes variables que tu veux partager et tu l'utilise dans toutes les autres classes.
[^] # Re: Oui, mais...
Posté par Anonyme . Évalué à 0.
[^] # Re: Oui, mais...
Posté par woof . Évalué à 1.
Sinon maintenant y'a aussi les session, mais j'y ai jamais touché encore .. (php4).
Vala, a+
--
moi
[^] # Re: Oui, mais...
Posté par Anonyme . Évalué à 0.
[^] # Euh le debugger ca existe ;-)
Posté par Anonyme . Évalué à 0.
Comme quoi un debugger ca sert à qqch !
Aller un dernier tips pour la route :
rajouter -classic dans les parametres de la VM lancé au moment du debug ca booste la vitesse du debug ... la raison : J2SE est livré avec Hotspot Client qui n'est pas prevu pour passer en mode debug :(
2 solutions :
- mettre le Hotspot Server
- passer en JIT classique (symantec) : la fameuse option -classic
Enfin, pour casser le troll qui pointe son nez :
- Oui, en perf brute PHP est plus rapide !
- Oui, en moté en charge JSP est plus performant !
- Oui, PHP est plus simple a mettre en place pour des choses simples !
- Oui, JSP est plus simple a utiliser dans les gros projets et à réutiliser.
En resumer : Les deux technos sont biens ....
Bien sur pour ceux qui connaissent les JSP il n'y a pas trop d'interet à passer à JSP ... pour ceux qui maitrisent PHP, le seul interet à passer à JSP est l'utilisation/le besion de : multiples Taglibs, nombreuses API couvrant tout les besoins possibles et imaginables, charges de folies ...
Mon seul reproche pour PHP, est que l'on doit retourner à l'ecole et se mettre à reapprendre une flopé des methodes ... :(
Ah si seulement tout etait fait en objet sous PHP ...
Pour finir : Mieux vaut faire du PHP que de l'ASP !
3hck'.
[^] # Re: Oui, mais...
Posté par loopkin . Évalué à 1.
D'ailleurs le vrai "concurrent" de PHP, c'est pas le JSP, c'est EmbPerl / mod_perl (ou perlIS pour les inconditionnels de MaxiSaloperie).
Enfin, Java est un vrai plus c'est sur, mais je ne suis pas forcément convaincu par le JSP direct non plus, ça n'apporte pas grand chose, et si on veut respecter le MVC, il faut quand meme pas mal bosser dessus. Essayez Enhydra....
[^] # Re: Oui, mais...
Posté par Vincent Ferrari . Évalué à 1.
# moui...
Posté par sToR_K . Évalué à 1.
C'est assez objectif tout de meme pour un
article ecrit par developpeur java (parceque ca ce voit qd meme :)
Mais il manque le plus important: un des 2 est en open-source..
[^] # Re: moui...
Posté par Anonyme . Évalué à 0.
# 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme . Évalué à 0.
gaz... une sorte d'ASP a la sauce SUN , dans ce
style je prefere la simplicite de PHP...
je conseilerai a ceux qui veulent un site en
java de faire des CGI en java, en plus on peut
ecrire des programmes (bytecode) java avec
d'autres langages (moins lourdingues) comme
python (tout en gardant l'acces aux api java)
http://www.jython.org/(...)
ah que ca c'est vraiement cool ...
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (site web personnel) . Évalué à 1.
Qu'appelles-tu installer JSP ? On n'installe pas JSP mais un serveur d'application supportant JSP/Servlet ...
et c'est une vraie usine a gaz... une sorte d'ASP a la sauce SUN
Même remarque ... Quel serveur as-tu installé ? Il y en a qui sont lourds, d'autres légers, ... Installe Weblogic pour faire tourner ton petit site web perso, ça va etre super lourd, pourtant pour faire tourner une grosse application J2EE, c'est au poil ...
dans ce style je prefere la simplicite de PHP...
Pour tes besoins a toi peut-être ... Mais pour une application plus grosse qui doit se connecter a d'autres systèmes ou exécuter des taches plus complexes, on préfèrera la richesse de Java ...
Tout est une question de besoins ...
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo . Évalué à 1.
Concernant l'article lui même :
- Comme cela a été dis, le debuggage des JSP est une catastrophe (Internal server error avec un numéro de ligne qui ne correspond pas à qq chose dans la page JSP) ;
- Le principe de fonctionnement des JSP est un millefeuilles : les jsp sont traduits en servlet (une classe java qui enverra sur "stdout" ce qui doit être envoyé au navigateur), le code java de cette servlet est alors compilé en bytecode java qui va être chargé par le moteur de servlet et exécuté.
- « ce qui fait la force de JSP, ce n'est pas JSP lui même, mais c'est JAVA », j'ajouterais que c'est aussi sa faiblesse on notera en particulier la difficulté pour s'interfacer avec des bibliothèques "natives" (c'est possible mais il faut un compilateur C pour faire le stub) ; la lourdeur du JRE (trois ou quatre objets un instancier pour lire un fichier ligne à ligne) et ses manques (impossible de locker un fichier en pure java) ;
- concernant l'interfaçage, PHP est nettement plus souple puisqu'écrit en C on notera que PHP s'interface avec COM sous Windows ou même Java ;
- dans la version "out of process" de JSP/Servlet on notera qu'un plantage du moteur de Servlets (core ou Docteur Watson) bloque tout le site alors qu'un plantage identique en PHP ne bloquera que la requête en cours.
Mis à part ces "oublis" l'article est intéressant.
De toute façon mod_perl rewlz ;-).
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (site web personnel) . Évalué à 1.
Je suis tout à fait d'accord, c'est de cela que je parlais ... Weblogic utilise son propre moteur JSP/Servlet, Orion aussi, ...
Simplement il en existe forcément de mieux fait que d'autres ...
Comme cela a été dis, le debuggage des JSP est une catastrophe (Internal server error avec un numéro de ligne qui ne correspond pas à qq chose dans la page JSP)
La plupart des engines vont te donner : L'exception et le message associé, la stack trace complète, le numéro de la ligne DU JSP ou l'erreur s'est produite, ...
Donc le debuging n'est ABSOLUMENT pas une catastrophe, et je sais ce que j'avance, je le fais tous les jours :-)
Le principe de fonctionnement des JSP est un millefeuilles : les jsp sont traduits en servlet (une classe java qui enverra sur "stdout" ce qui doit être envoyé au navigateur), le code java de cette servlet est alors compilé en bytecode java qui va être chargé par le moteur de servlet et exécuté.
Effectivement cela se passe ainsi : lors d'une requete vers un JSP, l'engine regarde si le JSP a deja été compilé. Si oui, il l'execute, si non, il génère le servlet, le compile, puis l'exécute. Une fois que le JSP a été compilé, il ne devra plus l'etre. De plus, tout ça est 100% transparant pour le développeur.
particulier la difficulté pour s'interfacer avec des bibliothèques "natives"
Java est justement réputé pour s'interfacer avec un peu tout et n'importe quoi sans trop de problèmes ... Et ça se vérifie dans la pratique ! J'ai récemment du faire l'interfacage entre des bibliothèques C++ d'un logiciel de mathématique et du code Java, ça s'est passé sans problèmes !! J'ai du compiler du C ? Et alors ? Je ne vois pas le problème :-)
dans la version "out of process" de JSP/Servlet on notera qu'un plantage du moteur de Servlets (core ou Docteur Watson) bloque tout le site alors qu'un plantage identique en PHP ne bloquera que la requête en cours
Possible... Je ne sais pas ... Aucuns des Servlet engine que j'ai utilisé n'ont encore planté ainsi ;-)
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme . Évalué à 0.
Arrêtes nelis! Tu ne savais pas que Sun avait créé les sites web qui plantent comme les applis?
Ne fais pas l'innocent!
De toute façon, java est accessible depuis php donc php aussi s'interface avec tout et n'importe quoi!
Sans rancune, nelis ;)
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (site web personnel) . Évalué à 1.
Je n'ai jamais dis que PHP c'était pas bien ou lent ou pas puissant ou quoi que ce soit ! J'ai dit, je connais pas PHP mais je vais y jeter un oeil car ça a l'air intéressant. Personnellement l'utilise Java, j'adore cette plateforme, mais ce n'est pas pour ça que je dis que tout le monde doit l'utiliser, je peux très bien comprendre que des gens n'utilisent pas Java car ils ne l'appécient pas ou qu'ils ne réponds pas a leurs besoins... Ce que je ne supporte pas, c'est que des gens qui critiquent qqchose qu'ils ne connaissent pas... (je ne dis pas ça pour toi, ms en regle générale)
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme . Évalué à 0.
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo . Évalué à 1.
Je veux bien le nom des moteurs car avec Tomcat 3.2.1 j'ai le numéro de ligne de la servlet, rien de plus.
Oui c'est assez vrai sauf dans un cas particulier. Sur un filesystem qui ne fait pas la différence en tre majuscules et minuscules (NTFS pour ne pas le nommer) on peut s'amuser à appeler d'abord http://azerty/qwerty.jsp(...) puis http://azerty/QwErTy.jsp.(...) Avec Tomcat on se retrouve avec une erreur 500 pour ClassNotFoundException. C'est con mais Tomcat recherche le fichier QwErTy.class, le trouve car le FS ne fait pas la différence avec qwerty.class. Lorsqu'il essaye d'instancier la classe QwErTy et bien il n'y arrive pas puisque la classe dans le fichier est "qwerty" :-(.
Bah moi j'en vois un. Lorsque tu es dans une entreprise et que tu n'as pas de licence d'un compilateur C (non gcc ça ne va pas car sous Windows gcc produit du code "cygwin" donc dépendant de l'environnement du même nom). Bref rien de techniquement infaisable mais dans la pratique impossible à faire. Sinon il faut noter que dans un service d'une entreprise travaillant uniquement en Java trouver quelqu'un pour faire le stub en C peut être un problème.
Bon faut que tu me donnes l'adresse de ton fournisseur de morteur de serlvet, moi j'en ai une par semaine. :-)
(PS : si tu as des URL de site "comment bien faire ses applications JSP/Servlet" je prend).
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (site web personnel) . Évalué à 1.
Avec Orion (www.orionserver.com) à la compilation :
500 Internal Server Error
Error parsing JSP page /xyz/brochure.jsp
Error in sourceFound 1 semantic error compiling "C:/orion152//brochure.jsp.java":
513. JSPHlper.getLocalDir(session) (JSP page line 116)
<------>
*** Error: "JSPHlper" is either a misplaced package name or a non-existent entity.
Erreur de runtime :
java.lang.NullPointerException
at /brochure.jsp._jspService(/brochure.jsp.java:1097) (JSP page line 287)
at com.orionserver[Orion/1.5.2 (build 10460)].http.OrionHttpJspPage.service(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._ah._rad(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)].server.http.JSPServlet.service(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._cxb._abe(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._cxb._uec(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._io._twc(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._io._gc(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._if.run(Unknown Source)
Ce comportement est tout à fait normal ... Les noms de classes sont case-sensitives !!
Bah vous achetez une licence pour un compilo C, ou vous en trouvez un gratuit (ça doit bien exister :-)). Sinon pour l'entreprise travaillant uniquement avec Java qui pourrait avoir un problème avec le stub en C, ils n'ont qu'a engager des informaticiens :-) Non mais c'est quoi ces gens qui ne sauraient faire qu'un seul langage ...
http://www.javaworld.com(...)
http://theserverside.com(...)
Ce sont deux très bon sites
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo . Évalué à 1.
Bah oui mais non. Lorsqu'une boite commence à avoir une certaine taille tu peux difficilement acheter un logiciel comme un compilateur C en claquant des doigts. Ce n'est pas nécessairement impossible mais ça prend du temps.
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme . Évalué à 0.
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo . Évalué à 1.
Version longue : non bien sûr pour peu que le métier de la boîte soit lié au développement de logiciel c'est peut probable. Mais dans la pratique savoir que M. Tartempion a un compilateur C sur sa machine ne t'arrange pas des masses car il est sur un autre site ; ne travaille pas du tout sur la même chose que toi et malgré toute sa bonne volonté acceptera difficilement que tu le virer de son poste une journée pour faire tes trucs. Donc ça revient au même.
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme . Évalué à 0.
Où travailles-tu ?
[^] # Avec un peu d'huile de coude...
Posté par Anonyme . Évalué à 0.
Xavier
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme . Évalué à 0.
C'est l'objectif que Sun veut atteindre! Un seul language qui te permettrait de TOUT faire! D'où les JSP qui arrivent pour rattraper le retard pris sur php et asp et en général au niveau du web. Depuis, ils ont bien rattrapé le coup en terme de positionnement mais uniquement grâce au marketing!
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par benjamin truquet . Évalué à 1.
C'est fait pour fonctionner avec des serveurs d'appli comme Tomcat, Weblogic, WebSphere ...
Php c bien mais est ce que c'est portable ? je suis pas sur :o) !! Une appli developpée en jsp tu fais un .war et hop tu la passes sur une plateforme Linux, Windows ou Solaris sans faire aucun changement ds le code. Les JSP c'est uniquement fait pour les pros et pas pour faire son petit site à la maison :o)
# Pour les JSP, c'est objectif :-)
Posté par Nelis (site web personnel) . Évalué à 1.
Je pense que les conclusions du comparatif vont énerver pas mal de monde :) (je pense a tout ceux qui aiment se complaire dans l'idée totalement fausse que Java, c'est lourd, c'est lent, et ça ne marche pas)
Bon sur ce, je vais aller regarder à quoi ressemble le PHP, ce comparatif m'a donné envie d'y jeter un oeil :)
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par François B. . Évalué à 1.
- L'un est le site pour une association, petite taille, pas de miroir ==> PHP (de toutes façon l'hébergeur ne propose pas de JSP ;-))
- L'autre est une partie d'une grosse application dont les données sont vraiment très complexes. Les données ne seraient pas raisonnablement manipulables avec PHP. La solution est donc EJB, Beans et JSP.
Conclusion, si tu n'as pas à faire de petit site, PHP ne t'aidera pas (ou alors tu te retrouveras avec une usine à gaz comme PHPnuke). Sinon, PHP s'apprend en deux jours avec la doc qui est en ligne sur http://php.net(...)PS : j'ai fait quelques tests de charge avec mon projet JSP. Le serveur était sur un Pentium 233MMX, 64 MB de RAM sur réseau local 10Base-T. Avec 100 utilisateurs, temps moyen de réponse 2 s, temps maximum 5 s. Avec 1000 utilisateurs, 7 et 21 s. Donc Java n'est pas toujours lourdingue : il suffit de programmer autrement et arrêter de faire confiance au matériel pour récupérer les erreurs de conception.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
Je suis désolé mais ton P233Mhz sous Patate , je doute qu'il fasse tourner décemment
quoi que ce soit programmé en Java .
Remarques , tu devrais essayer une Suse , pit'aitre que là ton projet JSP aurait plus
de punch .
Et puis ... ton super portable là qui tourne avec une misérable patate pas remise à jour :
Pourquoi ne pas profiter de la formidable avancé technologique que seul SUSE est à meme
de proposer ?
Je ne vois pas pourquoi tu perds ton temps à faire du Java (Mouarfff) et à laisser des patates
(Mouarfft * 2) dans tes bécanes .
PS; SI SI , JAVA EST TOUJOURS LOURDINGUE (sourtout quand ça ne tourne pas
sous SUSE(tm) )
MOUAAARRRFFF (quelqu'un que tu connais mais qui ne va pas se dénoncer , à la limite
je balance quelqu'un d'autre :)
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Nelis (site web personnel) . Évalué à 1.
No comment ...
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
à des gens aussi étroits d'esprit :-|
[^] # T'es pas sectaire non plus toi ...
Posté par Maillequeule . Évalué à 1.
quelqu'un a un decapsuleur sur lui ? parce que je vois des oeilleres qui ne vont pas etre faciles à enlever la...
Ok, le semblant d'etude est a mon gout un peu leger, et pas vraiment objectif. Ok, c'est une magnifique rampe de lancement pour trolls , mais quand meme...
Est ce quelqu'un va prendre un jour le recul necessaire pour penser que ce qu'il pratique au jour le jour n'est pas le meilleur langage du monde (a supposer que ca existe, mais ca me fait bien rire) et que d'autres font au moins aussi efficace avec d'autres choix technologiques ?
Pour avoir pratiqué les JSP et PHP sur des projets de taille sympathique, je prefere vous dire qu'a ces occasions la il etait impossible de preferer l'un a l'autre, pour la simple raison qu'il ne collaient pas tous les deux aux besoins ni a l'architecture choisie au moment T.
Bon, ceci dit, il faut que je m'excuse aupres de messieurs les fanatiques hein : PHP, servlets, jsp, et base oracle tournent sous RedHat, ce qui va a l'encontre de l'elitisme ambiant.
Et non je n'ai pas eu honte, et oui merci, ca tourne bien.
Mike
-
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
bon aller je te balance pas mais par pure gentillesse.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
Un bon grep goto *.c dans les sources, du cote des drivers, riqueraient de te faire penser ce qui suit :
<SecondDegre>
Ca doit vraiment etre une grosse merde avec des goto dans code C, beurk beurk...
</SecondDegre>
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
[^] # vive le goto (parfois)
Posté par Anonyme . Évalué à 0.
Exemple pour la gestion d'erreur :
int toto(void) {
int all_ok = 0 ;
if ( .... == probleme ) {
goto erreur ;
}
.
.
.
if ( ... == probleme ) {
goto erreur ;
}
.
.
.
return ok ;
erreur:
// boulot sur erreur
return pas_ok ;
}
Visual Basic propose l'excellent "on error goto".
Exemple pour sortir de beaucoups de boucle imbriqués.
qqc * chercher(...) {
for(....) {
while {
for(....) {
if (c'est presque le bon) {
.
.
.
if (c'est le bon) {
goto trouve ;
}
}
}
for(....) {
if (c'est le bon) {
goto trouve ;
}
}
}
}
return NULL ;
trouve:
// faire qqc
return qqc ;
}
P.S.: désolé pour ce code pas indenté mais dacode n'autorise pas la borne "<pre>" ni les " "
Dacode pourrait autoriser "<pre>" mais dans ce cas utiliser la fonction wordwrap() (cf:http://www.php.net/manual/en/function.wordwrap.php(...)) pour éviter les lignes trop longues.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . Évalué à 1.
avec quel injecteur ??
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
de plus 1 requete != 1 utilisateur:
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
bref prenons des pincettes pour manipuler ces chiffres.
PLuG
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à -1.
hop -1
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par François B. . Évalué à 1.
humm ... comment a tu fait tes tests ?
avec quel injecteur ??
Deluge ( http://deluge.sourceforge.net(...) ) et Hammerhead ( http://hammerhead.sourceforge.net(...) ). Tous deux sont en GPL ...
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
Un utilisateur pour l'injecteur est un utilisateur dans l'application : préférences + contexte.
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
En effet, il y en avait trois. De toutes façons, je pense que je n'étais pas loin de la limitation physique du réseau (10 Mb/s). Il faudrait que je regarde plus en détail les résultats ...
de plus 1 requete != 1 utilisateur:
En effet, il s'agit d'un serveur de documentation. Je suis parti de l'hypothèse qu'un utilisateur actif charge une page environ toutes les 30 secondes. Je pense d'ailleurs que c'est assez large ... mais comme je suis au début du développement du projet, c'était juste pour voir si la solution était viable.
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
Il y a en fait très peu d'images dans mon cas, et la plupart d'entre elles sont sur toutes les pages (logo de l'application, pictogrammes de sections ...) et résident donc dans le cache du navigateur. Sinon, il doit y avoir une dizaine d'images non récurrentes. La probabilité de tomber sur une page ayant une image doit être inférieure à 0.1%. Mais bon, ce que je voulais tester était la réponse applicative (J2EE + BDD), pas le serveur ...
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
Dans mon application, les actions d'un utilisateur n'impactent pas les autres. Je n'ai à aucun endroit de système de verrou sur les données globales par un utilisateur. Les seules saisies possibles concernent les préférences de l'utilisateur (ne peut potentiellement bloquer que cet utilisateur) et l'administration de l'application (un bloquage des sessions est alors voulu). J'ai considéré que ces saisies étaient marginales dans l'utilisation de l'aplication, je les ai donc exclues de mon test.
En fait, les chargements de données dans la base ne sont possible que depuis une application indépendante qui va directement taper dans les EJB. Il serait beaucoup trop complexe d'essayer de faire ça depuis l'application HTTP à cause de la très grande quantité d'informations à lire sur le disque ... Il est également prévu d'automatiser ces mises à jour, qui peuvent alors avoir lieu pendant les heures creuses d'utilisation.
bref prenons des pincettes pour manipuler ces chiffres.
C'est vrai que j'aurais dû préciser dès le début, mais les frustrés qui ne connaissent pas Java m'ont trop énervé pour que j'y pense de prime abord ...
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
Donc, tu nous as sorti une réponse de frustré! Un test sur ta machine perso pour servir de la doc à 3 clampins pour prouver que les JSP sont faites pour les gros projets! Merci Acne, en tout cas, de te joindre à mantha pour nous fournir ce pur moment de rigolade pendant les vacances :))
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . Évalué à 1.
Je suis tout de même agréablement surpris par les chiffres que tu donnes. Ils sont plus qu'honnorable pour la configuration matérielle utilisée.
Ca me fait penser à un jour ou un collegue avait des temps de réponse terrible ... en fait les pages qu'il récupérait avec son injecteur etaient toutes des erreurs 404 :-)) Mais vu ta réponse je vois que tu as du étudier tout cela de près.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . Évalué à 1.
Java c'est lourd,c'est lent, ....
Je ne suis pas un trolleur fou et je vais donc argumenter.
Java est une solution technique (c'est pas seulement un language) forcement lourde puisque le code généré n'est pas adapté au CPU mais à une machine virtuelle [quand on a pas un cpu JAVA]. Ca ressemble à executer du code pour x86 sur un macIntosh dans un emulateur.
Les fanatiques de JAVA vont dire que ca marche quand meme et ils auront raison. Mais le même programme compilé pour l'architecture cible et écrit correctement sera forcement moins gourmand en ressources CPU/RAM/... et donc potentiellement plus rapide puique seul l'algo utile tournera.
Ensuite les mêmes fanatiques de JAVA nous reparleront des tests qui ont montré un code JAVA tourner aussi vite que son homologue en C, mais ils oublieront que cela depend de la charge de la machine, que en JAVA sur beaucoup de plateformes c'est la JVM qui gère le scheduling des threads JAVA [et elle est moins douée que le scheduleur de l'OS, ca peut même bloquer tous les threads JAVA sur un seul CPU !!] et enfin que dans le cadre de ces tests, le code JAVA avait été soigné [de vous à moi, entre un développeur C et un développeur JAVA, lequel des deux risque de mieux soigner son algo ? celui qui ne se pose même pas la question de libérer la mémoire et espère le passage d'un garbage collector à un moment ou son appli n'aura pas besoin de trop de CPU ??]
Je ne suis pas un fanatique de JAVA, mais je vois bien les avantages des solutions JAVA quand même:
Un seul package qui s'installe sur toutes les plateformes. C'est le seul avantage mais il est de taille pour tous ceux qui ont déjà VRAIMENT produit du logiciel, cela supprime des hommes/mois de boulot de packaging, tests ...
Ce package multiplateforme est donc tout indiqué pour le web ou l'architecture du client est inconnue (applets). Pour les servlets ca se discute plus, mais ca fait le bonheur des vendeurs de serveurs ... et des developpeurs. Si JAVA est plutot une solution d'architecture, il a su séduire beaucoup de développeurs en tant que langage. Du coup il y a souvent confusion ...
PLuG
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
Tout à fait d'accord et rien de plus à dire.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par truelle . Évalué à 1.
Il va sans dire qu'avec la pléthore de langages disponibles actuellement, il n'est pas déraisonnable de choisir celui répondant le plus aux besoins du projet. Actuellement, c'est encore le coeur qui parle...
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par gle . Évalué à 1.
En tant que langage, Java est aussi très bien. Une approche totalement objet, un syntaxe claire, et la majorité des erreurs sont détectées à la compilation car le langage est peu permissif.
Et en tant qu'API, Java c'est aussi un vrai bonheur, car presque tout ce dont vous avez besoin existe, bien programmé, et avec une interface standard. Un vrai régal!
Quand aux trolls sur le thème Java c'est lent, sachez que tout le monde se fout que le C soit 10% plus rapide dans les milieux professionnels. Si l'algo est bien fait, la montée en charge sera la même en C et en Java (avec toujours 10% de différence), et c'est ça qui importe. Sauf que le C plantera sans doute en arrivant à ses limites parceque le programmeur aura eu la flemme de faire la gestion d'erreurs correctement, ou qu'un free() aura été oublié.
Vous ne semblez pas comprendre que généralement la démarche est de programmer l'algo, de faire des tests de charge, et de choisir la conf de la machine de prod en fonction de la charge à supporter. Avec Java, la machine sera peut-être un peu plus chère mais comparé au coût de développement du logiciel, c'est peanuts.
Enfin, quant à la guerre JSP contre PHP, elle n'a pas lieu d'être pour moi car leurs domaines de prédilection ne se recoupent pas. PHP est adapté à la création de sites dynamiques légers et rapides, les JSP permettent de mettre en oeuvre des solutions lourdes et de s'interfacer avec d'autres sytèmes (genre Bdd professionnelle, middleware ou aute système d'information de l'entreprise).
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
Tu te raménes avec les mêmes vieux arguments marketing.
Il faut sortir, le week-end, pour voir ce qui se passe à l'extérieur.
A oui, ta signature aussi, ça te décrédibilise vachement. Je serai toi, j'éviterai si je veux paraître sérieux.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par gle . Évalué à -1.
Sache que je te méprise cordialement et t'invite à essayer d'utiliser la masse spongieuse qui git entre tes oreilles pour tenter de réfléchir, et pourquoi pas d'argumenter pour transformer cette foire à trolls en débat.
Quant à ma signature, j'en fais ce que j'en veux.
(-1 - Ca fait pas avancer le débat)
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme . Évalué à 0.
d'une part parce que çà paye plus :)))) et j'aime bien tout connaitre.. :))))
Je suis une juste une machine à développer :)))
# Licence
Posté par Anonyme . Évalué à 0.
si quelqu'un sait q'il réponde!
[^] # Re: Licence
Posté par Val (site web personnel) . Évalué à 1.
http://packages.debian.org/testing/libs/libservlet2.2-java.html(...)
Cordialement, et sans troll :-P
[^] # Re: Licence
Posté par Anonyme . Évalué à 0.
[^] # Re: Licence
Posté par Nelis (site web personnel) . Évalué à 1.
Les spécifications JSP ne sont pas en GPL (d'ailleurs je ne sais pas si la GPL en tant que telle peut-être appliquée à des specs), mais elles sont publiques : tu as accès gratuitement aux specs complètes et tu es libre de les implémenter (comme toutes les specs Java).
Par contre tu as des implémentations des spécifications JSP qui sont sous diverses licenses : propriétaire (Weblogic par exemple), Apache Software License (Jakarta/Tomcat), peut etre meme GPL (je n'ai pas de nom en tete).
Voilà, j'espère que les choses sont un peu plus claires pour toi :-)
[^] # Re: Licence
Posté par Anonyme . Évalué à 0.
[^] # Re: Licence
Posté par Matafan . Évalué à 1.
[^] # Re: Licence
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Y'a meme un compilateur qui crée de vrais binaires à partir de code PHP en commercial. Je vais regarder son cout et le faire acheter par ma boite si besoin... Si ça peut permettre de gagner un millipoil en temps de réponse sur les PHP les plus utilisés, ça peut etre intéressant...
Tiens, ça aussi c'est un avantage de PHP que Java n'a pas : générer un vrai binaire :-)
[^] # Re: Licence
Posté par Anonyme . Évalué à 0.
Tout dépend de ton environnement d'exécution. Il existe des compilateurs java qui produisent du code natif. Au hasard, le GNU java compiler :
http://gcc.gnu.org/java/(...)
[^] # Re: License
Posté par Anonyme . Évalué à 0.
Le compilo de Zend n'est pas un compilateur ...
il génère du byte code ... comme les compilo java (faudrait changer les noms c'est vrai que appeler ca compilateur aussi ca prete à confusion)
D'ailleurs pire ... pour pouvoir le réinterpreter derriere il faut avoir le Zend Optimizer (qui fait office d'interpreteur pour le byte code)
Et d'apres ce qu'on ma dit (désolé je n'ai pas les sous pour faire les tests moi meme) on ne gagne pas grand chose .... c'est plus pour cacher les sources.
# ja va est trop gourmand en ressources
Posté par Anonyme . Évalué à 0.
Il semblerait que ce soit pour cela que des serveurs avec Tomcat/Jboss tombent régulièrement
ceci dit c'est vrai que pour traiter de l'objet metier au sein d'un intranet il vaut mieux java que php
[^] # Re: ja va est trop gourmand en ressources
Posté par Anonyme . Évalué à 0.
Pour moi le comparatif est un peu faussé par le fait qu'on ne peut pas réellement comparer jsp et php puisque l'interet de développer des jsp sans servlets derrière est assez limité... Mais ce comparatif a le mérite de faire le point.
# ATTENTION !!!
Posté par Anonyme . Évalué à -1.
[^] # ABSOLUMENT PAS !!!!
Posté par Nelis (site web personnel) . Évalué à 1.
Alors arrete de dire des conneries, si dès qu'une news parle de qqchose qui ne te plait pas, c'est que c'est un troll, créé la DaAnonymeFrenchPage et ne parle que de toi dessus ... La tu auras la paix !!
[^] # Re: ABSOLUMENT PAS !!!!
Posté par François B. . Évalué à 1.
Ce sont ceux qui trollent le plus qui connaissent le moins ...
</parodie>
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
Personne ne t'empêche de l'utiliser mais ne te raméne pas avec tes potes trollesques pour démonter ceux qui ne l'utilisent pas!
C'est quoi cette news à 2 balles sinon un troll?
Rien n'est objectif!
Le mec balance des énormitées:
"- php peut se connecter à toutes les bases de données du marche mais les
interfaces sont propriétaires :
Pour ouvrir une connexion avec mysql : mysql_connect
Pour ouvrir une connexion avec oracle : OCILogon"
Je ne compte pas le nombre de fois ou il dit: "je crois, enfin je ne suis pas sûr, à vérifier quand même,..."
L'auteur nous prouve que c'est un troll:
"comme son nom l'indique (php = Personnal Home Page) permet le
développement plus rapide de petites applications web"
Si ça, c'est un comparatif objectif... Ca veut aussi dire "PHP: Hypertext Preprocessor" mais peu importe. L'auteur se base sur le nom du produit pour tirer des conclusions: trés objectif!
Bon, je ne parle pas du reste qui ne sert à prouver que "directeur technique" ne veut vraiment rien dire (dans ce cas là en tout cas). Au moins il retient les grandes lignes maketing, c'est déjà ça! MVC, EJB,etc...
Bref, c'est quoi cette news de merde? Ca part peut être d'une bonne intention mais il fallait faire quelque chose de + sérieux au niveau de la comparaison et pas ce lynchage idiot qui est un trollpot!
Au fait, nelis. Tu l'a eu, ton bac, cette année?
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Nelis (site web personnel) . Évalué à 1.
Je ne connais pas l'auteur de la news, et je trouve qu'avec le JSP il est objectif ! Pour le PHP voir mon commentaire plus haut, j'ai dis que je ne savais pas juger parce que je ne connaissais pas, mais que ça m'a donné envie d'y jeter un oeil ;-)
Je ne démonte personne, je n'ai jamais dit a personne d'utiliser PHP plutot que Java, je donne juste des arguments lorsque je ne suis pas d'accord avec un commentaire ... Regarde mes différents post sur cette page et dis moi ou tu vois des trolls ...
Enfin dernier commentaire concernant ta dernière phrase, j'ai terminé mon graduat en informatique industrielle il y a un an, et depuis je travaille pour une boite qui développe des applications ... J2EE :-) Voilà pkoi le sujet me tient à coeur ... Et toi, tu l'as eu ton bac ?
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
Aprés ton post où tu disais gentillement:
>Alors arrete de dire des conneries
j'ai voulu voir ta réaction, surtout que ta fougue envers java m'amusait déjà.
Bonne réaction, tu ne m'as pas insulté même si tu en mourrais d'envie! Trés bien!
N'empêche nelis, ce texte a beau être à la limite du correct quand il parle des JSP, s'il ne l'est pas au niveau du PHP, c'est un troll,FUD,etc...
Et là, malgré ta politesse, je ne peux être d'accord avec toi quand tu défends ce genre de truc. Je pensais que java n'avait pas besoin de ça pour être considéré comme une solution viable.
Par contre, je n'ai que mon brevet des colléges et un bi-proc 800MHz, donc je crains que java et les EJB ne restent pour moi qu'un doux rêve!
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Nelis (site web personnel) . Évalué à 1.
Bah on y gagne rien a insulter :-) Meme si parfois ça fait du bien et ça défoule, ça nous retombre tjrs dessus ...
N'empêche nelis, ce texte a beau être à la limite du correct quand il parle des JSP, s'il ne l'est pas au niveau du PHP, c'est un troll,FUD,etc...
C'est possible, comme je l'ai dis je ne connais pas PHP, par contre je serais très heureux de l'apprendre :-) Si tu veux on en parle autour d'une bonne bière ? ;-)
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à -1.
Qui a dit que les forums n'étaient pas conviviaux, hein ???
;o))
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
non, cette news n'est pas objective. elle est pro-jsp.
et c'est pour cela que c'est un troll déguisé.
et je ne connais pas assez le jsp pour en parler, donc je ne participerait pas plus au débat, mais il n'y a pas besoin de s'y connaitre dans le domaine pour le voir.
magic23, qui n'etait pas autentifié, qui n'avait pas fait gaffe, et qui a la flemme de retrouver son mot de passe.
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
Cette news n'est pas un troll, c'est un avis. Par contre, c'est tout sauf un comparatif objectif, mais c'est telle fréquent de nos jours...
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à -1.
Freddy la Bastos
Comment ça -1 ?
[^] # Re: ABSOLUMENT PAS !!!!
Posté par Anonyme . Évalué à 0.
# Amusant :-)
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Parmis les "petites" applis qu'on a réalisé, je peux citer un workflow complet d'achats connecté à notre serveur SAP/R3, les systèmes de saisie d'heures travaillées et de congés tenant compte de la legislation des 35 heures, un SGDT pour notre système de CAO permettant, entre autres, de faire des compositions numériques de véhicules et de visualiser ces compositions en VRML sur n'importe client....
Point de vue développement, c'est extrèmement rapide et c'est parfaitement fiable. L'orientation
objet de PHP permet facilement de définir des classes comunes à toutes les applis et donc de développer toutes les applis selon un framework commun. Quelqu'un d'autre de ma boite qui lit aussi linuxfr.org pourra en rajouter sur le sujet si ça lui dit ;-)
Parallèlement, du fait de l'achat (pas eu mon mot à dire) d'un logiciel du commerce basé sur JSP, j'ai du le mettre en place (JSP avec Apache sur Solaris, encore) et je peux dire que de mon expérience (admin, pas développeur), c'est un véritable cauchemard à mettre en place, c'est lent lourd et pénible à maintenir. Et je trouve que ça bouffe bien trop de ressources par rapport au peu de hits que ça fait.
Pour moi, JSP = bricolage... Mais ce n'est que le point de vue d'un admin...
Dans l'équipe des développeurs, y'en a un qui a déjà fait du JSP et il préfère largement le PHP, y'a pas photo (ca fait un peu léger comme argument technique mais bon...)
[^] # Re: Amusant :-)
Posté par Val (site web personnel) . Évalué à 1.
Aller, finalement t'aime pas... alors ne dit pas que ça ne marche pas chez toi.
[^] # Re: Amusant :-)
Posté par Anonyme . Évalué à -1.
Toi ka l'air de bien maitriser jsp et autres (java koi), pourquoi tu nous réécrirais pas dacode 1.2 en jsp? C'est vrai ke 10Mhit/M, c'est pas un gros site mais c'est juste pour voir.
Tu peux développer avec ki tu veux (nelis,acne,frafra,etc....) pour qu'on ai une chance de voir kkchose avant 2003.
Juste une restriction: pas de mainframe!
Il faut ke sa tourne sur le même serveur k'actuellement!
Alors, ça roule pour le challenge?
[^] # Re: Amusant :-)
Posté par Nelis (site web personnel) . Évalué à 1.
Sinon, si vous avez un projet intéressant à proposer, je suis partant :-)
[^] # Re: Amusant :-)
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Et là, je parle d'un serveur dans un bureau d'études de 3000 personnes avec des utilisateurs éparpillées un peu partout en Europe et en Amérique du Sud, donc la disponibilité est TRES importante !
Pour ce qui est de la doc, j'en ai déjà lu un tout petit peu (!), je te remercie, pour mettre en place des config Apache + PHP + SSL + authentifications Radius et LDAP, sans meme parler de Apache + JSP et j'oublie tout un tas d'autres modules !
Pour ce qui est du développement, je fais confiance aux développeurs quand ils me disent préférer PHP à JSP. Et quand je vois les superbes applis qu'ils pondent en PHP : je les crois :-)
[^] # Re: Amusant :-)
Posté par Anonyme . Évalué à 0.
là vous comparé ACCESS avec Visual BASIC...
PHP est très puissant je pense même que c'est plus rapide que le JSP, mais le PHP est extra pour tout ce les site Editoriaux. Ensuite on passe dans la cour des grands avec le JSP.
Aujourd'hui les entreprise demande du java car il y a une image derièrre pourtant je pense qu'il est surement possible de faire la même chose en PHP.... voilà voilà
# Mise au point....
Posté par Pierre Tramal (site web personnel) . Évalué à 1.
jsp (donc java) est un langage full objet avec tous les avantages que cela
comporte en terme de rapidité de développement + de nombreux IDE
PHP peut etre utilisé en tant que langage objet et hériter de toutes les fonctionnalités d'un langage de ce type (cf: dacode).
- en terme de système d'information, java possède beaucoup plus d'api que
php pour tous types de connexions à d'autres applicatifs ou protocoles :
cela permet de se greffer plus facilement à tout système d'information :
CICS, MQSeries, SNMP, tivoli, bases de données, corba, RMI, XMLRPC, FTP...
PHP supporte le FTP en natif depuis la version 4.0.x, peut se connecter aux bases de données MySQL, PostgreSQL, Oracle, Interbase, DB2,... (la liste pourrait faire des pages et des pages)
- Les serveurs applicatif java peuvent se greffer sur tous les serveurs WEB
du marche, php ne doit (a vérifier) que fonctionner avec Apache et IIS
PHP peut fonctionner en tant que CGI, ce qui lui ouvre les portes de tous les serveurs du marché
- les serveurs applicatifs java peuvent fonctionner "in process" ou "out
process" : c'est a dire dans le même processus que le serveur web ou dans un
processus sépare, ce qui permet (dans le cas du out-process) de placer le
serveur web et le serveur applicatif sur des machines différentes : cela
permet d'avoir un système complet N-Tiers qui assure notamment du load
balancing et de la haute disponibilité a tous les niveaux.
PHP ne permet pas cette souplesse d'architecture, car il tourne
"in-process", (je crois que php possède maintenant un module lui permettant
de faire de l'out-process aussi, mais lorsqu'on l'utilise, je crois que
certaines fonctionnalités (par exemple la gestion des sessions) ne
fonctionnent pas <--- à vérifier quand même)
parlons-en, de la performance de Java....
- comme son nom l'indique (php = Personnal Home Page) permet le
développement plus rapide de petites applications web, mais en aucun cas de
vrai applications web scalable et fortement connectées. Des lors que le
projet commence a devenir gros, le PHP devient complexe a mettre en oeuvre.
1. PHP a été renommé en Php Html Preprocessor.
2. On ne développe pas des grosses applis web en php: moui, c'est pour ca que c'est le language de script serveur le plus utilisé sur le Web....
En terme de rapidité d'exécution, les temps de réponses de JAVA sont
aujourd'hui équivalent a ceux de PHP
Avec un octo-Pentium III Xeon @ 1.2 ghz chacun et 64gb de RAM ?
- enfin, mais ça a son importance, JAVA est soutenu par un grand nombre de
TRES grand noms de l'informatique : SUN, IBM, ORACLE...
Windows est soutenu par un GEANT de l'informatique: Microsoft. Ce n'est pas pour ca que c'est bien...
[^] # Re: Mise au point....
Posté par Anonyme . Évalué à 0.
> Le contraire n'a pas ete dit.
PHP supporte le FTP en natif depuis la version 4.0.x, peut se connecter aux bases de données MySQL, PostgreSQL, Oracle, Interbase, DB2,... (la liste pourrait faire des pages et des pages)
> ok pour ftp et les bd, mais le reste, ya pas ke ftp et bd dans la vie.
Toutes les api java sont utilisables sans meme avoir les sources (juste besoin des .class et de la javadoc) en jsp.
En php il faut ou attendre ke php evolue, ou bien ajouter la fonctionnalité a php sois meme ce qui me parait tres complexe (en tout cas plus complexe que de reutiliser des class deja faites).
PHP peut fonctionner en tant que CGI, ce qui lui ouvre les portes de tous les serveurs du marché
> Je vois pas bien l'interet de php si c pour faire des cgi, autant faire du c ou du perl ...
parlons-en, de la performance de Java....
> bah oui allons y; pour un serveur applicatif elles sont identiques a celle de php.
En plus on te parle d'architecture distribué impossible a faire en php, et tu nous parles de perf., tu manques un peu d'args non ? Et oui remets toi, ya au moins un truc que tu peux pas faire en php :p
1. PHP a été renommé en Php Html Preprocessor.
2. On ne développe pas des grosses applis web en php: moui, c'est pour ca que c'est le language de script serveur le plus utilisé sur le Web....
> Renomer un projet ne change rien au fait k'il soit dédié aux petits projets.
Avec un octo-Pentium III Xeon @ 1.2 ghz chacun et 64gb de RAM ?
> Bah on utilise des mono-p2-300 avec 128Mo et ca marche tres bien. Ca te parait gros comme machine ? C'est meme plus du bas de gamme ...
- enfin, mais ça a son importance, JAVA est soutenu par un grand nombre de
TRES grand noms de l'informatique : SUN, IBM, ORACLE...
Windows est soutenu par un GEANT de l'informatique: Microsoft. Ce n'est pas pour ca que c'est bien...
> tu n'as pas compris le sens de la phrase emporté par ton élan a defendre php.
Il ne s'agit pas de dire "sun oracle et ibm de defendent donc c bien", il s'agit de dire " sun oracle et ibm contribue a son dev." ca veut dire "sun oracle et ibm codent pour faire avancer les choses".
Je te rappelle aussi que tu as dit plus haut ke php etait le plus utilisé au monde. Windows est le plus utilisé au monde, est-il le meilleur ?
Conclusion :
Je trouve que tu manques un peu d'objectivité.
Cet article ne descend pas php, il dit simplement que jsp permet plus de choses, la question est de savoir qui en a besoin. Si php suffit autant utiliser php. Pas la peine d'utilise une masse pour ecraser des fourmis.
[^] # Re: Mise au point....
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Quand je dirais à nos développeurs qu'on fait des petits projets en PHP, ça va bien les faire rire :-)
Dire ça, c'est vraiment n'importe quoi :-)
Pour nous, c'est plutot JSP qui est synonyme de petit projet lent et qui ne marchera jamais vraiment bien (désolé, je ne fais que constater, dans mon environnement, je n'ai encore pas vu de projet développé en JSP qui vaille le détour, ça ne veut pas dire que ça n'existe pas).
> En php il faut ou attendre ke php evolue, ou bien ajouter la fonctionnalité a php sois meme ce qui me parait tres complexe (en tout cas plus complexe que de reutiliser des class deja faites)
On peut faire (et on fait) des classes en PHP :
classe pour gérer les accès au BD (dès fois que l'envie nous prenne de remplacer Oracle par autre chose), classes pour gérer les autorisations par profil, objet pour générer des graphiques dynamiques, etc...
[^] # Re: Mise au point....
Posté par woof . Évalué à 1.
y'a une class db, et selon qu'on a configuré mysql ou postgresql, eh ben c dbmysql.php3 ou dbpgsql.php3 qui se fait charger avec la classe Db :)
et le reste n'y voit que du feu ->
$db->fonction();
--
moi
[^] # Re: Mise au point....
Posté par Anonyme . Évalué à 0.
Allez sur : http://industry.java.sun.com/products/jdbc/drivers(...) et comptez le nombre de bd gerees.
Moi j'en compte plus de 70 et ca en changeant juste le driver jdbc (un fichier a ajouter + une conf a changer).
Sans parler de daCode, php ne gere pas (encore) tout ca.
Si votre base est geré par php , vous pouvez toujours ecrire votre propre class db.
Si ce n'est pas le cas, vous pouvez tjs ajouter la gestion a php ... bon courage.
[^] # Re: Mise au point....
Posté par Anonyme . Évalué à 0.
De plus, php utilise les API natives des bd donc + rapide et plus fiable et disponible d'emblé dans le language!
Si le driver jdbc pour ta bd est buggé (il y en a bcp surtout quand on veut manipuler les procédures stockées), c'est le même tarif! A toi de le réécrire alors....bon courage ;)
[^] # Re: Mise au point....
Posté par Anonyme . Évalué à 0.
[^] # Re: Mise au point....
Posté par Anonyme . Évalué à 0.
Mais jevais te répondre à toi, pas à l'article.
<-"Je vois pas bien l'interet de php si c pour faire des cgi, autant faire du c ou du perl"
->Et bien c'est l'auteur de l'article qui argumentait en disant que c'était un manque ... indépendament du fait que ca soit pertinent ou pas ca existe donc ca ne peut etre un manque contrairement à ce qu'il dit.
<-"ok pour ftp et les bd, mais le reste, ya pas ke ftp et bd dans la vie.
Toutes les api java sont utilisables sans meme avoir les sources (juste besoin des .class et de la javadoc) en jsp.
En php il faut ou attendre ke php evolue, ou bien ajouter la fonctionnalité a php sois meme ce qui me parait tres complexe (en tout cas plus complexe que de reutiliser des class deja faites)."
-> euh .. les classes elles dne descendent pas du ciel, c'est soit java qui bouge (les développeur de chez sun) soit quelqu'un qui l'a fait lui meme et partagé. D'un point de vue possibilité d'extension c'est la meme chose. D'un point de vue extensions déjà faites je pense que pour l'essentiel des applications qui tournent sur le web les extensions contenues dans php suffisent (ce qui ne veux pas dire qu'il ne faut pas que ca évolue encore mais pour te sentir limité avec ca faut déjà chercher quelque chose de bien spécifique et pas habituel j'ai l'impression).
<-"Renomer un projet ne change rien au fait k'il soit dédié aux petits projets. "
-> on est bien d'accord, ceci dit il a été nommé du temps de PHP/FI et depuis .. oui ... le projet à bien changé et n'a plsu rien à voir.
Personnellement je ne pense pas que php s'oppose à la gestion de "grands" projets ou applications, ceci dit pour un projet important je ne le ferais pas en script, que ce soit des scripts java ou php ....quitte à le faire en script rien j'avoue que rien ne m'empechera de le faire ne php (et vu la différence de ressources prises ca me semble meme le meilleur choix).
De plus comment dire .... juger les performances et la pertinence d'un code sur son nom ca me semble .... léger .. non ?
<- "Le contraire n'a pas ete dit. "
-> mais clairement sous entendu car présenté comme un désavantage (ou alors j'ai mal compris mais je ne crois pas)
Je ne connais que tres tres peu jsp donc peut etre que c'est en effet formidable et "mieux" que php mais une chose est sure ... sur l'article n'est en rien objectif car la tres grande majorité (pour ne pas dire tout) de ce qui est dit sur php est faux/aproximatif/non expliqué ....
[^] # Re: Mise au point....
Posté par Anonyme . Évalué à 0.
Moi j'utilise WebSphere 3.5 sur un Pentium III 1 GHz avec 512 Mo de RAM, eh ben c'est vraiment pas une fleche... Il faut compter entre 5 et 10 minutes pour demarrer une application (un peu) lourde.
Par contre, Java est vraiment un excellent langage, et si, comme moi, vous n'aimez pas les jsp, il existe des solutions Java qui n'utilisent que des servlets. je pense a Enhydra, qui est simple a mettre en oeuvre (en une semaine, on peut vraiment en avoir une maitrise correcte, et developper une application simple), et qui a une architecture vraiment cool (des classes pour l'acces aux donnees, des classes pour la "Business Logic", et des classes pour la presentation). Pour moi, Enhydra est (plus ou moins) un PHP en Java, vraiment pas trop lourd (meme si un programme Java - JVM oblige - sera toujours trop gourmand en memoire) et vraiment propre pour developper et donner de bonnes habitudes aux jeunes developpeurs. J'ai meme reussi a l'installer sur le laptop d'un commercial, pour qu'il aille faire des demos chez nos clients... Avec un PII 300 et 64Mo, ca ne ramait pas du tout...
Maintenant, pour des developpements tres importants, la problematique est differente. C'est vrai que Java offre des possibilites de connectivite que tout le monde connait, et dans ce cas, le support des editeurs comme SAP ou Oracle, ou meme le support pour des applis plus exotiques est un avantage. Java permet aussi d'utiliser des frameworks open source MVC comme Struts ou Barracuda, qui sont deja interessants, et surtout qui ont un potentiel enorme en terme de facilite de developpement.
Malgre le (gros) probleme de consommation memoire pour les petites applis non graphiques, et le (tres gros) probleme de consommation de ressources processeur + memoire pour les applis AWT/Swing, Java cote serveur est quand meme un environnement au tres fort potentiel, qui offre deja une foule de fonctionnalites interessantes malgre une relative jeunesse. Java doit encore murir, mais a une reelle ambition cote serveur.
Hugo (non authentifie)
[^] # Re: Mise au point.... php objet
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
je n'etai pas arrivé a stocker un objet dans la propriete d'un objet, ça me semble un peu limitant pour faire de la POO, quand même, non?
Si vous voulez de l'objet pas java, ya Zope, non?
> PHP peut fonctionner en tant que CGI, ce qui lui ouvre les portes de tous les serveurs du marché
avec du CGI, tu vas super loin... il se recharge a chaque fois, tu perds plein d'info et de possibilités dans ton code. Le CGI, c'est du bricolage. et puis, entre nous, si tu utilises du PHP, tu prends Apache, ça sert a rien de tortiller, (ou un machin qui l'utilise comme il faut).
[^] # Re: Mise au point.... php objet
Posté par Chamelle Kolabo . Évalué à 1.
dans le cas de php il y une separation traitement/donnée, alors que dans un SGBDO comme
02 ou zope tu retrouves le tout stocké au meme endroit.
# Sql-Relay
Posté par Anonyme . Évalué à 0.
interfaces sont propriétaires :
Sql-Relay est un démon qui interface différentes bases de données avec plusieurs langages dont PHP par l'intermédiaire d'une API. En définitif on se retrouve avec un code générique quelque soit le type de SGBD.
>- Toujours concernant les bases de données : php gère en natif un système de
pooling de connexion, ce système, quoi que relativement performant n'est pas
aussi performant que les systèmes de pool de connexion que l'on peut avoir en
java (plus de possibilité de configuration du pool)
Sql-Relay permet une configuration fine de son pooling de connexion. Son principe est extrèmement performant est a fait ces preuves sur le site d'inscription d'OREKA.
Sur ce site le démon Sqlb a été utilisé mais je conseille fortement Sql-Relay.
http://www.firstworks.com(...)
SHen.
SQL Relay is a persistent database connection pooling, proxying and load
balancing system for Unix and Linux supporting ODBC, Oracle, MySQL, mSQL,
PostgreSQL, Sybase, MS SQL Server, IBM DB2, Interbase, Lago and SQLite with C,
C++, Perl, Perl-DBD, Python, Python-DB, Zope, PHP, Ruby and Java APIs, command
line clients, a GUI configuration tool and extensive documentation.
[^] # Re: Sql-Relay
Posté par Ludovic Boisseau . Évalué à 1.
<TROLL type=mechant>
Ah bon ? OREKA disposait d'un truc performant quelque part ? Je savais pas ;o)
</TROLL>
Au fait, pour ceux qui utilisent encore OREKA, ca marche mieux ?
[^] # Re: Sql-Relay
Posté par Anonyme . Évalué à 0.
# halte !
Posté par Anonyme . Évalué à 0.
Et oui, je suis étonné que linuxfr.org se fasse le relai de ce genre de choses, du moins comme ca.
Présenté comme un "comparatif" ca ne me semble pas autre chose que de la critique comparé, ce que les boites américaines ont l'habitude de faire pour se faire de la pub (descendre celui d'a coté en faisant un soit disant comparatif).
D'ailleurs le modérateur n'est pas tres objectif non plus, seul le lien vers jakarta est présent.
Si au moins ca avait été présenté avec un minimum de recul et de commentaire ...
Linuxfr.org commence à faire de moins en moins sérieux par moment. Si le fait que les directeurs de projets fassent des textes on ne peux moins objectifs et utiles ca ne me choque guerre, mais que linuxfr s'en fait l'écho en les qualifiant de "comparatif" sans aucune commentaire là je suis plutot choqué ... une personne qui ne connais pas PHP sera convaincu apres avoir lu ca que ca ne vaut pas mieux que du qbasic.
Et le modérateur ? il n'est pas là pour filtrer ? ou au moins mettre un minimum de commentaire pour dire "tout n'est pas vrai" ou "c'est loin d'etre objectif" ?
En effet on trouve des choses archi fausses que quelqu'un qui s'est interressé à php plus de deux semaines pourraient corriger. S'il a le rflexe de mettre "a vérifier" à chaque fois, si réellement il ne savait pas qu'il disait une énormité alors je crois qu'il n'est pas assez renseigné pour que son texte vale plus que celui d'un débutant qui a essayé pendant deux semaines php et jsp (comme je lui prete plus de connaissances que ca, c'est qu'il a du le faire expres de raconter des choses fausses, ce qui n'est pas mieux .... bref, soit il n'y connait rien (du coté php) soit il est menteur, je vous laisse choisir)
Entre autres (sans pour autant dire que php est mieux que jsp, je ne connais pas assez jsp pour ca) :
- et si : php permet depuis longtemps d'executer les scripts grace à un binaire, et donc dans un process séparé du serveur web,
- la gestion des session marche tres bien quand php marche en binaire ... les fonctionnalités sont les mêmes (je ne connais qu'une seule exception mais qui doit etre la meme en java puisque venant du serveur web)
- php ne marche pas que avec IIS et apache et je concois meme qu'il doit etre plus simple à implémenter dans un autre serveur que un moteur jsp (ou il faut une machine java ..)
- "comme son nom l'indique (php = Personnal Home Page) permet le développement plus rapide de petites applications web, mais en aucun cas de
vrai applications web scalable et fortement connectées" Si c'etait peut etre vrai du temps de PHP/FI ca ne l'est plus et il est facile de regarder l'existant pour contredire l'argument. SI, php permet bien de faire des applications au meme titre que java.
- "les coûts induit (pour de gros
projet) par des développements php dépasse très rapidement le coût marginal" je n'ai pas assez d'expérience en java pour donner une réponse précise mais je suis très étonné par cette affirmation, php m'a l'air plus simple d'acces que jsp pour un programmeur qui n'a fait aucun des deux. Ca m'a plutot l'air d'une affirmation gratuite. Ou alors il parle du fait que c'est plus complexe car pas de l'objet ... c'est discutable
- des couches d'abstraction de base de données qui n'ont rien à envier a personne existent désormais en php (c'est vrai que ce n'était pas vrai il y a un an), le seul défaut étant qu'elle ne sont pas incluses dans le moteur.
- "Pour de petits applicatifs qui n'ont vraiment aucune raison (même a long terme) d'être connectée au système d'information de l'entreprise le choix PHP semble s'imposer." Si je comprend bien java ne s'impose que à cause de la connectivité ? voyant les possibilités de php à ce niveau (je ne connais que peu celle de java) je pense que la majorité des gens n'auront jamais lieu de les dépasser, si j'en crois cette phrase autant garder php :o)
Je ne suis peut etre pas tres objectif mais je ne peux l'etre que plus que l'auteur de départ.
[^] # Re: halte !
Posté par Anonyme . Évalué à 0.
projet) par des développements php dépasse très rapidement le coût marginal" je n'ai pas assez d'expérience en java pour donner une réponse précise mais je suis très étonné par cette affirmation, php m'a l'air plus simple d'acces que jsp pour un programmeur qui n'a fait aucun des deux. Ca m'a plutot l'air d'une affirmation gratuite. Ou alors il parle du fait que c'est plus complexe car pas de l'objet ... c'est discutable
---> On parle de gros projets, donc rarement de developpeurs debutants... (mais tout est possible :p)
[^] # session & base de donnée
Posté par Anonyme . Évalué à 0.
CF : http://www.php.net/manual/en/ref.session.php.(...)
Néanmoins penser a utilise PHPLIB qui ajoute quelques fonctionnalités interressantes.
* > - "comme son nom l'indique (php = Personnal Home Page) permet le développement plus rapide de petites applications web, mais en aucun cas de vrai applications web scalable...
N'importe quoi... Il y a de très gros site qui utilise php sans problème.
Il est LOGIQUE que php utilise des fonctions spécifiques par base de donnée (les bases de données ont souvent des caractéristiques différentes). Si on veut un accès unifié il faut utiliser ODBC (c'est fait pour çà).
Sinon, pour le pas utilise ODBC il y a PHPLIB (ou PEARL) pour être indépendant de la base de donnée...
[^] # Re: halte !
Posté par Val (site web personnel) . Évalué à 1.
- "je suis étonné que linuxfr.org se fasse le relai de ce genre de choses, du moins comme ca"
- "Et le modérateur ? il n'est pas là pour filtrer ? ou au moins mettre un minimum de commentaire pour dire "tout n'est pas vrai" ou "c'est loin d'etre objectif" ?"
C'est bien, vive la liberté avec des mecs dans ton genre. La news dit bien "Mantha (directeur technique) a écrit un petit comparatif php/jsp" et un peu plus bas sur la page tu peux lire "Les nouvelles et les commentaires appartiennent à leurs auteurs respectifs, le reste appartient à LinuxFr".
Alors les leçons de morale à deux balles parce-que [ ] les trolls et/ou [ ] les débats (coche la ou les case(s) qui t'interresse(nt)) qui touchent à ton honneur de développeur du langage trucmuche machinchose tu les colles pas sur le dos de LinuxFR stp, merci.
Et je suis d'accord avec toi : t'es pas objectif.
[^] # wow
Posté par Claveras Manu . Évalué à 1.
Au final même si ce que le mec a dit avant est peut-être pas très juste, c'est toi qui passe pour un abruti congénital en l'envoyant chier.
[...] touchent à ton honneur de développeur du langage trucmuche machinchose ...
C'est un petit peu l'hopital qui se fout de la charité. En relisant tes commentaires, on a bien vu que ton honneur de développeur du langage trucmuche machinchose (jsp) avait été blessé par les défenseurs de PHP. C'est un petit peu toi que tu décris avec cette phrase.
[^] # Re: halte !
Posté par Anonyme . Évalué à 0.
Quand au fait de la mention, en bas de page/news c'est bien mais peut mieux faire. Pour faire une (horrible) image (donc forcément mauvaise comme toutes les images, il ne faut pas prendre ca au premier degré mais ca illustre), si j'ai un journal que je recopie des textes négationistes, on pourra me le reprocher, meme si je met que les propos ne sont pas ma responsabilité.
En les publiant vous linuxfr les cautionne un minimum, c'est à ca que sert la modération, à ne pas mettre une news completement fausse.
Maintenant je n'ai rien contre la librerté d'expression contrairement à ce que tu le dis. Si c'est une opinion alors soit, mais qu'elle soit signalée comme une opinion du coté de linxfr (et pas comme un comparatif, chose qui par définition est sensée etre un minimum objective).
Si la news avait étée présentée avec un peu plus de précautions genre "un texte présenté comme comparatif, attention il y a quelques choses fausses" je n'aurais rien à y dire. Pour moi c'est le role du modérateur de vérifier ce qu'il publie ou au moins de le présenter comme vrai/faux objectif/pas objectif. En mettant "comparatif" dans le titre vous trompez le monde, j'ai vu des news ici qui ont bénéficié de ce traitement de "attention" ou "mouais ..."
Dernier point, oui, comme je l'ai dit je fait pas mal de php, et oui c'est peut etre à cause de ca que je m'insurge plus, pas besoin d'etre dépréciatif, je ne vois pas ca en négatif.
D'ailleurs comment dire .. si je ne connaissais pas bien le php alors je n'aurais pas eu lieu de réagir puisque j'aurais proablement cru ce qu'il y avait marqué :o)
Ganfset@free.fr
# Darkleon >Tout ça, c'est du marketing, concrétement qu'est-ce que ça donne.
Posté par Anonyme . Évalué à 0.
J'ai travaillé en JSP et en PHP et je constate :
1 - aucune des 2 solutions peut faire du MVC correct (séparation du boulot d'infographiste/designer du html et du codeur) il arrivera toujours un moment ou il y a trop de code dans la page (pour la création de tableaux par exemple). A priori, PHP est un peu plus bordélique, sauf si on met toutes les fonctions dans un autre fichier importé.
2 - conséquence immédiate, j'ai vu trop de JSP qui ressemblait à du PHP -> gain nul en lisibilité, perte seche en facilité de développement.
3 - PHP n'a jamais été prévu pour faire tourner une usine à gaz, c'est orienté pour l'affichage d'une page et pas la succsession de plusieurs pages (comme le site SNCF par exemple).
4 - une appli PHP n'a pas besoin d'un environnement, un simple éditeur de texte suffit. C'est la robustesse du basic avec une syntaxe C.
5 - Trop souvent on passe des paramètres de pages en pages tout en refaisant le même traitement, ce qui supprime tous les avantages du JSP.
6 - Les applis JSP/EJB ont vite tendance à devenir des usines à gaz (en PHP aussi si les pages sont interdépendantes), on fait trop de traitement du côté JAVA, et pas assez du côté de la Base de Donnée (reqûete simple, et combinaison de plusieurs tables du côté de l'appli JAVA, au lieu de les faires en SQL).
Conclusion :
Perso, je trouve plus agréable de travailler en PHP (attention, j'ai pas dit que c'était mieux techniquement) car c'est bcp plus rapide pour développer, les libs sont vraiment orientés manipulations de texte et sgbd, et c'est pil-poil ce qu'il faut pour faire de l'affichage HTML.
Si maintenant il faut une appli qui aille ouvrir 36 sockets exotiques pour récupérer l'information, il vaut mieux utiliser JAVA, mais c'est plutôt une minorité de cas.
Et puis comme ça on a de bonnes excuses si ça foire.
Le problème de cette solution, c'est qu'elle est trop généraliste, et il faut prévoir pleins de trucs avant même de tapper le code de l'appli qui nous concerne.
Je ne crois pas au modéle de SUN (sur le plan technique, enfin en théorie c'est génial sisi, mais en pratique, quel bordel), mais il va quand même passer, parce que
1 - ça fait hype pour les gentils commerciaux
2 - donne plein de boulots aux SSII (Des usines à gaz tu écriras, pour faire payer la maintenance tu devras).
3 - fait plus sérieux qu'un logiciel dont les sources font 3mo et qui sont développés à la base par un gars indépendant
De toute manière, c'est toujours pareil, en fonction de l'appli à programmer, on va choisir l'une ou l'autre solution.
Darkleon (Cookies Lost in Space).
[^] # Re: Darkleon >Tout ça, c'est du marketing, concrétement qu'est-ce que ça donn
Posté par Yann Bloch . Évalué à 1.
Pour ca, les fonctionnalites de java sont quand meme pratiques pour garantir une certaine clarte du code : par exemple les notions d'interface, de classes abstraites, de methodes publiques, protegees ou privees. Tout ca, je n'ai pas souvenir de l'avoir vu en PHP.
PHP, c'est super facile, relativement puissant, mais ca devient tres vite galere quand on veut faire des gros trucs, tout simplement parce que le cote objet n'est pas assez poussee.
[^] # Re: Darkleon >Tout ça, c'est du marketing, concrétement qu'est-ce que ça donn
Posté par Anonyme . Évalué à 0.
Java dans ton environnement (mainframes à tous les étages :), c'est sans doute la bonne solution.
Mais ici, on parle de web.
[^] # Re: Darkleon >Tout ça, c'est du marketing, concrétement qu'est-ce que ça donn
Posté par Yann Bloch . Évalué à 1.
[^] # Re: Darkleon >Tout ça, c'est du marketing, concrétement qu'est-ce que ça donn
Posté par Anonyme . Évalué à 0.
Documentes toi un peu plus sur PHP, tu verra, c'est très bien :-)
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Anonyme . Évalué à 0.
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Serge Rossi (site web personnel) . Évalué à 1.
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Ghorin . Évalué à 1.
Nous faisons du php depuis maintenant 2 ans et nous l'utilisons pour tous nos développements. Nous avons développé un paquet de librairies (plus de 60) sous forme de classes réutilisées dans toutes nos applis. Bref du standard !
Tout ça non pas avec 3000 informaticiens mais avec juste 5 informaticiens. Ah oui, j'oubliais : il n'y a pas eut besoin d'envoyer quiconque en formation pour php : c'est facile à comprendre. Or le temps c'est de l'argent et chez nous, ils ont bien compris ça : nos clients internes veulent des applis qui marchent 3 mois après au maximum ... et ils l'ont et elles durent longtemps. En gros, nos applis développées en php coutent peu en développement et sont rentabilisées très vite par la société. Ce qui n'est jamais le cas avec les gros développements java, jsp ou c++ de la maison mère qui coutent des millions et qui sont obsolètes dès leur sortie.
Bon Serge vous a donné son point de vue d'administrateur mais voici mon point de vue de développeur (sachant que je n'ai jamais fait de jsp et que je ne remonte que les remarques d'un collègue pour ce langage) :
Ce que je reproche à php, c'est de ne pas implémenter complètement le langage objet. Il y a des choses qui manquent réellement comme le polymorphisme. Mais peut être qu'un jour ...
Sinon on peut tout faire avec, de la simple petite appli au gros projet. Il suffit d'organiser la structure de développement, ce qu'on a fait. Comme tout langage, il y a ceux qui savent l'utiliser et ceux qui bidouillent avec.
L'avis de mon collègue concernant php-jsp est le suivant : jsp est un langage plus complet que php (et je suis d'accord avec lui) car il implémente toutes les notions objet. Son code est plus clean puisqu'il ne permet pas d'écrire n'importe quoi mais il est plus contraignant et plus lourd à mettre en oeuvre.
Juste une remarque en passant : Ce n'est pas parce qu'un langage est "simple" qu'il ne peut pas tout faire ! Et dans l'autre sens, ce n'est pas parce qu'un langage est complet qu'il est mieux que les autres. Le problème est d'avoir les compétences et l'organisation adéquate pour bien l'utiliser.
Je ne saurais répondre moi-même sur jsp mais les échos de projets jsp de la maison mère ne sont pas très élogieux. Mais peut être n'est ce qu'un problème de compétence (j'espère qu'ils ne vont pas me reconnaitre sinon je suis grillé chez eux) !
Eric
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Yann Bloch . Évalué à 1.
C'est aussi ce que je lui reproche. Ca me parait un peu bizarre de faire de grosses bibliothèques de classes avec un langage qui n'est pas fait pour. Parce que, oui, PHP, ce n'est pas un langange fait pour de l'orientation objet. On peut effectivement faire quelques classes, mais je vois mal de grosses hierarchies...
Quant a une integration future des fonctionnalités manquantes de la POO, je suis plus que sceptique. il faudrait revoir pas mal de choses, notamment le système de typage, la méthode d'instanciation des classes...
J'ai pas mal programmé en PHP, et je vais certainement continuer de le faire, mais à mon avis, un langage comme Java (ou Python ?) est mieux adapté à de grosses structures.
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Ghorin . Évalué à 1.
Pas du bel orienté objet certes !
Mais quel est le but du développement informatique ? De faire du pur orienté objet ou de pondre l'application que demande les utilisateurs ?
En tout cas chez nous php nous suffit et est largement suffisant pour répondre à toutes les demandes de développement. Et pas que pour des petits développements. Et en plus, ça ne coûte rien : pas de license à acheter avec apache+php+ 1 éditeur de texte libre, pas de machine énorme pour faire tourner la jvm et les process clients, pas de formation intensive et couteuse ...
Mais là je suis peut être négatif et il existe sans doute des solutions jsp peu couteuses également.
à mon avis, un langage comme Java (ou Python ?) est mieux adapté à de grosses structures
Je dirais plutôt que ce genre de langage ne peut être mis en place efficacement que dans les grosses équipes de développement. Si chez nous on ne faisait que du java, on pondrait beaucoup moins d'applications clientes.
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Anonyme . Évalué à 0.
Ca va évoluer, tout est prévu ds le prochain moteur ZEND (php 4.1 ou php5)
http://www.zend.com/engine2/(...)
Damien
[^] # Re: Darkleon >Tout ça, c'est du marketing...
Posté par Yann Bloch . Évalué à 1.
you create a new object you will be getting a handle to the object instead of the object
itself. When this handle is sent to functions, assigned and copied it is only the handle
which is copied/sent/assigned. The object itself is never copied nor duplicated. This
results in all handles of this object to always point at the same object making it a very
consistent solution and saving unnecessary duplication and confusing behavior.
C'est tres interessant. C'etait mon principal reproche a la POO en PHP.
Par contre, je plains les developpeurs qui devront reecrire leurs bibliotheques de classes pour les faire coller au nouveau paradigme.
D'autres trucs sympas que j'ai lus : l'heritage multiple, les membres prives, statiques, la gestion des exceptions, etc...
Bref, on se rapproche de Java.
# Support de données persistentes et PHP précompilé.
Posté par Anonyme . Évalué à 0.
1- L'identifiant peut est propagé de façon transparente par l'url ou les cookies
2- Les données peuvent est stocké n'importe où (mémoire partagée, fichiers, base de donnée ...).
CF la doc.
Pour du PHP précompilé :
http://apc.communityconnect.com/(...)
The APC Caching module is an open source alternative to Zend's caching engine. The APC caches compiled PHP code so that the PHP interpreter doesn't have to recompile pages on each and every request.
Et le code précompilé peut est mis en mémoire partagée aussi. j'ai testé sur un site, le gain va jusqu'à 2 (maximum).
PS : le comparatif n'est pas objectif.
# et Zope ?
Posté par Eudoxe . Évalué à 1.
J'ai commencer à apprendre Zope (je connais déjà Python). Est ce que quelqu'un peut me donner un avis objectif (à peu près) sur ce serveur applicatif ?
# Un exemple d'utilisation de JSP
Posté par Daniel Le Berre (site web personnel) . Évalué à 1.
Sun a change dernierement de logiciels de forum sur son site "Java Developer Connection":
http://forum.java.sun.com/(...)
Le nouveau forum est maintenant gere par un logiciel jusqu'a present Open Source, Jive:
http://www.jivesoftware.com/(...)
C'est du pur Java/Servlets/JSP, et ca marche tres bien (grace a un tres bon systeme de cache).
Jugez par vous meme,
--Daniel
# Aparté PHP
Posté par truelle . Évalué à 1.
Par contre, concernant le PHP, il s'agit d'un langage que j'aime beaucoup car je le trouve très clair (contrairement au Perl), et la communauté autour de PHP est dynamique. Il n'est pas rare de trouver des fonctions toutes faites sur un sujet alors qu'un mois auparavant, il fallait se palucher ce travail manuellement.
C'est malheureusement aussi le revers de la médaille : Je réutilise rarement mon code PHP car il est toujours has-been (pour la gestion des sesssions, par exemple).
Pour finir, la plupart des problèmes que je rencontrent sont rarement du au code PHP, Perl ou autre mais plutôt à l'interprétation du code HTML par le navigateur (apsect IHM). Sur ce sujet, par contre, il y à matière à dénigrer.
# Hébergement
Posté par Anonyme . Évalué à 0.
Il me semble que trouver un hébergeur pour une appli développée en php est autrement plus facile que de trouver un hébergeur qui accepte vos pages JSP + vos JavaBeans + votre framework qui va bien + éventuellement d'ajouter 2 ou 3 jar au CLASSPATH + ....
Je me trompe ???
Bob
[^] # Re: Hébergement
Posté par benjamin truquet . Évalué à 1.
# Petite Réponse
Posté par Anonyme . Évalué à 0.
plusieurs choses :
>Java à une interface d'abstraction de connexion au bases
Faux, PHP aussi cela se trouve dans PEAR.
>- Les serveurs applicatif java peuvent se greffer sur tous les serveurs WEB
du marche, php ne doit (a vérifier) que fonctionner avec Apache et IIS
Faux PHP se greffe sur tout types de serveurs avec son interfaces ISAPI une petite liste de serveurs (Apache,CGI,fhttpd,Caudium,IIS,PWS,Netscape,iPlanet,OmniHTTPd Server,Oreilly Website Pro,Xitami,...)
>- enfin, mais ça a son importance, JAVA est soutenu par un grand nombre de
TRES grand noms de l'informatique : SUN, IBM, ORACLE...
est-ce une garantie ? PHP est développé par un collectif de plus de 300 bénévoles ...
>Pour de petits applicatifs qui n'ont vraiment aucune raison (même a long
terme) d'être connectée au système d'information de l'entreprise le choix
PHP semble s'imposer. Pour le reste, je conseille fortement JAVA...
l'API d'extension de PHP est trés bien concu est permet de s'interfacer a toutes librairies en C avec une facilité déconcertante !
pour ceuw qui est de l'utilisation de PHP
http://www.securityspace.com/s_survey/data/man.200106/apachemods.ht(...)
37,77% des serveurs Apache utilise PHP
je crois que le nombre de serveur qui tourne sous Java est un peu moins important ApacheJServ ou Jakarta sont loin de ca.
Enfin ce genre d'article est du pur troll ca aurait même du passer a la modération .....
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.