Subject: Re: Struts : context de page, beans de saisie - msg#00004

Previous Message by Date: click to view message preview

Re: Struts : context de page, beans de saisie

Ces objets en question sont parfois appele objet de presentation. Un peu comme les objets metiers, mais dedies pour la presentation. Sinon, l'autre solution, est de placer des if partout dans la JSP pour le cas ou le client est null. Plutot que de saupoudrer ces null partout, pourquoi ne pas envisager ces objets de presentation ? Ils factorisent ces if et deviennent reutilisable, meme si la presentation devient Swing. Effectivement, il faut penser a les copier dans les deux sens. Une pratique consiste a developper un "transvaseur" base sur l'introspection. S'il y a parfois des transformation de type entre la couche metier et la couche presentation (dates) cela peut vite devenir plus complexe. DELUNE Sébastien wrote: Bonjour la liste, Nous somme en train de revoir notre architecture orientée service, et nous nous posons une question à propos de la couche présentation. Nous utilisons Spring pour la glue technique et Hibernate pour le mapping. Pour la présentation, nous utilisons Struts. On se pose pas mal de questions à propos de la meilleure pratique pour la saisie des données de l'utilisateur. Un cas en particulier nous pose problème : les attributs facultatifs. Prenons un exemple : Une facture peut avoir 0 ou 1 client. Si une facture n'a pas de client, on aura l'attribut client de l'objet Facture qui vaudra null. On veut afficher une facture avec son éventuel client, et permettre à l'utilisateur de pouvoir modifier la facture et son client. Dans ce cas, quelle méthode employez-vous si vous voulez que l'utilisateur puisse saisir une facture et son client ? Voici les classes : class Facture { private Client c = null; public Client getClient() { return c; } } class Client { private String nom; public String getNom() { return nom; } public void setNom(String n) { nom = n; } } Dans le FormBean : class FactureFB extends ActionForm { Facture f; public Facture getFacture() { return f; } } Dans la page JSP : <html:text property="facture.client.nom" /> <--- ceci ne fonctionnera pas si la facture que l'on affiche ne possède pas de client ! Pour l'instant, il me semble que la seule solution est de créer un objet Client que l'on stockerai dans le FormBean, et cet objet servirai uniquement à la saisie. Cet objet de saisie ne serait jamais nul. Il faut alors penser à recopier l'objet client de la facture vers l'objet de saisie quand on affiche la page JSP, et penser à recopier l'objet de saisie vers le client de la facture où mettre le client de la facture à null si aucune info du client n'a été saisie, quand on veut enregistrer le client en base. Qu'en pensez-vous, comment gérez vous ce genre de problèmes ? Utilisez-vous systématiquement des objets de saisie ? Merci d'avance ! Seb.

Next Message by Date: click to view message preview

Re: Struts : context de page, beans de saisie

