elamapi a écrit 335 commentaires

ben tu a la gestion des socket en php :)

donc bind, accept, ensuite si mes souvenir son bon
avec jabber c'est du XML qui passe donc tu utilise ton joli parser XML php (y en a plein) et tu cause à ton jabber :)

mais meme si ca reste faisable, ca reste de la magouille, je vien de capter ce qui me manquait (post plus pas)

c'est la persistance des processus (pas de données).

en ram aussi vivi mais j'ai enfin compris ce qui me manquerai vraiment entre PHP et J2EE.

ce n'est pas la persistance des données, ca y a toujours moyen de ce debrouiller.


C'est la persistance des processus.

A part la grosse magouille, je ne peut pas laisse tourner une tache de fond sur mon apache.

Enfin je vois bien une methode, mais il faudrai un serveur web pur php, plus une normalisation etc ... je ne pense pas que ca esiste deja.

pas besoin de couche ni de passerelle. Le hic ne vient pas de la. c'est la persistance qui fait défaut dans le cas présent.

si tu veux tuer le troll , tu choisiras le langage le plus qui te permettra a et a ta société de développer le projet demandé le plus rapidement possible/avec le moins de personne possible/le plus maintenable et evolutif.

Ca dependra donc de chaque application:

si tu doit ecrire un MMORPG avec un graphisme de fou -> c++
si tu doit ecrire hello world -> bash devrai suffire etc ...

a alors je ne comprend pas.

Dans ce cas, tu peut tout aussi bien ecrire ton application/applet java qui communique avec un serveur php.

je vois ce que tu veux dire, simplement ton exemple est mauvais.

Le panier comme tu dis sera stocké en DB, la DB à un cache en ram, il n'y aura pas plus d'accés disque qu'avec J2EE.

par contre est ce que quelqu'un a des graphe de bench au niveau de l'utilisation ram/disk sur des applications equivalentes ? (entre php/apache et j2ee)

j'entre apercois le truc.

En gros tu developpe une appli qui aura la meme interface sur une page web que sur une application/applet java ?

Effectivement la je vois l'interet, mais dans ce cas, peut on systematiquement avoir l'equivalent HTML d'une applet/application java ?

ben heu .... tu peux faire la meme chose avec n'importe quel serveur apache en fait.

et tu le met ou ton jsp ?

Ok, je n'avais pas saisi. donc si j'ai bien compris tu programmes le checker de rdv et tu le met dans la "cron" interne de jboss par exemple ?

Oki pour le hello world par contre:

>>>tu n'as pas possibilite de reutiliser autant de librairies qu'en Java
j'ai pas compris la ? je ne vois pas ce qui empeche de reutiliser du code php ?

>>>un vrai langage objet
mouais faut voir pour php 5. Evidement c'est pas au niveau de java.

>>>les avantages de J2EE sur un simple Hello world
ben justement, a partir de quel niveau ca devient interessant, parceque c'est ca que j'essais de determiner?

En gros c'est histoire de savoir si un jour j'aurai l'utilité de developper avec J2EE (donc je m'y met plus serieusement) ou alors si J2EE ca sert uniquement a creer des application pour gerer des centrale nucleaire avec 10E100000 lignes de code et 100 personnes deriere auquel cas, ca ne me servira probablement jamais.

Absoluement pas. je te l'ai dis, je ne suis pas expert J2EE donc je pose simplement une question.

meme réponse que plus haut, vous parlez d'applet/application en mode connecté (pke si la connexion n'est pas persistante, rien n'est plus facile que de monter un cluster et de distribuer la session, meme en bash :) ).

Otes moi d'un doute, t'a une jolie applet java (ou alors une application java) pour faire ca ?

lol, juste un gag :)

ecrire hello world , une fois pour J2EE , une fois pour PHP/apache

http://www.phpmvc.net/(...)
http://www.mojavi.org/(...)
http://www.phppatterns.com/index.php(...)

j'ai que cela en tete. l'argument ne tient pas.

Heu, tu peux détailler stp ?

je suppose que ton serveur ne devine pas tout seul qu'il faut envoyer un mail,

donc je supose que tu dois ecrire une parti serveur qui va checker les rdvs et envoyer le mail,

je supose toujours que tu dois "activer/lancer" l'action de checker les rdvs pour envoyer les mails ?

Si tel est le cas tu peu faire la meme chose avec PHP/apache (uniquement sans cron ni programme externe).

5 minimum

scusez mon ignorance mais je viens de lire qu'il n'existe pas de plugins flash pour mac ? est ce exact ? ai-je mal compris et l'auteur a t il voulu dire qu'il n'existait pas de plugin flash pour Linux ppc ? et si tel est le cas, ne peut on faire tourner ce plugin avec Wine (car si tel est encore le cas, le plugin flash tournerai sur vraiment beaucoup d'archi).

merci

J'ai travaillé au developpement d'applications web avec Zope (4 ans tout de même!), j'en connais qui tournent, je connais des célébrité comme plone et je connais trés bien le langage pyhton.

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

Bon, j'ai renoncé à tester jonas pour jboss, carrement plus simple à mettre en oeuvre. Un trés bon point pour lui.

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).

30Mo pour rien faire c'est pas "enorme??????"

Ben merci pour le lien, pke sinon, c'est pas super clair leurs indications pour installer une plateforme J2EE.

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

je teste de ce pas l'install d'une plateforme J2EE pour voir si c'est aussi simple qu'annoncé.

Je connais l'existance du langage java. J'ai déjà programmé avec ce langage (sans être un expert je sais quand même faire quelques trucs). Je connais les grands concepts de ce langage (mais a amha pas les subtilité).

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 ?