Explication concrète : les méthodes annotées en “@after” sont appelées après le render. Par conséquent, modifier les renderArgs ne sert effectivement plus à rien, c’est trop tard.

Il y aurait un effet si les méthodes @after étaient appelées au moment du render, ce qui n’est pas le cas. Un petit coup d’oeil dans play.mvc.ActionInvoker permet de le vérifier (méthode invoke).

// 3. Invoke the action
try {
// @Before
handleBefores(request);

Bonne journée !

Un truc sympa si l’on veut enrichir son objet plutôt que le tronquer en supprimant des données.

Il suffit de remplacer dans la fonction serialize(..)
JsonObject obj = new JsonObject();
par
JsonObject obj = new Gson().toJsonTree(obj).getAsJsonObject(); // on récupère l’objet déja parsé

Par exemple, si ‘lon veut ajouter le type d’une classe complexe.

public JsonElement serialize(Objet obj, Type type, JsonSerializationContext jsonSerializationContext) {
JsonObject obj = new Gson().toJsonTree(obj).getAsJsonObject();
obj.addProperty(“type”, obj.getClass().getName());
return obj;
}

Perso, le problème s’est posé avec la manipulation d’objets complexes ayant un meme parent. Le parsage Json étant effectué sur le type du parent,
il était un peu dommage de rajouter l’information de type de classe dans l’objet a parser. Cela aurait fait redondance.

Merci de partager tout ça ici !

I found that your blog is informative, and has potential articles on Play! If you are interested in reviewing the book, then I’d be glad to send you an e-copy of it.

More information about the book: http://www.packtpub.com/play-framework-cookbook/book

For more details, contact me on: jiteshg@packtpub.com

Play est un peu léger sur ce point mais ça peut facilement être complété de façon élégante. Je vois 2 solutions possibles.

* Solution 1 : Compléter Play en continuant à utiliser Gson.

- Créer une nouvelle annotation runtime (par exemple NotSerialized)
- Créer une ExclusionStrategy Gson qui se base sur la présence de cette annotation pour exclure de la sérialisation (c’est en fait l’inverse de la stratégie par défaut utilisée par Gson avec son annotation @Expose au travers de sa méthode GsonBuilder.excludeFieldsWithoutExposeAnnotation() ).
- Créer une nouvelle implémentation de play.mvc.result.Result pour remplacer play.mvc.result.JsonResult
en s’inspirant de son code ou en l’étendant (par exemple MyJsonResult).
- Créer un nouveau contrôleur abstrait qui fait un extend de celui de base et redéfinit les fonctions renderJson afin que celles-ci utilisent MyJsonResult au lieu de JsonResult (par exemple MyController).

Il suffit ensuite d’utiliser systématiquement ce nouveau contrôleur et d’annoter les attributs qui posent problème avec @NoSerialize. Ce qui donne:


package models;

@ManyToOne
@Required
@NoSerialize
public Post post;
}


et:


package controllers;

public class Application extends MyController {
public static void index() {
List posts = Post.findAll();
renderJSON(posts);
}
}


Ainsi, plus de code à écrire pour obtenir le même résultat que dans ton exemple.

* Solution 2 : Compléter Play en remplaçant Gson par FlexJSON

Là je ne vais pas tout expliquer mais, globalement le principe peut être le même en surface en utilisant des annotations. L’intérêt majeur de FlexJSON par rapport à Gson est qu’il permet de prendre en compte le fait que pour une entité donnée il peut exister plusieurs vues différentes suivant le contexte d’usage. Pour ce faire, il se base sur un contexte se sérialisation qui lui dit quoi inclure ou exclure dans un contexte donné (un JSONSerializer).

Par défaut FlexJSON propose des annotations un peu limitées (@JSON) qui permettent d’inclure ou d’exclure des attributs. Ce qui revient grosso modo à l’annotation @NoSerialize que je proposais pour Gson.

Par contre, il est très facile de créer des annotations plus complètes qui permettraient de prendre en compte un contexte en construisant automatiquement des JSONSerializer à partir des infos portée par les annotations.

Par exemple, en générique on aurait:


/** Notion de contexte de sérialisation **/
public interface SerializationContext {}



@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD})
public @interface NoSerialize {
Class[] context default "";
}


Alors en reprenant le même principe que précédemment, a l’usage ça pourrait donner:


/** Contexte de sérialisation spécifique à la vue "liste des commentaires **/
public interface ListeCommentaires extends Serialization Context {}



@Entity
public class Comment extends Model {
@Required
public String author;

@ManyToOne
@Required
@NoSerialize // jamais sérialisé
public Post post;
}


Il suffirait alors d’ajouter une variante de renderJson admettant un argument de type Class pour pouvoir sérialiser pour un contexte particulier. Exemple:


public class Application extends Controller {
public static void index() {
List posts = Post.findAll();
renderJSON(posts, ListeCommentaires.class );
}
}


Alors qu’un appel à renderJson sans cet argument supplémentaire ferait un sérialisation pour le contexte par défaut.

Ça permettrait donc de prendre en compte le fait que suivant le contexte d’utilisation un objet n’est pas toujours sérialisé de la même façon, problème que l’on rencontre obligatoirement à un moment donné si on ne veut pas transférer de données inutiles ou non souhaitables (droits d’usage/sécurité par exemple).

J’ai aussi dans l’idée de faire un post sur une mésaventure de passage de dev sur H2 en “prod” sur MySQL qui a bien merdé (nommage et conf en jeu).

Pour finir, Maven est un outil DÉCLARATIF, contrairement à Ant qui est un outil PROCÉDURAL. On ne désire pas, dans un cycle projet, définir les tâches qui vont constituer son cycle. On préférera généralement une généricité du cycle de projet, ce qu’offre Maven. Je répondrai donc à la phrase “Tous les projets sont différents”: oui, en un sens, mais le cadre conventionnel offert par Maven est commun à TOUS LES PROJETS. Et puis, si les choix des conventions ne plaisent pas, c’est configurable. Cependant, on préconise le respect des conventions Maven pour éviter de plonger dans un un sentiment de rébellion inutile, finalement.