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

GWT et Vaadin Java Discussion :

A propos des servlets


Sujet :

GWT et Vaadin Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre régulier
    Inscrit en
    Juillet 2011
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : Juillet 2011
    Messages : 8
    Par défaut A propos des servlets
    Bonjour,

    Je suis nouveau dans le dev web et en GWT en particulier. Afin de partir sur de bonnes bases, j'aimerais éclaircir quelques points :
    1. Quel est le cycle de vie d'un RemoteServiceServlet ? Quand est-ce que les instances de nos servlets sont créées, détruites et par qui ? Une instance par navigateur de lancé ? Par exemple si je veux inclure un système d'identification classique (avec un formulaire login/pass), il me suffit de stocker les informations relatives à l'utilisateur courant dans les attributs du servlet ou il y a-t-il un mécanisme de session qui m'échappe ?
      ;
    2. Quelles sont les manières conseillées de décomposer une application en servlets ? Selon quels critères est-il pertinent de regrouper des requêtes sur le même servlet ?
      ;
    3. Si je parse en java un fichier xml côté client via un chemin fixe qui pointe vers mon disque, le code javascript généré ne contiendra aucune trace de la lecture de ce fichier n'est-ce pas ? Autrement dit, côté client, tout ce qui est strictement en amont de l'action de l'utilisateur est du pré-processing du point de vue du compilo java vers javascript ?


    merci,

  2. #2
    Membre régulier
    Inscrit en
    Juillet 2011
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : Juillet 2011
    Messages : 8
    Par défaut
    Bonjour,

    Je réponds à mes questions:

    1. Ma question était bête je l'admets. Le servlet est unique et se crée au lancement du serveur d'application. Il n'y pas un servlet par session. Les exemples sur le net où des infos sur l'utilisateur courant sont directement stockées dans le servlet prêtent à confusion.

    2. A priori, une application n'aura qu'un seul servlet, donc la question ne se pose plus.

    3. Je n'ai toujours pas de réponse claire à cette question. Par exemple si j'écris ce code java côté client :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    String configInfo = ReadInfoFromXmlFile("chemin_vers_un_fichier_chez_moi(pas_chez_le_client).xml");
    Il sera transformé en ce code javascript ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    var configInfo = new String("information_lue");

    Par ailleurs, pour rebondir sur ma première question, quel est le meilleur moyen du coup dans le servlet pour savoir quel client a envoyé la requête que l'on traite ? getThreadLocalRequest() puis récupérer la session ? Ou il y a mieux ?

  3. #3
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Par défaut
    Salut,

    1)
    La question sur les servlets n'est pas propre à GWT.
    Les servlets sont généralement gérées (instanciées, détruite) par le conteneur de servlets.
    A moins de forcer, tu ne maîtrise pas trop leur gestion, c'est pour cela qu'il est en général déconseillé d'utiliser des variables d'instances (sans parler du multithreading)
    Si tu souhaites mémoriser les données propres à un client (un navigateur), vu que http est un protocole sans état, il te faut soit utiliser une session http côté serveur (il y a une méthode getSession() accessible par l'objet request) soit échanger les données avec le client.
    Dans un cas comme dans l'autre, il faut stocker le minimum dans la session.

    2)
    Dans les framework ordinaires, tu peux avoir autant de servlets que d'actions.
    En gwt, autant de servlets que de service.
    Tu peux également faire du MVC avec un controleur hiérarchique, une sorte de super contrôleur avec une seule servlet.
    En Jee classique, tu fais une servlet qui dispatch vers différentes actions.
    En gwt, tu peux faire un super service générique qui reçoit/envoit des données.

    3)
    Pour des questions de sécurité, tu ne peux pas lire de fichier sur le poste client avec javascript.
    Tu peux en revanche lui les faire uploader par le serveur et le serveur peut ensuite renvoyer ce contenu au client.

  4. #4
    Membre régulier
    Inscrit en
    Juillet 2011
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : Juillet 2011
    Messages : 8
    Par défaut
    Salut,

    ok pour 1) et 2)

    Pour 3), le fichier ne se trouve pas sur le poste client, mais sur le poste du développeur au moment de la compilation. Je testerai à l'occasion mais je m'attends à ce que le résultat de la compilation de la lecture du fichier soit une simple chaîne de caractères dans le javascript. Je sais que la question est bête encore une fois, mais je préfère être sûr avant de m'embarquer dans quelque chose qui ne correspond pas exactement à mes besoins.

  5. #5
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Par défaut
    En développement, le serveur et le client sont généralement sur la même machine donc attention pour la mise en prod.

    Il est possible d'avoir des "clients bundles" avec gwt.
    Des fichiers ressources qui seront ajoutés comme ressources statiques lors de la phase de compilation.
    Ensuite ces ressources statiques seront accessibles depuis le code javascript.

    Donc si le dev a un fichier de config xml, il peut en faire un bundle gwt donc ce fichier sera accessible depuis le code js (le fichier xml qui ets sur le serveur aura été envoyé au client mais c'est gwt qui fait le taf)

    Attention toutefois qu'il n'y ait pas des données confidentielles dedans.

  6. #6
    Membre régulier
    Inscrit en
    Juillet 2011
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : Juillet 2011
    Messages : 8
    Par défaut
    Merci.

    il peut en faire un bundle gwt donc ce fichier sera accessible depuis le code js
    En fait j'espérais ne même pas avoir à lire le fichier en js, puisque son contenu est toujours le même.

    Je pensais que la phase de compilation GWT exécutait le code java et que l'exécution des classes de GWT générait du js, à l'inverse de mon code java qui aurait été considéré comme du pré-processing puisqu'il aurait été exécuté sans produire du js. Mais en réalité il traduit réellement le code java en js grâce à de l'introspection ? Autrement dit, 2+2 ne sera pas traduit en 4 (le code java a été exécuté) mais bien en 2+2 (il est uniquement traduit).

    Je ne t'embête pas plus, je mets le sujet en "résolu".

    edit: je suis un peu déçu quand même

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Aide a propos des TMenuEdit
    Par scooper dans le forum C++Builder
    Réponses: 9
    Dernier message: 27/05/2004, 15h39
  2. Une question à propos des thread
    Par tscoops dans le forum C++Builder
    Réponses: 4
    Dernier message: 07/11/2003, 14h03
  3. A propos des 'File management Functions' de Windows
    Par znaidi dans le forum Windows
    Réponses: 3
    Dernier message: 01/04/2003, 16h01
  4. A propos des modèles d'objet (avec sources)
    Par DevX dans le forum C++Builder
    Réponses: 14
    Dernier message: 01/12/2002, 12h22

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