détrompe toi, avec les nouvelles versions, Seam supporte d'autres serveur que JBoss.Citation:
Envoyé par OButterlin
Version imprimable
détrompe toi, avec les nouvelles versions, Seam supporte d'autres serveur que JBoss.Citation:
Envoyé par OButterlin
Pour l'instant, d'après leur site, il n'y a quand même que ces serveurs :Citation:
Envoyé par Sniper37
JBoss Application Server 4.2.X
JBoss Application Server 5
IBM Websphere
BEA WebLogic
Oracle OC4J
Apache Tomcat
Maintenant, je ne pourrais pas dire ce qui empêcherait de le faire tourner sur d'autres serveur (comme JRun par exemple)
D'autant que Prototype ou JQuery facilitent pas mal la tâche.Citation:
Envoyé par OButterlin
Les applets sont largement sous-utilisées ! Cela permet de developper rapidement l'IHM et, contrairement à Javascript, d'avoir un langage typé avec des tests unitaires simples à mettre en place. Bref, facile à entretenir.Citation:
Envoyé par OButterlin
C'est là qu'est l'echec total de JSF : le but fondateur est de faire ses propres composants. C'est aussi un peu le même échec des composants Javabeans en Swing qui sont pourtant (un peu) plus simples à creer (pub : j'en parle justement aujourd'hui dans mon blog :mouarf:).Citation:
je pense que c'est une erreur de se lancer dans le développement de composants, ça rendra la maintenance et l'évolution de l'application impossible.
tu as cité plus de 90% de la part de marché des serveurs d'applications.Citation:
Envoyé par OButterlin
Pourquoi comparer GWT à swing? il s'agit quand même d'une application web qui a besoin d'un simple navigateur pour fonctionner.Citation:
Envoyé par OButterlin
le modele de programmation est le meme. on manipule des composants en java, et on ne fait pas de html/js/css (presque pas). Donc pour le développeur, tu es plus proche d'un dev swing, que d'un dev web habituel.Citation:
Envoyé par Sniper37
Rien ne t'empêche d'utiliser swing dans une applet et donc dans une page web.Citation:
Envoyé par Sniper37
ouii mais l'avantage de GWT c'est que tout est fait coté client, la session est géré dans le client, en plus, les requêtes sont asynchrones, c'est de l'ajax ... et surtout c'est plus flexible..il y'a plus d'interaction avec l'utilisateur..Citation:
Envoyé par OButterlin
je ne suis pas un inconditionnel de GWT, d'ailleurs, je n'ai pas encore réaliser une vrai application métier en GWT, mais, la comparaison avec swing s'arrête pour moi au principe de composants développés sur le serveur..
C'est marrant parce que je viens juste d'écrire un AjaxEvent et un AjaxListener pour mon Applet. Et ca marche TROP BIEN ! :yaisse2:Citation:
Envoyé par Sniper37
fait fonctionner ton applet sur le navigateur de la Wii, de la ps3, d'un pc en entreprise qui n'a pas java d'installé :aie:
l'avantage de GWT, c'est de rester full standard, et de ne pas reposer sur un plugin. Apres, si tu peux te permettre de réduire l'audience d'un site/application l'applet est un bon choix. mais si tu fais un site de ecommerce, (par exemple), la cible c'est le maximum possible.
JSF est sympa conceptuellement et se justifie bien pour des projets nécessitants une logique métier importante. Je pense par exemple à une application de télédéclaration.
Le coté standard n'est a mon sens pas du tout justifier :
- Sans autre librairie, JSF est inutilisable ou presque (facelet, iceFaces) Elle ne sont nullement standard
- Est ce que parce que SUN créé une JSR et l'inclut dans les spécification J2EE cela devient un standard ? Personnellement, je ne suis pas trop d'accord avec ce concept. Pour moi un standard est quelque chose issu de plusieurs acteurs qui se sont mis d'accord sur la création commune d'un produit ou quelque chose de reconnu par un acteur définissant des standards (W3C ou ISO par exemple). A la rigueur si une technologie est fortement répandu on peut la définir comme un standard. Mais ce n'est pas le cas de JSF.
Au dela de cela cette technologie est quand même assez lourde à mettre en oeuvre. Et repose sur des concepts évolué (rien que la lecture du cycle de vie de l'application JSF permet d'entrevoir la complexité du bouzin)
Quant a GWT, c'est pas mal mais c'est limité (du moins dans les version que j'ai testé). Comme on l'a déja écrit pas de MVC intégré par défaut mais la création d'un mvc performant est réalisable coté java. De plus, le tout ajax/js permet difficilement de faire des pages bookmarkables. Enfin le coté boite grise (puisque le code est ouvert sauf erreur) ne me plait pas trop.
Moi je te conseille de voir a ce qui se fait ailleurs. Wicket est sans doute tres bien et supporter par apache. Personnellement, je suis fan de Grails qui est assez industriel avec sa couche spring et qui viens d'etre racheté par SpringSource.
Ce que tu cite correspond parfaitement à ce que peut faire un applet.Citation:
Envoyé par Sniper37
En fait le seul réel avantage de GWT par rapport à un applet à ce niveau est de pouvoir se passer de machine virtuelle java.
Personnellement, j'ai développé des applis JSF et des applis GWT, et... comment dire... ça n'a rien à voir !!!
La productivité coté GWT est 10 fois meilleure, car on ne manipule qu'un seul langage (Java) au lieu du tryptique JSF/JSP/HTML.
De plus, coté pérennité, JSF a du plomb dans l'aile :
- Son modèle de navigation (page à page) ne correspond plus aux demandes clients
- Sun pousse JavaFX qui n'a rien à voir avec JSF
- Les divers serveurs d'application sont en train de migrer vers d'autres frameworks de présentations (Flex, GWT, ...)
Donc, GWT est loin d'être parfait (temps de compilation, librairies graphiques tierces nécessaires, etc...), mais il a à mon avis plus d'atout et d'avenir que JSF.
Bruno
PS : (petite pub perso) intégration Hibernate avec GWT -> http://gilead.sourceforge.net (ex-hibernate4gwt) 8-)
Change de clients, ils n'ont rien compris au web :mouarf::mouarf::mouarf:Citation:
Envoyé par bmarchesson
Personnellement,
c'est le concept même de développer avec une technologie qui ne sert qu'à produire du code pour être réinterprété par une autre qui me dérange.
Et pour moi, ayant essayé GWT, le problème il est là avant tout. Sans celà, je trouve que GWT fait beaucoup trop bidouille. C'est dérangeant ce décalage entre ce que tu code et ce que tu obtiens, qui est inévitablement non nul.
Seul JavaScript 2 nous sauvera.
:arf:
Javascript 2, c'est ActionScript 3.0 ;) - puisque tous les deux Ecma-machin.
Faut reconnaître le problème :
- Flash c'est joli mais affreux à programmer
- Javascript est affreux à programmer, mais simple au départ
- Java, c'est pas très beau, et complexe au départ - lent à démarrer la JVM (même avec Java 6 et un super PC).
L'idéal serait que les navigateurs gèrent en natif Java et que Sun fassent des composants sexys.
Ou alors un language avec deux piles distinctes, clientes et serveur
c'est à dire que par exemple dans ton projet, avec ce langage hypotétique, tu distinguerais la partie serveur ou tu as tes controllers et models, et la partie view serait interprétable uniquement par le navigateur, avec une interface pour la pile serveur. Je dis n'importe quoi mais bon, ce serait techniquement envisageable, je pense.
Ben perso, côté serveur je fais tout en java et pour la présentation j'utilise flex. Entre les 2 soit, BlazeDS, soit weborb.
Ainis d'un bout à l'autre de la chaine on ne fait que manipuler des objets.
je trouve que malgré tous ses framework, un temps fou est passé sur le UI à cause de toutes des différences d'interprétations html, javascript et cie... alors qu'avec un client lourd ce problème existe pas...
si j'aurais a refaire les applications que j'ai dû faire en entreprise, je pousserais d'avantage sur les chargé de projet pour que Java Web Start soit utilisé
:king:Citation:
Envoyé par nicorama
(et pas tout à fait faux d'ailleurs...)