Discussion :

[Dr@ke]

Je pense n'avoir pas compris un des principes de JSF, n'arrivant pas a trouver la bonne methode pour faire ceci :

L'utilisateur peut rentrer un nom de Client par exemple dans une form, lors de la validation, une action est effectuee (action qui se trouve dans la class Client) et qui recherche dans une base de donnee si ce nom existe. (avec Hibernate, createQuery)

Apres execution de la methode, je souhaiterai afficher toutes les infos de ce client grace aux JSF EL (#{client.nom} etc..)...

Ma question est, quelle est la bonne methode pour remplir le client... Je trouve ca bizzare de charger le client depuis la base avec createQuery, puis de copier manuelement toutes ses infos dans this.. pour quelles soient disponibles ensuite...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Client c = session.createQuery("from client where nom=this.nom");
this.prenom = c.prenom;
this....

Me suis-je fais comprendre, quelqu'un sait-il me repondre ? Merci !!

[BugFactory]

C'est tout à fait normal.

D'un point de vue objet, le client, en tant qu'entité de votre modèle de données, et le backing bean, qui contient la logique de votre formulaire, sont des objets séparés.

Le jour où un client vous demandera une page affichant deux clients (pour les comparer par exemple) avec deux listes pour sélectionner les deux clients en questions, vous serez bien content de ne pas avoir à mettre ça dans votre classe Client.

[tchize_]

J'ajoute une autre possibiltié intermédiaire:
Soit Client ta classe Hibernate et ClientBean le bean JSF,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class ClientBean {
    private Client dbClient = new Client(); /*client par défaut à vide*/
    public string getDatabaseClient(){
        /* tres symbolique la query hein, faudrait 
           une requete parametrisée et des try catch pour bien faire
         */
        Client c = session.createQuery("from client where nom=dbClient.nom"). ...;
        if (c!=null)/* replace dummy Client with existing one */
            dbClient=c;
    }
    /* delegate pattern */
    public String getNom(){return dbClient.getNom();}
    public void setNom(String nom) {dbClient.setNom(nom);}
    .....
}

Avantage, tout ce qui est en dessous de delegate pattern peut être généré automatiquement par ton éditeur. Par exemple, sous eclipse, menu source, generate delegate methods, et tu coche 'dbClient'. Ca va générer touts les appels. Tu peux même limiter à certaines méthodes.

Avantage, si un jour la classe Client change fortement ou se complexifie, tu n'a qu'à régénérer les appels dans ClientBean pour les exposer à JSF.

[BugFactory]

C'est rapide, mais risqué.

A priori, l'instanciation d'une classe signifie la création d'un nouvel objet pour le modèle de données, l'appel à un setter, une modification d'une valeur. Ici, on crée un objet non parce qu'on a une nouvelle données, mais pour contenir les valeurs du formulaire.
Ceci pose un problème, car un autre développeur serait en droit de supposer qu'un appel à cet objet représente une manipulation des données et non du formulaire. Si il place des traitements dans ces méthodes, ils seront activés à tort à chaque utilisation du formulaire.

Donc à éviter. Le temps gagné au développement ne justifie pas le temps qui sera perdu en maintenance. (N'oubliez pas que la maintenance représente 80% du cout d'une application. Et de longues heures le soir pour vous!)

La bonne méthode est celle à priori employée par Dr@ke : le formulaire doit avoir une propriété correspondant à chacun de ses champs. La méthode qui correspond au bouton "valider" vérifie la saisie, puis crée l'objet Client si tout est bon.

Avantage bonus : il est courant qu'après une évolution ou deux, les champs du formulaire ne correspondent plus exactement à ceux de l'objet. Cette méthode permet de gérer ce cas facilement.

[tchize_]

Donc à éviter. Le temps gagné au développement ne justifie pas le temps qui sera perdu en maintenance. (N'oubliez pas que la maintenance représente 80% du cout d'une application. Et de longues heures le soir pour vous!)

Tout dépend de l'application, la maintenance des wrapper avec manuelle, c'est aussi un lourd temps de maintenance, surtout lorsque des Collections sont impliquées.

Sinon, une méthode rapide de transfert des données est de passer par beanutils, qui fourni des méthodes pour copier les propriétés de même nom entre 2 beans.

[Dr@ke]

Merci de ce debat, j'apprends beaucoup de choses...
Mettre a jour manuellement chaque donnee peut etre assez long, ca me parraissait bizzare...
D'ailleurs le setter automatique des listes, il m'a fait list = list...pas tres fute..