Sinon utiliser comme pour l'api Collection des Factures.EMPTY_FACTURE et des Clients.EMPTY_CLIENT. Et tout le monde sait qu'une EMPTY_FACTURE contient un EMPTY_CLIENT. My half a cents. On 2/2/07, Sebastien Cesbron <scesbron@xxxxxxxxx> wrote: Sinon ajouter un get/set nomClient dans facture qui fait le taf et appeler cet attribut dans la jsp Sinon moi j'aurais affiché une combo avec la liste des clients en sélectionnant le client de la facture a partir de son id. Normalement ce type de méthode pose moins de pb de null Seb On 2/1/07, Jean-Baptiste BRIAUD <jb@xxxxxxxxxx> wrote: > Ces objets en question sont parfois appele objet de presentation. > Un peu comme les objets metiers, mais dedies pour la presentation. > > Sinon, l'autre solution, est de placer des if partout dans la JSP pour > le cas ou le client est null. > Plutot que de saupoudrer ces null partout, pourquoi ne pas envisager ces > objets de presentation ? > Ils factorisent ces if et deviennent reutilisable, meme si la > presentation devient Swing. > > Effectivement, il faut penser a les copier dans les deux sens. Une > pratique consiste a developper un "transvaseur" base sur l'introspection. > S'il y a parfois des transformation de type entre la couche metier et la > couche presentation (dates) cela peut vite devenir plus complexe. > > DELUNE Sébastien wrote: > > Bonjour la liste, > > > > Nous somme en train de revoir notre architecture orientée service, et nous nous posons une question à propos de la couche présentation. > > Nous utilisons Spring pour la glue technique et Hibernate pour le mapping. Pour la présentation, nous utilisons Struts. > > > > On se pose pas mal de questions à propos de la meilleure pratique pour la saisie des données de l'utilisateur. Un cas en particulier nous pose problème : les attributs facultatifs. > > > > Prenons un exemple : Une facture peut avoir 0 ou 1 client. Si une facture n'a pas de client, on aura l'attribut client de l'objet Facture qui vaudra null. > > On veut afficher une facture avec son éventuel client, et permettre à l'utilisateur de pouvoir modifier la facture et son client. > > > > Dans ce cas, quelle méthode employez-vous si vous voulez que l'utilisateur puisse saisir une facture et son client ? > > > > Voici les classes : > > > > class Facture { > > private Client c = null; > > public Client getClient() { return c; } > > } > > > > class Client { > > private String nom; > > public String getNom() { return nom; } > > public void setNom(String n) { nom = n; } > > } > > > > Dans le FormBean : > > > > class FactureFB extends ActionForm { > > Facture f; > > public Facture getFacture() { return f; } > > } > > > > Dans la page JSP : > > > > <html:text property="facture.client.nom" /> <--- ceci ne fonctionnera pas si la facture que l'on affiche ne possède pas de client ! > > > > Pour l'instant, il me semble que la seule solution est de créer un objet Client que l'on stockerai dans le FormBean, et cet objet servirai uniquement à > > la saisie. Cet objet de saisie ne serait jamais nul. Il faut alors penser à recopier l'objet client de la facture vers l'objet de saisie quand on affiche la page JSP, et penser à recopier l'objet de saisie vers le client de la facture où mettre le client de la facture à null si aucune info du client n'a été saisie, quand on veut enregistrer le client en base. > > > > Qu'en pensez-vous, comment gérez vous ce genre de problèmes ? Utilisez-vous systématiquement des objets de saisie ? > > > > Merci d'avance ! > > > > Seb. > > > > > > > > > >

Previous Message by Thread: click to view message preview

Re: Struts : context de page, beans de saisie

Ces objets en question sont parfois appele objet de presentation. Un peu comme les objets metiers, mais dedies pour la presentation. Sinon, l'autre solution, est de placer des if partout dans la JSP pour le cas ou le client est null. Plutot que de saupoudrer ces null partout, pourquoi ne pas envisager ces objets de presentation ? Ils factorisent ces if et deviennent reutilisable, meme si la presentation devient Swing. Effectivement, il faut penser a les copier dans les deux sens. Une pratique consiste a developper un "transvaseur" base sur l'introspection. S'il y a parfois des transformation de type entre la couche metier et la couche presentation (dates) cela peut vite devenir plus complexe. DELUNE Sébastien wrote: Bonjour la liste, Nous somme en train de revoir notre architecture orientée service, et nous nous posons une question à propos de la couche présentation. Nous utilisons Spring pour la glue technique et Hibernate pour le mapping. Pour la présentation, nous utilisons Struts. On se pose pas mal de questions à propos de la meilleure pratique pour la saisie des données de l'utilisateur. Un cas en particulier nous pose problème : les attributs facultatifs. Prenons un exemple : Une facture peut avoir 0 ou 1 client. Si une facture n'a pas de client, on aura l'attribut client de l'objet Facture qui vaudra null. On veut afficher une facture avec son éventuel client, et permettre à l'utilisateur de pouvoir modifier la facture et son client. Dans ce cas, quelle méthode employez-vous si vous voulez que l'utilisateur puisse saisir une facture et son client ? Voici les classes : class Facture { private Client c = null; public Client getClient() { return c; } } class Client { private String nom; public String getNom() { return nom; } public void setNom(String n) { nom = n; } } Dans le FormBean : class FactureFB extends ActionForm { Facture f; public Facture getFacture() { return f; } } Dans la page JSP : <html:text property="facture.client.nom" /> <--- ceci ne fonctionnera pas si la facture que l'on affiche ne possède pas de client ! Pour l'instant, il me semble que la seule solution est de créer un objet Client que l'on stockerai dans le FormBean, et cet objet servirai uniquement à la saisie. Cet objet de saisie ne serait jamais nul. Il faut alors penser à recopier l'objet client de la facture vers l'objet de saisie quand on affiche la page JSP, et penser à recopier l'objet de saisie vers le client de la facture où mettre le client de la facture à null si aucune info du client n'a été saisie, quand on veut enregistrer le client en base. Qu'en pensez-vous, comment gérez vous ce genre de problèmes ? Utilisez-vous systématiquement des objets de saisie ? Merci d'avance ! Seb.

