Jul 232012
 

Après une installation fraiche d’Ubuntu 12.04, je me retrouve avec cet icone dans le system tray :

Après avoir pas mal cherché comment enlever cet icône (pas de clic droit / supprimer …) j’ai enfin trouvé comment faire! Voici la marche à suivre :
Menu Système / “Paramètres Système”

Cliquer sur le menu “Accès universel”

Dans l’onglet “Saisie”, décocher l’option “Activer les fonctionnalités d’accéssibilité à partir du clavier”

Et voilà l’icône a disparu.

Sep 062011
 

Imaginez le Diagramme UML suivant :

Qui pourrait parfaitement représenter les Objets d’un Blog, mais pas que.

Imaginez que vous souhaitiez réaliser un API, compatible REST, qui vous permette de récupérer vos Posts et Comments au format JSon.

Nos Objets Métiers

Commençons tout d’abord par écrire nos objets Model :
app/models/Post.java

app/models/Comment.java

Données de référence & Configuration

Pour nous simplifier la vie, Play! prévoit un mécanisme très pratique d’import de données, basé sur l’utilisation d’un fichier au format YAML
conf/initial-data.yml

conf/application.conf

Bootstrap Job & Controller

Le Bootstrap Job va nous permettre d’importer nos données de référence sans effort, et notre contrôleur devra réaliser notre besoin initial, à savoir nous retourner la liste des Posts
app/controllers/Bootstrap.java

app/controllers/Application.java

Premier résultat

Après avoir accédé via votre navigateur à l’adresse http://localhost:9000, vous devriez avoir l’erreur suivante :

Et dans votre console :

Corrections

La méthode renderJSON prévoit l’utilisation de vos propre JSonSerializer. Ce que nous allons faire pour nos Objets Post et Comment.

app/models/serializer/PostJSonSerializer.java

app/models/serializer/CommentJSonSerializer.java

On modifie par la suite l’appel à la méthode renderJSon dans le fichier app/controllers/Application.java:

Résultat final

Rafraîchissez l’adresse http://localhost:9000 pour obtenir le résultat suivant :

ps: Je vous livre ici mes observations sur le fonctionnement des JSonSerializer. Si vous voyez une façon de mieux les écrire, ou de mieux faire n’hésitez pas à commenter ce billet.

Sep 052011
 

Considérons le contrôleur suivant :

app/controllers/Application.java

Ainsi que le template associé :
app/views/Application/redirect.html

Lequel des trois prénoms suivants, Michel, Serge et Robert, va t’il s’afficher dans votre navigateur à l’adresse http://localhost:9000 ?

La réponse est Robert.

Conclusion : Un renderArgs.put dans un @After ne sert à rien!

Sep 052011
 

Imaginez que vous ayez un objet Model Tag, et que vous souhaitiez avoir un contrôleur dédié à la gestion de ces objets. Vous le nommeriez tout naturellement controllers.Tags.

Ce qui implique que vous ayez un répertoire app/view/Tags pour vos templates.

Ensuite imaginez que vous ayez besoin pour vos templates de créer des tags Play! personnalisés. Le framework s’attend à les avoir dans un répertoire nommé app/view/tags.

Vous commencez à voir où il pourrait y avoir un problème ?

Et oui, Play! sur Windows (qui est un système que je conchie) hérite du “case insensitive” de l’OS. Ce qui fait que pour lui, il n’y a pas de différence entre app/view/Tags et app/view/tags.
Play! sur Linux, qui lui est case sensitive, voit une différence, et donc ne trouve pas vos templates de tags placés dans le répertoire app/view/Tags.

En conclusion il faut donc faire attention à ne pas nommer un de vos contrôleurs Tags pour éviter tout problème avec les mécanismes internes du framework.