IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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éveloppement Web en Java Discussion :

Meilleur composant pour interface graphique


Sujet :

Développement Web en Java

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    430
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Octobre 2006
    Messages : 430
    Points : 103
    Points
    103
    Par défaut 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.

  2. #2
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juin 2004
    Messages : 73
    Points : 85
    Points
    85
    Par défaut
    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 ??

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    Avril 2003
    Messages
    509
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Avril 2003
    Messages : 509
    Points : 568
    Points
    568
    Par défaut
    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.
    UML avec VIOLET

  4. #4
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juin 2004
    Messages : 73
    Points : 85
    Points
    85
    Par défaut
    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.

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    Avril 2003
    Messages
    509
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France

    Informations forums :
    Inscription : Avril 2003
    Messages : 509
    Points : 568
    Points
    568
    Par défaut
    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.
    UML avec VIOLET

  6. #6
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juin 2004
    Messages : 73
    Points : 85
    Points
    85
    Par défaut
    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 ).

  7. #7
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    3 274
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 3 274
    Points : 4 141
    Points
    4 141
    Par défaut
    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.

  8. #8
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    3 274
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 3 274
    Points : 4 141
    Points
    4 141
    Par défaut
    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.

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Juin 2004
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : Juin 2004
    Messages : 73
    Points : 85
    Points
    85
    Par défaut
    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 .

  10. #10
    Expert confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    3 274
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 3 274
    Points : 4 141
    Points
    4 141
    Par défaut
    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.

Discussions similaires

  1. Meilleur API pour interface graphique J2ME
    Par raz2008 dans le forum Java ME
    Réponses: 0
    Dernier message: 02/08/2013, 22h03
  2. Cherche tutorial pour interface graphique
    Par Le Pharaon dans le forum Interfaces Graphiques en Java
    Réponses: 1
    Dernier message: 07/04/2006, 17h58
  3. Choix de langage pour interface graphique simple
    Par C_C dans le forum Langages de programmation
    Réponses: 9
    Dernier message: 04/04/2006, 20h12
  4. [Eclipse] Plugins pour interface graphique
    Par Thomas Lebrun dans le forum Eclipse Java
    Réponses: 10
    Dernier message: 07/01/2005, 16h59
  5. Conseil pour interface graphique en C
    Par MaxiMax dans le forum Choisir un environnement de développement
    Réponses: 4
    Dernier message: 29/03/2004, 20h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo