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.
Ca me fait penser à cette table “show” pour une appli de programme TV en Play!, qui fonctionnait en local, mais plantait lors du déploiement sur PlayApps (mot réservé sur MySQL et visiblement pas sur H2, je n’ai pas approfondi). Quelques heures perdues pour l’occasion…
Effectivement ça fait penser à ça.
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).