Architecture : Gui en PHP5 et infra en J2EE ?

test a dit le 22/05/2005 à 22:02:

J'ai envie d'inciter le groupe projet à étudier l'opportunité d'utiliser
PHP5 pour le développement des interfaces utilisateurs

L'interface serait, dans ton cas semble-t-il, déterminée par HTML.
PHP n'est qu'un outil pour dynamiquement générer ce code d'interface en
fonction des données d'entrées (url ou formulaire).

Et tu ferais appel à tes applications comment ? En ligne de commande ?

ou à raison que celà aurait plusieurs avantages : rapport temps de
développement / qualité de l'interface finale favorable notamment.

Oui, effectivement, une interface en HTML est bien plus facile à
développer qu'une interface dite "riche".

Mais je m'interroge sur les inconvénients potentiels :
- est-ce une architecture exotique ?

PHP ? Ça n'a rien d'exotique.

- vais-je de toute façon devoir utiliser des applets Java pour les fonctions
client un peu trop complexes pour PHP qui est exécuté sur le serveur (si je
ne m'abuse) ?

PHP, tout comme n'importe quel langage de programmation, peut presque
tout faire si tu lui en donnes les moyens.
La seule limitation, c'est la performance. Enfin normalement, c'est pas
vraiment pire que Java.

- l'absence d'intelligence sur le client va t'elle me pénaliser ?

C'est possible. Tu es soumis aux limitations d'HTML.
Tu peux néanmoins tenter d'améliorer la chose avec Javascript.
Mieux encore, utiliser la méthode que l'on appelle "ajax" et dans
l'idéal XUL.
Avec XUL, sur un intranet, tu peux vraiment t'amuser.

- est-ce que je vais plus perdre à mélanger deux langages qu'y gagner ?
bref, est-ce farfelu de faire du J2EE pour les composants de base, et PHP
pour le front end ?

Je crois que le créateur de PHP faisait ça mais avec du C en backend.
Enfin personnellement, je ferais plutôt tout dans le même langage, et je
choisirais plutôt PHP, pour des raisons de goût notamment.

Sinon il serait intéressant d'utiliser XUL et d'appeler directement via
CGI ou autre tes applications J2EE.

j'aimerais avoir quelques avis éclairés... et potentiellement différents de
celui des grands cabinets de conseil.
J'ai commencé à faire des appli web en perl puis php et je suis passé à

java pour les projets professionnels

Je ne vois pas l'interêt d'utiliser php pour faire l'interface d'un
application java ! Java (avec les servlet et jsp) est tout à fait
capable de faire ce que fait php.

L'avantage d'utiliser une même technologie pour la partie métier et
interface est :
- La facilité de réutilisabilitée (pourquoi devoir créer des objets de
structures identiques en php et en java).
- Un développeur java est capable de maintenir l'application en entier

PHP5 pour ... temps de développement
Mouai, mais s'il faut tout réécrire pour s'interfacer avec le java, je

suis pas sur qu'on y gagne en temps.

- est-ce une architecture exotique ?
Biensûr, comment vont communiquer php et java ? Il va faloir créer les

même objets coté java et coté php ?

- vais-je de toute façon devoir utiliser des applets Java ...
Pas forcément, bon nombre d'application aussi compliquées soient-elle

fonctionnent en html pur (avec un peu de javascript aussi)

- l'absence d'intelligence sur le client va t'elle me pénaliser ?
Cela n'a pas de rapport avec php, c'est le problème des applications web

qu'elles soient écrites en C, perl, php, java ou même C#

- est-ce que je vais plus perdre à mélanger deux langages qu'y gagner ?
Je le pense, ça risque de faire une application dificile à maintenir.

bref, est-ce farfelu de faire du J2EE pour les composants de base, et PHP
pour le front end ?
C'est pas forcément farfelu, mais j'ai du mal à y trouver une justification

En espérant avoir apporté quelques pistes, je précise juste que je suis
un inconditionel de php, mais je trouve qu'il n'est pas toujours adapté
pour gérer des systèmes de gestions complexes.

--
Benoit F.

[...] PHP qui est exécuté sur le serveur (si je ne m'abuse) ?
Bonsoir,

Si vous en êtes à ce niveau de compréhension, vous devriez pour cette phase
au moins, laisser la responsabilité des choix techniques à des gens
compétents.

--
Cléo

[...] PHP qui est exécuté sur le serveur (si je ne m'abuse) ?

Si vous en êtes à ce niveau de compréhension, vous devriez pour cette phase
au moins, laisser la responsabilité des choix techniques à des gens
compétents.

personnellement dans ce projet, j'avais compris que l'interface php
etait en gtk, donc autonome. Je crois effectivement qu'il faudrait
laisser les responsabilités des choix techniques ...

Prenez vos cachets, Cléo, et répétez après moi : "je fais des
réponses constructives" et non pas "je me complais dans l'invective".

"PHP ? Ça n'a rien d'exotique. "

Je parlais du mélange des deux, naturellement.

Prenez vos cachets, Cléo, et répétez après moi : "je fais des
réponses constructives" et non pas "je me complais dans l'invective".

Salut,
Ne vous méprenez pas, il n'y a aucune agressivité dans mes propos.

--
Cléo

Bonjour,

j'aimerais avoir quelques avis éclairés...
Ca, ça reste à voir.

et potentiellement différents de
celui des grands cabinets de conseil.
Ca en revanche ce n'est pas trop difficile à faire.

Pour un vraiment grand projet (genre 4000 utilisateurs simultanés,
Ca ne veut rien dire "4000 simultanés". La seule chose qui compte, c'est

le nombre de requêtes secondes à traiter simultanément. Si tu as deux
paquets de 3999 et de 1 luser, la charge ne sera pas la même selon le
paquet qui est en pause café :-)

national) sur une application métier assez sophistiquée, je suis à peu près
contraint contractuellement
Contractuellement ? Diantre. Peut-être qu'un jour les clients arrêteront

de dire à leurs prestataires comment ils doivent implémenter ce qu'eux
mêmes sont incapables de faire. Bref.

sur une infrastructure J2EE - ce qui, quoi qu'il
en soit, est a priori adapté à la circonstance (sécurité, montée en charge
etc)

Sécurité de quoi ? Il n'y a pas moins ni plus de failles sur une
architecture tomcat+jsp qu'apache+php.

Montée en charge : non, justement. Il n'y a qu'à regarder le superbe site
des impôts, en java machin-chose, qui a été en rideau pendant un mois,
pour bien voir que si on veut tolérer la montée en charge, ce n'est pas
nécessairement du java qu'il faut prendre. Souvenez vous qu'un certain 11
septembre, 1 site d'information boursière est resté en ligne, 1 seul:
boursorama. Il tourne sur php. Tout le reste est parti en vrille.

et au budget (significatif).
Quel est le rapport ? Si le client veut quelque chose qui coûte cher pour

se rassurer parce que "si c'est cher c'est bien", il n'est pas difficile
d'augmenter la marge...

L'outil Eclipse sera vraisemblablement
utilisé pour le développement.
Ca, on s'en fout (même si Eclipse est tout à fait acceptable pour

développer en php, donc on peut en effet avoir le même IDE pour les
deux, mais peu importe car ce ne sera probablement pas la même équipe).

Mais je m'interroge sur les inconvénients potentiels :
- est-ce une architecture exotique ?
Inhabituelle oui.

- vais-je de toute façon devoir utiliser des applets Java pour les fonctions
client un peu trop complexes pour PHP qui est exécuté sur le serveur (si je
ne m'abuse) ?

Aucune différence par rapport à une solution où il y a du java sur le
serveur.

- l'absence d'intelligence sur le client va t'elle me pénaliser ?
Impossible de répondre sans connaîre les besoins / le cahier des charges,

et aucune différence par rapport à une solution avec java côté serveur.

- est-ce que je vais plus perdre à mélanger deux langages qu'y gagner ?
etc etc

Strictement impossible de dire sans connaître l'application.

bref, est-ce farfelu de faire du J2EE pour les composants de base, et PHP
pour le front end ?

Tu risques de devoir développer deux fois les mêmes fonctionnalités et les
maintenir deux fois. Ce n'est pas obligatoire, mais c'est possible.
Impossible de dire sans savoir ce que fait l'appli (et surtout sasn
connaitre ses flux de données).

Tu risques des problèmes de compatibilité ou de portabilité si un imbécile
décide, par exemple, de chiffrer les mots de passe dans la base de données
(c'est de la sécurité par le petit bout de la lorgnette, donc très à la
mode).

Quand j'étais au Bureau de l'AFUP, nous répondions (gratuitement, et
surtout, sans mettre nos boites en avant) à ce genre de questions et de
problématiques. http://www.afup.org/

En revanche, il faut clairement avoir été bercé trop près du mur pour, sur
une machine de production d'une application un peu critique, instancier
des classes java en php et réciproquement. Se méfier de tout discours
concernant de genre de délires (à la mode en ce moment aussi).

a++;
JG

"cleo" <cleo@no-spam.net> a écrit dans le message de
news:429204f2$0$7546$626a14ce@news.free.fr...

Prenez vos cachets, Cléo, et répétez après moi : "je fais des
réponses constructives" et non pas "je me complais dans l'invective".

Salut,
Ne vous méprenez pas, il n'y a aucune agressivité dans mes propos.

L'invective peut se faire dans le velours. Elle est d'autant moins plaisante
qu'elle ne s'accompagne même pas d'une tentative de réponse. Ce qui fait que
nul ne sait si vous même avez la compétence pour juger de la mienne...

...et qu'est ce que vous fais penser que je suis un décisionnaire pour
motiver votre intervention ?

(Pour finir, ca fait longtemps que les choix technologique stratégiques des
grands projets ne sont plus laissés aux techniciens :-)

John GALLET a dit le 23/05/2005 à 19:49:

Tu risques des problèmes de compatibilité ou de portabilité si un imbécile
décide, par exemple, de chiffrer les mots de passe dans la base de données
(c'est de la sécurité par le petit bout de la lorgnette, donc très à la
mode).

Je ne comprends pas ce commentaire.