Re: [Topia-devel] [Dev] Strut2/JSON Retourner que les proprietes que l'on souhaite
On Fri, 13 Jan 2012 18:39:32 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Salut,
Voila une config que j'utilise pour ca. En gros seules les proprietes de l'action decrite dans le type wikitty-json son serialise en json. Ici, je ne joue que sur l'include, mais on peut aussi utilier exclude, voir la doc pour plus de detail: http://struts.apache.org/2.1.8/docs/json-plugin.html
Tony me glisse dans l'oreille qu'il est trop dur pour topia d'ecrire les includes/excludes. L'idée serait donc de créer un helper json dans topia. Ca eviera a chaque projet de devoir creer des dto pour ce seul besoin. TopiaJsonHelper { /** * Retourne une version json de l'objet seules les propriétés simples * sont incluses les liens vers les autres entites ne sont ajoutées * que via l'id de l'autre entité */ toJson(TopiaEntity e):String /** * Retourne une version json de l'objet, seules les propriétés simples * sont incluses, mais aussi les autres entités que l'on peut atteindre * comme décrit dans les chaines entityField * @param entityField ex: si on est sur Employee et qu'on veut aussi * Company dans le json: * <pre> * String s = TopiaJsonHelper.toJson(e, "company"); * </pre> * Si la company a encore une entite adresse et qu'on le veut aussi * <pre> * String s = TopiaJsonHelper.toJson(e, "company", "company.address"); * </pre> * * TODO reflechir s'il est utile que entityField puisse etre une regex * et est-ce simple a implanter ? */ toJson(TopiaEntity e, String ... entityField): String /** * Retourne une version json de l'objet, seules les propriétés simples * sont incluses, mais aussi les autres entités que l'on peut atteindre * jusqu'au niveau depth * @param depth le niveau de serialisation 1=seulement e, 2=e et ses fils directs * 3=e, ses fils directs et les fils des fils, ... */ toJson(TopiaEntity e, int depth): String } -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le Fri, 13 Jan 2012 19:14:55 +0100, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Fri, 13 Jan 2012 18:39:32 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Salut,
Voila une config que j'utilise pour ca. En gros seules les proprietes de l'action decrite dans le type wikitty-json son serialise en json. Ici, je ne joue que sur l'include, mais on peut aussi utilier exclude, voir la doc pour plus de detail: http://struts.apache.org/2.1.8/docs/json-plugin.html
Tony me glisse dans l'oreille qu'il est trop dur pour topia d'ecrire les includes/excludes.
J'ai essayé de mettre en place des regex pour exclure les infos non désirées dans la serialization JSON. Cela me semblait etre plus cohérent : utiliser les outils proposés et pas contourner le probleme (meme si on m'avait prevenu que d'autres se sont cassé les dents en tentant de jouer les regex , ouep, chui tetu, et j'aime comprendre ce qui va pas...) J'ai réussi à faire fonctionner avec deux objets simples A&B et un objet C qui contenait B, par contre, des lors ou j'ai rajouté un objet D contenant A, soit la serialisation de C plantait, soit c'était celle de A, en fonction de comment je jouais sur la regex. En soit meme, je ne comprends pas comment cela ne peut pas fonctionner sur les deux, car le schema et le meme : C contient un seul B et D contient un seul A. donc la regex qui fonctionne sur l'un devrait correspondre à l'autre aussi. (donc je comprends toujours pas ce qui va pas ):
L'idée serait donc de créer un helper json dans topia. Ca eviera a chaque projet de devoir creer des dto pour ce seul besoin.
Je suis pas convaincu par l'approche : on a un probleme, pour le moment specifique à notre utilisation du plugin JSON de struts, mais des lors ou il faudra serializer dans un autre langage (xml, yaml, etc ...), devra-t-on faire la meme chose ? Ma vision du probleme, c'est qu'on remonte la terre et le monde avec les entités. Loin de moi l'envie de relancer un débat qui semble avoir deja eu lieu à plusieurs reprises. L'approche que j'ai sur cette problematique, c'est de créer des DTOs avec nos entités. Je vois l'utilisation d'un DTO comme une vue sur une entité (ou plusieurs entités), et c'est exactement ce que l'on désire ici : ne voir que certaines propriétés, celles propres à l'entité, que l'on ecrit dans le model (+ potentiellement l'id, qui est pas explicitement indiqué dans le model). Pourquoi ne pas voir alors dans le EntityDTOTransformer un ajout de la propriété "id" qui correspondrait au topiaId de l'entité, ainsi qu'une operation permettant la creation du DTO depuis l'entité pour en faire la copie directement et simplement ? Ou alors j'ai pas compris l'utilité de ce transformer par rapport au "DTOTransformer". -- Yannick
On Wed, 18 Jan 2012 14:59:57 +0100 Yannick Martel <martel@codelutin.com> wrote:
Pourquoi ne pas voir alors dans le EntityDTOTransformer un ajout de la propriété "id" qui correspondrait au topiaId de l'entité, ainsi qu'une operation permettant la creation du DTO depuis l'entité pour en faire la copie directement et simplement ? Ou alors j'ai pas compris l'utilité de ce transformer par rapport au "DTOTransformer".
+1, sur un entityDTOTransformer cela parait très cohérent. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Wed, 18 Jan 2012 14:59:57 +0100 Yannick Martel <martel@codelutin.com> wrote:
L'idée serait donc de créer un helper json dans topia. Ca eviera a chaque projet de devoir creer des dto pour ce seul besoin.
Je suis pas convaincu par l'approche : on a un probleme, pour le moment specifique à notre utilisation du plugin JSON de struts, mais des lors ou il faudra serializer dans un autre langage (xml, yaml, etc ...), devra-t-on faire la meme chose ?
Oui, il faudra implanter un helper specifique, qui pourra s'appuyer sur la bonne librairie pour ce langage. Par exemple on on remonte le TopiaContext mais il est marque transient donc la serialization json ne devrait pas le prendre donc c'est le plugin qui est en faute. Il faut donc utilise une librairie qui fonctionne convenablement pour implanter le TopiaJsonHelper. De plus si on veut utiliser Topia dans un autre context que struts et faire du json, on fait comment ? Il faudra reecrire la serialization json pour ce projet car plus de plugin struts ? Je ne dis pas qu'il faut anticiper un besoin qu'on a pas (loin de moi cette idee). Je dis juste qu'on a un problème actuellement qu'on peut résoudre facilement en implantant un Helper en utilisant la bonne librairie. En resolvant ce probleme de cette facon, on ouvre la librairie a tout plein d'usage.
Ma vision du probleme, c'est qu'on remonte la terre et le monde avec les entités. Loin de moi l'envie de relancer un débat qui semble avoir deja eu lieu à plusieurs reprises.
non tout ce qui est en 'trop' est transient
L'approche que j'ai sur cette problematique, c'est de créer des DTOs avec nos entités. Je vois l'utilisation d'un DTO comme une vue sur une entité (ou plusieurs entités), et c'est exactement ce que l'on désire ici : ne voir que certaines propriétés, celles propres à l'entité, que l'on ecrit dans le model (+ potentiellement l'id, qui est pas explicitement indiqué dans le model).
Et le jour ou ce DTO ne plait pas a ta librairie du framework que tu utilises tu fais un autre DTO encore plus mieux ? Je pense que tu ne fais que reporter le probleme. En plus dans ce cas tu genere un objet DTO qui ne sert qu'a permettre a une mauvaise librairie de faire une serialization Json. Donc tu crées un objet, tu copies toutes les données pour le mettre a la poubelle juste apres :(. C'est pas un peu couteux, surtout lorsque tu as une solution qui te permet de faire la meme chose sans creer d'objet intermediaire
Pourquoi ne pas voir alors dans le EntityDTOTransformer un ajout de la propriété "id" qui correspondrait au topiaId de l'entité, ainsi qu'une operation permettant la creation du DTO depuis l'entité pour en faire la copie directement et simplement ? Ou alors j'ai pas compris l'utilité de ce transformer par rapport au "DTOTransformer".
Ca c'est une autre chose, simplifier la creer d'un DTO qui existe déjà et lui ajouter un id qui permettrait de le rendre reellement utilisable. Vu le cout du developpement et le gain que cela peut avoir je suis plutot pour. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le Wed, 18 Jan 2012 17:33:34 +0100, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
Il faut donc utilise une librairie qui fonctionne convenablement pour implanter le TopiaJsonHelper. De plus si on veut utiliser Topia dans un autre context que struts et faire du json, on fait comment ? Il faudra reecrire la serialization json pour ce projet car plus de plugin struts ?
Je suis justement pas convaincu par le fait d'ecrire la serialization json ou autre alors que le framework qu'on utilise est censé le gérer.
L'approche que j'ai sur cette problematique, c'est de créer des DTOs avec nos entités. Je vois l'utilisation d'un DTO comme une vue sur une entité (ou plusieurs entités), et c'est exactement ce que l'on désire ici : ne voir que certaines propriétés, celles propres à l'entité, que l'on ecrit dans le model (+ potentiellement l'id, qui est pas explicitement indiqué dans le model).
Et le jour ou ce DTO ne plait pas a ta librairie du framework que tu utilises tu fais un autre DTO encore plus mieux ? Je pense que tu ne fais que reporter le probleme. En plus dans ce cas tu genere un objet DTO qui ne sert qu'a permettre a une mauvaise librairie de faire une serialization Json. Donc tu crées un objet, tu copies toutes les données pour le mettre a la poubelle juste apres :(. C'est pas un peu couteux, surtout lorsque tu as une solution qui te permet de faire la meme chose sans creer d'objet intermediaire
Le jour ou mon DTO ne plaira plus, ce ne doit pas etre à cause du framework, mais parce que mon besoin a changé. Je me suis peut etre mal exprimé sur ma vision du DTO, mais si je prends un exemple, c'est avoir un objet "Company" avec plusieurs propriétés : name, address, postalCode, city, country, leader, activityDomain et une List<Employee>. Si toutes ces données sont utiles à la création ou à l'affichage de la company, dans un listing des Companies, on ne peut vouloir afficher que le name, country et leader. Dans ce cas là, l'utilisation d'un DTO ne contenant que les champs souhaités peut etre propice. (Je passe l'exemple avec une grappe d'objets pouvant provenir de employee). Autre exemple, un simple User, en remontant l'entité, on remonte toutes les infos dont le mot de passe. L'interet du DTO, c'est aussi de pouvoir masquer ce genre d'informations. Transient ou pas, les informations liées à l'entité sont aujourd'hui remontées, et je trouve pas que cela soit une bonne chose. Ensuite, que mon framework d'UI soit struts, tapestry, gwt, ou autre, le besoin restera toujours le meme. Le probleme n'est donc pas déporté, car non lié au framework. Et donc, ma phrase "c'est exactement ce que l'on désire ici" était censé etre cet exemple :) -- Yannick <martel@codelutin.com> Société Code Lutin Tel: 02 40 50 29 28 http://www.codelutin.com
participants (3)
-
Benjamin POUSSIN -
Tony Chemit -
Yannick Martel