détrompe toi, avec les nouvelles versions, Seam supporte d'autres serveur que JBoss.Envoyé par OButterlin
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
détrompe toi, avec les nouvelles versions, Seam supporte d'autres serveur que JBoss.
Articles: Richfaces - JBosstools pour JSF.
Pour l'instant, d'après leur site, il n'y a quand même que ces serveurs :
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.Ceci dit, on nous parle de web2, ajax etc... et on voudrait s'affranchir de javascript ? Syntaxe error
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.
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 blogje 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.
Articles: Richfaces - JBosstools pour JSF.
Pourquoi comparer GWT à swing? il s'agit quand même d'une application web qui a besoin d'un simple navigateur pour fonctionner.On a, l'année dernière, tenté GWT, c'est lent, lourd et franchement, s'il s'agit de réinventer le client lourd, autant utiliser swing
Articles: Richfaces - JBosstools pour JSF.
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.
Rien ne t'empêche d'utiliser swing dans une applet et donc dans une page web.
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..
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..
Articles: Richfaces - JBosstools pour JSF.
C'est marrant parce que je viens juste d'écrire un AjaxEvent et un AjaxListener pour mon Applet. Et ca marche TROP BIEN !
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é
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.
Et pourquoi que ces deux la.
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.
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)
Change de clients, ils n'ont rien compris au web
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.
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.
Java + Flex
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é
Change de clients, ils n'ont rien compris au web
(et pas tout à fait faux d'ailleurs...)
Répondre avec citation
Partager