Meilleur composant pour interface graphique

Bonjour

J'aimerais développé une interface graphique pour une application Web et je ne suis pas certain de ce que je dois utiliser car il existe plusieurs choses comme Swing, AWT, ...2D, 3D, ......

Je vais utiliser Java/javascript avec Netbeans et je veux aller directement travailler avec le meilleur outil.

Cette interface contiendra un menu, des sous menu, des boutons, un progress bar, ...

Voici les critères :

- Rapidité de développment
- Convivialité
- Look attirant

Qu'est ce que vous en pensez ?

Merci.

Si c'est du Web, ce n'est pas du client lourd donc swing, spring ou awt ????je pense pas.

Du coup tu n'as plus trop de choix. JSF permet de customiser l'interfacce un peu plus que strust. Mais tu restes limité au HTML dans la majorité des cas. Moi je prendrais du jsp natif ou de l'hibernate et je mettrais de l'AJAX par dessus. Comme ça du fais de l'interface comme sur un client lourd (donc plein de trucs joli partout) et tout ça en mode Web. C'est pas génial ??

Tu peux faire une appli web avec un client lourd, tout depend de son utilité, si c'est une appli ouverte à tout les internautes il te faudra a priori effectivement une interface web HTML classique mais si c'est un intranet je pense qu'il faut clairement se lancer dans un client lourd swing, les possibilité sont bcp plus grande.
Pourquoi faire du web dans une appli en intranet ??
Je travaille actuellement sur un intranet qui a ete fait en web et cette appli doit permettre la saisie de masse et aucun client n'est satisfait du passage au web (ils etaient en VB avant), le web est une mode on se lance dedans sans reflechir, c'est une erreur, d'autant plus qu'on peut tres bien faire une appli en client lourd se connectant a serveur contenant le "metier" ce qui rend le client bcp moins lourd.

Enfin bref si tu peux fais du swing.

Tout à fait d'accord avec le principe du client lourd. Mais même dans un intranet, c'est beaucoup plus simple d'avoir une appli en mode web.

Pourquoi ? La maintenance notamment puisque le déploiement est instantané. Si l'entreprise à 500 postes et que tu dois passer sur tous les postes pour déployer ton app c'est la mort.

Aujourd'hui tout le monde s'accorde à dire qu'un client Web est beaucoup plus intéressant car moins permissif pour l'utilisateur. ET qui plus est avec AJAX, tu peux construire des interfaces très évoluée avec plein de widgets et même du drag and drop. Si tu veux permettre un accès extranet ensuite tu peux très facilement le faire.

Citation:

---

Pourquoi ? La maintenance notamment puisque le déploiement est instantané. Si l'entreprise à 500 postes et que tu dois passer sur tous les postes pour déployer ton app c'est la mort.

---

C'est la le role de JWS (Java Web Start) lorsque tu lance une appli web start elle va automatiquement verifier sur le serveur si une version plus recente est presente si oui elle la telecharge, tout ca est automatique plus besoins de passer sur les poste client.

En ce qui concerne l'AJAX ca reste du Javascript et question facilité de dev et clareté "c'est la mort" :)

Perso je trouve bcp plus simple de faire du java de bout en bout IHM et dev metier.

Sur le principe de l'update sur chaque client c'est vrai que le fonctionnement de JWS est pas mal mais le client garde le controle sur son appli non (choix d'updater ou non??).

Sinon concernant AJAX, j'ai vu des choses très propres du côté des frameworks ZK ou autres. Forcément tu ne comprends pas tout ce que tu fais mais le code est très correct.

Sinon c'est vrai que tout codé en java pur est bien mais pas très utile dans bien des cas. L'architecture métier de java (dc du J2EE apriori est très lourde et gourmande en ressource). Sur des énormes volumétrie il s'avère que le java devient vite débordé. Du C ou du shell se prête mieux à la problématique métier d'après moi. La encore c'est une question d'habitude ou plutot de contraintes (bonjour aux clients :) ).

Jsp et Hibernate ne sont pas comparables puisque ils ne traitent pas des même choses.

Je suis d'accord avec FreshVic pour dire qu'une appli Swing est plus agréable pour l'utilisateur. En ce qui me concerne, je préfère développer sous Swing que développer une application Web.
Certains disent que développer avec Swing est plus long et plus compliqué.
Moi, je n'en suis pas tout à fait convaincu.

Citation:

---

Sinon c'est vrai que tout codé en java pur est bien mais pas très utile dans bien des cas. L'architecture métier de java (dc du J2EE apriori est très lourde et gourmande en ressource). Sur des énormes volumétrie il s'avère que le java devient vite débordé. Du C ou du shell se prête mieux à la problématique métier d'après moi. La encore c'est une question d'habitude ou plutot de contraintes (bonjour aux clients ).

---

La critique de la lourdeur, des perfs et des ressources ne tient pas la route.

Pouquoi la lourdeur et les perfs n'est pas un argument qui tient la route?

On ne peut pas nier que lorsque la partie métier d'une appli est full java, il faut un gros serveur bien puissant même sur des petites volumétries. Et lorsqu'on parle de grosse volumétrie :aie: .

Parce que ce n'est pas vrai.
Tout dépend de ton architecture.
Tu peux avoir de bonnes perfs et une achitecture pas lourde du tout en faisant du J2EE.
Et pour de petites applis, un petit serveur peut suffire.

C'est comme dire, Java, c'est lent, ça n'a pas de sens hors contexte.