A mon avis, ce site a bcp d'avenir.
Il est en francais.
Il est assez oriente open-source.
Il presente l'actualite des application servers, et des technologies associees.
L'article est un bon point d'entree dans ces nouvelles technologies du Web.
A voir sur leur homepage! MDR;-) Ils devraient déposer un brevet :-)
Ils ont la même approche du web que mon CTO qui n'y connait rien!
Genre: le web, c'est pas pour les mauviettes! Pour faire un bon site dynamique, il faut un serveur d'application, du XML, du jsp, une archi trois-tier,.......Les langages de scripts (php,asp,...) c'est pour les rigolos qui font des sites persos de 3 pages foireuses.
Je n'ai rien contre java mais je constate que le marketing de Sun a réussi à rattraper le retard qu'ils avaient pris dans le web. Maintenant, pour qu'un site soit bon, il faut qu'il soit en java. C'est vrai que c'est dégradant pour un développeur de faire du html tout con. Non. En passant par du java, de l'XML, du JSP, on se démarque de ces graphistes à la con (je suis moi-même développeur) qui se la joue parce qu'ils savent faire du php. Là, ils pigeront que dalle, cool.
Tout ça pour dire qu'il n'existe pas un language qui soit excellent dans TOUS les domaines. Je n'ai rien contre les applications dont ils parlent. C'est le discours "c_est_comme_ça_qu_il_faut_faire!" qui colle pas.
Pour un site sur le java c'est un peu normal qu'il soit pro-java, c'est comme si linuxfr commençait à ne plus venter les mérites de linux.
Concernant tes critiques, "c_est_comme_ça_qu_il_faut_faire!", l'auteur donne son avis et c'est son droit et en plus il apporte une argumentation.
C'est ce droit que j'applique en donnant mon avis sur son avis.
Quand il dit:
>Ces technologies sont adaptés aux développements >de " petits "sites,
>c'est-à-dire de sites ayant peu de types de pages >dynamiques mais ils s'avèrent
>limités pour des applications web ayant plusieurs >dizaines de types de pages dynamiques
Je ne suis pas d'accord et je le dis. That's all.
Et toi, où sont tes arguments? C'est ton patron le gars ou quoi? Il faut dire amen à tout ce qu'il dit?
Je crois que l'auteur a déjà très bien exposé les arguments que je partage.
Je ne te reproche pas du tout de critiquer mais de faire un procès d'intention en parlant du marketing de Sun et en faisant dire ou pensé à l'auteur des choses qui n'a jamais dit (l'auteur pense que le php,asp et autres sont de la merde). Ou alors j'ai raté ce passage. Il ne sont pas destinés au même type d'usage, c'est tout ce que j'ai pu noté. C'est vrai que le choix du mot "petits" n'est pas approprié mzis est-ce que le php est adapté pour des applications ayant plusieurs dizaines de types de pages dynamique ?
Je ne sais personnellement pas trop, je ne connais pas bien le php mais les serveurs d'application java offrent une excellente solution.
Une seule solution à tous nos problémes, ça n'existe pas (microsoft est un bon exemple dans le domaine de l'informatique, je pense). C'est de la désinformation, cet article (Il aurait pû faire un effort pour les schémas!). Si java est une si bonne solution que celà, pourquoi cite-t-il php et asp?
Un seule solution b'existe pas et c'est plutôt une bonne chose.
L'article est un peu leger, jes suis d'accord et je l'ai souligné. Mais dire que c'est de la désinformation je ne suis pas d'accord. C'est une bonne présentation d'une solution globale mais si elle est un peu legere et aurait merité plus d'argument. Et les schémas sont vraiment pourris.
Je t'explique l'interret des serveurs d'applications et donc de Java et JSP.
Il y a 20 ans lorsque tu allais dans une agence de voyage pour commander. La nana, elle se connectait en VTx sur le mainframe du siege pour voir ce qui restait de libre. (VTx : mode texte, les plus connus sont VT25, VT40 et VT100).
A l'époque toutes les applications d'entreprise fonctionnaient comme ca.
Ensuite, est venu le temps des interfaces Windows, au plus grand plaisir de MS.
Maintenant, il semblerait que HTML soit devenu le remplaçant universelle de VTx pour acceder à des applications d'entreprise (ce qui a fouttu les boulles a MS car Windows ne devient plus obligatoire)
Et dans 10 ans, il y aura encore autre chose pour l'interfacage, mais le coeur des traitements (metier), ce sont les memes.
Lorsque tu payes une application d'entreprise plusieurs millions de francs (celle qui se trouvait et qui peu encore se trouver sur le MainFrame d'il y a 20 ans).
Tu n'as pas envie de refaire de gros developpement pour adapter ton logiciel à une nouvelle interface tous les 5 ans.
Les serveurs d'applications apportent une solution, en separant ce qui est graphique de ce qui est metier.
En plus avec Java, meme le systeme et le hard peuvent evoluer, sans poser de probleme.
Sun Microsystem, IBM et d'autre en apporte la garantie.
PHP est tres bien pour faire un site en HTML.
Pas pour faire une application d'entreprise qui est sense durer 20 ans. Independament des evolutions techniques autour de lui.
Si demain PHP ne plait plus, et que personne ne poursuit le developpement. Alors, à moins de le faire toi meme, tu te fais niquer.
Enfin, je n'ai jamais vu de Benchmark, mais je pense que les JSP sont plus performant que PHP. Il tire profit des JIT et des systèmes de pool de Thread. Mais je ne connais pas bien PHP, peut etre que ca existe aussi.
J'espere que quand tu dis 'les JSP', tu n'inclues pas 'le JSP' tout court, c'est a dire, les scripts interpretes en temps reel. Car la il est clair que PHP est bien plus rapide. Par contre, les servlets, qui sont du java byte code, sont probablement plus performantes.
Il existe une regle de transformation permettant de convertir une JSP en servlet. Au premier accès de la page, la transfo va faire ramer, et pas qu'un peu :), mais ensuite, on accédera à la servlet compilée. Donc au final, entre JSP et servlet, ya pas de différences de vitesses.
Leur cycle de vie est simplement différent ...
L'avantage des JSP par rapport aux servlets c'est defaciliter la création de pages générant du flux texte pour HTTP, alors que les servlets restent plus generique (on peut aussi générer du flux pour d'autres protocoles).
Un page JSP, la toute (toute) premiere fois quelle est appellée depuis une modification est traduite à la volée par le containeur de JSP en servlet (translateur/compilateur) qui va etre ensuite exécuté par le container de servlet (ton serveur de servlet, par ex. Tomcat).
Par la suite cette classe sera utilisée directement à pleine vitesse !
(en cas de changement de la page, le cycle recommence ...)
Le gros avantage des JSP/Servlet est leur capacité de s'adapter aux besoins : besoin de puissance = choix du serveur large et architectures différentes, besoin de connectivité = connection J2EE directe ou utilisation de taglib XML.
Le cycle d'apprentissage est netement plus lourd que PHP, mais ca reste un outil formidable car puissant efficace et simple (malgres-tout).
Pour un petit site je conseille PHP, mais pour un site d'entreprise, JSP fait vraiment l'affaire, surtout qu'il y a pas mal de projets opensource super puissants (TOMCAT + EJBOSS + JIVE + JetSpeed + ...)
ah ok, autant pour moi, je savais qu'il y avait moyen de faire du JSP->Servlet, mais pensais naivement que ce n'etait pas automatique. Cela dit, je suis entierement d'accord, pour un gros site les JSP permettent de coder bien plus modulerement et proprement. Ce qui me gene notemment avec PHP, c'est d'une part la gestion des sessions (du moins avec php4), dont le comportement est parfois plus que bizarre, mais surtout le templating (je n'ai pas encore trouve d'outil serieux pour en faire). Par rapport au cycle d'apprentissage, ben ca depend, si on a un background de programmation objet, c'est quammeme rapide, surtout que tout ceci est quammeme extremement bien documente.
Et pour les JSP comment tu utilises des templates ? Tu intègres ton code directement dans ton java ? Je trouve ca encore plus porc ! A moins qu'il y ait un système que j'ai loupé ?
En fait pour php j'ai trouve des trucs pour le templating, mais aucuns ne permettait de faire des loops, ce qui est quammeme un peu genant. Bon, j'ai pas beaucoup cherche aussi, et je suis sur que ca existe, une url sera bienvenue :)
D'accord mais dans l'article, je ne vois pas de référence aux applications dont tu parles. Je reconnais que tes arguments sont fondés mais l'auteur parle de java pour le web sinon, il aurait parlé de c,c++ ou même c# pour venter les mérites de java.
>Enfin, je n'ai jamais vu de Benchmark, mais je >pense que les JSP sont plus performant que PHP
Tout ton discours s'effondre d'un coup! Tu tiens le même discours que l'auteur de l'article mais en te décrédibilisant tout seul. Tu dis: "Je ne connais pas PHP...", "Je n'ai jamais vu de benchmark...."
Vues de l'esprit tout ça. La réalité est altérée par tous ces préjugés alors qu'elle est devant vos yeux (dacode gére + de 10 pages dynamiques. 12 au total, je crois...-).
>Si demain PHP ne plait plus,...
Si demain Sun fait faillite, tu reprends java? Tu n'en aurais même pas le droit. Avec des si, on refait le monde donc argument non valable.
Bref, que du pipeau tout ça. J'utilise les 2 (java(appli,servlets,jsp)) et php (web,scripts)) et je sais lequel est le mieux adapté à ce que je veux faire.
Ton discours, adressé à un neuneu, confirme ce que je disait sur le ton "fait_comme_papa_a_dit_sans_reflechir" que prennent certains.
L'ignorance fait dire beaucoup de connerie.
Pour se faire une petite idée niveau performance, on peut déjà visiter http://www.caucho.com/articles/benchmark.xtp(...) .
Cette page présente des benchs effectués par la société qui s'occupe du développement de Resin, un moteur de servlets/JSP/EJB. Evidemment, on peut craindre la subjectivité des tests, mais on peut commencer à se faire une opinion.
a mon avis tu es dans le faux !! php est certaienement plus rapide qu'une application j2ee, par contre il est vrai que les techno java semble plus perenne au yeux des entreprises car indépendante des choix matériels !
Il semblerais que java réponde bien au test de charge, mais d'après les quelques applis que j'ai developpé, je pense qu'avec java pour avoir des performance correcte il faut vraiment bien penser le codage ou avoir une solution cluster avec un sacré puissance pour la mettre en production !!
et pour ce qui est dis plus bas , une application tout servlet est plus rapide qu'une application jsp/servlets car la compilation des jsp n'est pas optimisée voir ce lien:
Olla, olla, les private jokes d'école, c'est peut-être pas très cools pour les autres (n'est ce pas pour les autres ECL qui traineraient sur ce site....).
En plus usurper l'identité d'Auto, c'est pas cool ;-) Pour bien le connaitre, ça m'étonnerait qu'il est posté ici avec le pseudo de Raymond Deubaze (posté tout court ici d'ailleurs).
Ca fait un moment que je connais ce site et c'est vrai qu'il est sympa pour ceux qui s'intéressent aux serveurs d'application java.
Concernant l'article je le trouve un peu "baclé", il sagit plus d'une présentation que d'une véritable argumentation. Ce serai bien que l'auteur revienne sur les différentes parties, en particulier en intégrant les solutions commerciales.
Sinon je rajouterais un petit mot sur un serveur web/jsp/servlet open source bien sympa et recommandé par jboss : http://jetty.mortbay.com/(...)
# Site d'avenir
Posté par Rossel Olivier . Évalué à 1.
Il est en francais.
Il est assez oriente open-source.
Il presente l'actualite des application servers, et des technologies associees.
L'article est un bon point d'entree dans ces nouvelles technologies du Web.
[^] # Re: Site d'avenir
Posté par lucio . Évalué à 1.
Espérons que Linuxfr lui permettra d'avoir un peu plus de lecteurs...
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
>application-servers.com invente le web skinnable
A voir sur leur homepage! MDR;-) Ils devraient déposer un brevet :-)
Ils ont la même approche du web que mon CTO qui n'y connait rien!
Genre: le web, c'est pas pour les mauviettes! Pour faire un bon site dynamique, il faut un serveur d'application, du XML, du jsp, une archi trois-tier,.......Les langages de scripts (php,asp,...) c'est pour les rigolos qui font des sites persos de 3 pages foireuses.
Je n'ai rien contre java mais je constate que le marketing de Sun a réussi à rattraper le retard qu'ils avaient pris dans le web. Maintenant, pour qu'un site soit bon, il faut qu'il soit en java. C'est vrai que c'est dégradant pour un développeur de faire du html tout con. Non. En passant par du java, de l'XML, du JSP, on se démarque de ces graphistes à la con (je suis moi-même développeur) qui se la joue parce qu'ils savent faire du php. Là, ils pigeront que dalle, cool.
Tout ça pour dire qu'il n'existe pas un language qui soit excellent dans TOUS les domaines. Je n'ai rien contre les applications dont ils parlent. C'est le discours "c_est_comme_ça_qu_il_faut_faire!" qui colle pas.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
Concernant tes critiques, "c_est_comme_ça_qu_il_faut_faire!", l'auteur donne son avis et c'est son droit et en plus il apporte une argumentation.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
Quand il dit:
>Ces technologies sont adaptés aux développements >de " petits "sites,
>c'est-à-dire de sites ayant peu de types de pages >dynamiques mais ils s'avèrent
>limités pour des applications web ayant plusieurs >dizaines de types de pages dynamiques
Je ne suis pas d'accord et je le dis. That's all.
Et toi, où sont tes arguments? C'est ton patron le gars ou quoi? Il faut dire amen à tout ce qu'il dit?
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
Je ne te reproche pas du tout de critiquer mais de faire un procès d'intention en parlant du marketing de Sun et en faisant dire ou pensé à l'auteur des choses qui n'a jamais dit (l'auteur pense que le php,asp et autres sont de la merde). Ou alors j'ai raté ce passage. Il ne sont pas destinés au même type d'usage, c'est tout ce que j'ai pu noté. C'est vrai que le choix du mot "petits" n'est pas approprié mzis est-ce que le php est adapté pour des applications ayant plusieurs dizaines de types de pages dynamique ?
Je ne sais personnellement pas trop, je ne connais pas bien le php mais les serveurs d'application java offrent une excellente solution.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
L'article est un peu leger, jes suis d'accord et je l'ai souligné. Mais dire que c'est de la désinformation je ne suis pas d'accord. C'est une bonne présentation d'une solution globale mais si elle est un peu legere et aurait merité plus d'argument. Et les schémas sont vraiment pourris.
[^] # Re: Site d'avenir
Posté par CMO (site web personnel) . Évalué à 1.
Il y a 20 ans lorsque tu allais dans une agence de voyage pour commander. La nana, elle se connectait en VTx sur le mainframe du siege pour voir ce qui restait de libre. (VTx : mode texte, les plus connus sont VT25, VT40 et VT100).
A l'époque toutes les applications d'entreprise fonctionnaient comme ca.
Ensuite, est venu le temps des interfaces Windows, au plus grand plaisir de MS.
Maintenant, il semblerait que HTML soit devenu le remplaçant universelle de VTx pour acceder à des applications d'entreprise (ce qui a fouttu les boulles a MS car Windows ne devient plus obligatoire)
Et dans 10 ans, il y aura encore autre chose pour l'interfacage, mais le coeur des traitements (metier), ce sont les memes.
Lorsque tu payes une application d'entreprise plusieurs millions de francs (celle qui se trouvait et qui peu encore se trouver sur le MainFrame d'il y a 20 ans).
Tu n'as pas envie de refaire de gros developpement pour adapter ton logiciel à une nouvelle interface tous les 5 ans.
Les serveurs d'applications apportent une solution, en separant ce qui est graphique de ce qui est metier.
En plus avec Java, meme le systeme et le hard peuvent evoluer, sans poser de probleme.
Sun Microsystem, IBM et d'autre en apporte la garantie.
PHP est tres bien pour faire un site en HTML.
Pas pour faire une application d'entreprise qui est sense durer 20 ans. Independament des evolutions techniques autour de lui.
Si demain PHP ne plait plus, et que personne ne poursuit le developpement. Alors, à moins de le faire toi meme, tu te fais niquer.
Enfin, je n'ai jamais vu de Benchmark, mais je pense que les JSP sont plus performant que PHP. Il tire profit des JIT et des systèmes de pool de Thread. Mais je ne connais pas bien PHP, peut etre que ca existe aussi.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
[^] # JSP -> Servlet
Posté par Anonyme . Évalué à 0.
les JSP sont des servlets !!!
Leur cycle de vie est simplement différent ...
L'avantage des JSP par rapport aux servlets c'est defaciliter la création de pages générant du flux texte pour HTTP, alors que les servlets restent plus generique (on peut aussi générer du flux pour d'autres protocoles).
Un page JSP, la toute (toute) premiere fois quelle est appellée depuis une modification est traduite à la volée par le containeur de JSP en servlet (translateur/compilateur) qui va etre ensuite exécuté par le container de servlet (ton serveur de servlet, par ex. Tomcat).
Par la suite cette classe sera utilisée directement à pleine vitesse !
(en cas de changement de la page, le cycle recommence ...)
Le gros avantage des JSP/Servlet est leur capacité de s'adapter aux besoins : besoin de puissance = choix du serveur large et architectures différentes, besoin de connectivité = connection J2EE directe ou utilisation de taglib XML.
Le cycle d'apprentissage est netement plus lourd que PHP, mais ca reste un outil formidable car puissant efficace et simple (malgres-tout).
Pour un petit site je conseille PHP, mais pour un site d'entreprise, JSP fait vraiment l'affaire, surtout qu'il y a pas mal de projets opensource super puissants (TOMCAT + EJBOSS + JIVE + JetSpeed + ...)
A tester donc ...
[^] # Re: JSP -> Servlet
Posté par Anonyme . Évalué à 0.
[^] # Re: JSP -> Servlet
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: JSP -> Servlet
Posté par Anonyme . Évalué à 0.
- Webmacro, le plus vieux ( http://www.webmacro.org(...) )
et surtout
- jakarta-velocity ( http://jakarta.apache.org/velocity(...) ) qui suit le meme princippe, mais comble les manques de webmacro.
En fait pour php j'ai trouve des trucs pour le templating, mais aucuns ne permettait de faire des loops, ce qui est quammeme un peu genant. Bon, j'ai pas beaucoup cherche aussi, et je suis sur que ca existe, une url sera bienvenue :)
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
>Enfin, je n'ai jamais vu de Benchmark, mais je >pense que les JSP sont plus performant que PHP
Tout ton discours s'effondre d'un coup! Tu tiens le même discours que l'auteur de l'article mais en te décrédibilisant tout seul. Tu dis: "Je ne connais pas PHP...", "Je n'ai jamais vu de benchmark...."
Vues de l'esprit tout ça. La réalité est altérée par tous ces préjugés alors qu'elle est devant vos yeux (dacode gére + de 10 pages dynamiques. 12 au total, je crois...-).
>Si demain PHP ne plait plus,...
Si demain Sun fait faillite, tu reprends java? Tu n'en aurais même pas le droit. Avec des si, on refait le monde donc argument non valable.
Bref, que du pipeau tout ça. J'utilise les 2 (java(appli,servlets,jsp)) et php (web,scripts)) et je sais lequel est le mieux adapté à ce que je veux faire.
Ton discours, adressé à un neuneu, confirme ce que je disait sur le ton "fait_comme_papa_a_dit_sans_reflechir" que prennent certains.
L'ignorance fait dire beaucoup de connerie.
[^] # Re: Site d'avenir
Posté par Yann KLIS . Évalué à 1.
Cette page présente des benchs effectués par la société qui s'occupe du développement de Resin, un moteur de servlets/JSP/EJB. Evidemment, on peut craindre la subjectivité des tests, mais on peut commencer à se faire une opinion.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
[^] # Re: Site d'avenir
Posté par Anonyme . Évalué à 0.
Il semblerais que java réponde bien au test de charge, mais d'après les quelques applis que j'ai developpé, je pense qu'avec java pour avoir des performance correcte il faut vraiment bien penser le codage ou avoir une solution cluster avec un sacré puissance pour la mettre en production !!
et pour ce qui est dis plus bas , une application tout servlet est plus rapide qu'une application jsp/servlets car la compilation des jsp n'est pas optimisée voir ce lien:
http://www.techmetrix.com/trendmarkers/tmk0300/tmk0300-2.php3(...)
# Sacré Raymond!
Posté par ufoot (site web personnel) . Évalué à -1.
-1 parce que this is a private joke -<8-)
[^] # Re: Sacré Raymond!
Posté par Foxy (site web personnel) . Évalué à 1.
En plus usurper l'identité d'Auto, c'est pas cool ;-) Pour bien le connaitre, ça m'étonnerait qu'il est posté ici avec le pseudo de Raymond Deubaze (posté tout court ici d'ailleurs).
# Oui
Posté par Anonyme . Évalué à 0.
Concernant l'article je le trouve un peu "baclé", il sagit plus d'une présentation que d'une véritable argumentation. Ce serai bien que l'auteur revienne sur les différentes parties, en particulier en intégrant les solutions commerciales.
Sinon je rajouterais un petit mot sur un serveur web/jsp/servlet open source bien sympa et recommandé par jboss : http://jetty.mortbay.com/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.