Next Message by Thread: click to view message preview

Re: Struts : context de page, beans de saisie

Sinon utiliser comme pour l'api Collection des Factures.EMPTY_FACTURE et des Clients.EMPTY_CLIENT. Et tout le monde sait qu'une EMPTY_FACTURE contient un EMPTY_CLIENT. My half a cents. On 2/2/07, Sebastien Cesbron <scesbron@xxxxxxxxx> wrote: Sinon ajouter un get/set nomClient dans facture qui fait le taf et appeler cet attribut dans la jsp Sinon moi j'aurais affiché une combo avec la liste des clients en sélectionnant le client de la facture a partir de son id. Normalement ce type de méthode pose moins de pb de null Seb On 2/1/07, Jean-Baptiste BRIAUD <jb@xxxxxxxxxx> wrote: > Ces objets en question sont parfois appele objet de presentation. > Un peu comme les objets metiers, mais dedies pour la presentation. > > Sinon, l'autre solution, est de placer des if partout dans la JSP pour > le cas ou le client est null. > Plutot que de saupoudrer ces null partout, pourquoi ne pas envisager ces > objets de presentation ? > Ils factorisent ces if et deviennent reutilisable, meme si la > presentation devient Swing. > > Effectivement, il faut penser a les copier dans les deux sens. Une > pratique consiste a developper un "transvaseur" base sur l'introspection. > S'il y a parfois des transformation de type entre la couche metier et la > couche presentation (dates) cela peut vite devenir plus complexe. > > DELUNE Sébastien wrote: > > Bonjour la liste, > > > > Nous somme en train de revoir notre architecture orientée service, et nous nous posons une question à propos de la couche présentation. > > Nous utilisons Spring pour la glue technique et Hibernate pour le mapping. Pour la présentation, nous utilisons Struts. > > > > On se pose pas mal de questions à propos de la meilleure pratique pour la saisie des données de l'utilisateur. Un cas en particulier nous pose problème : les attributs facultatifs. > > > > Prenons un exemple : Une facture peut avoir 0 ou 1 client. Si une facture n'a pas de client, on aura l'attribut client de l'objet Facture qui vaudra null. > > On veut afficher une facture avec son éventuel client, et permettre à l'utilisateur de pouvoir modifier la facture et son client. > > > > Dans ce cas, quelle méthode employez-vous si vous voulez que l'utilisateur puisse saisir une facture et son client ? > > > > Voici les classes : > > > > class Facture { > > private Client c = null; > > public Client getClient() { return c; } > > } > > > > class Client { > > private String nom; > > public String getNom() { return nom; } > > public void setNom(String n) { nom = n; } > > } > > > > Dans le FormBean : > > > > class FactureFB extends ActionForm { > > Facture f; > > public Facture getFacture() { return f; } > > } > > > > Dans la page JSP : > > > > <html:text property="facture.client.nom" /> <--- ceci ne fonctionnera pas si la facture que l'on affiche ne possède pas de client ! > > > > Pour l'instant, il me semble que la seule solution est de créer un objet Client que l'on stockerai dans le FormBean, et cet objet servirai uniquement à > > la saisie. Cet objet de saisie ne serait jamais nul. Il faut alors penser à recopier l'objet client de la facture vers l'objet de saisie quand on affiche la page JSP, et penser à recopier l'objet de saisie vers le client de la facture où mettre le client de la facture à null si aucune info du client n'a été saisie, quand on veut enregistrer le client en base. > > > > Qu'en pensez-vous, comment gérez vous ce genre de problèmes ? Utilisez-vous systématiquement des objets de saisie ? > > > > Merci d'avance ! > > > > Seb. > > > > > > > > > >