[2.0.4] Struggling with packages

[Tim P]

Hi

Almost all examples seem to ignore the issue of packages. I'm used to putting my code in a package something like <com>.<company><application><module> and I've tried to do the same with play - but I end up with huge package strings everywhere - and then it (or I) seems to get confused with error messages like "object Application is not a member of package controllers" from routes_routing.scala.

So does everyone just throw the whole package thing out of the window - at least for controllers and views? What is the recommendation?

Thanks

Tim

[Thomas Felix]

Personally I just use the default structure for the play app (so just a package for controllers, views and models). But when I do a play module which might get included in other apps I will stick to the "standard" approach. I looked how the deadbolt plugin did it: https://github.com/schaloner/deadbolt-2/tree/master/project-code/app look at its package structure. Thats my approach. :)

[James Roper]

One of the goals of play is to minimise complexity and code boiler plate.  When writing a library that other code will depend on, name spacing things carefully in packages that you know are going to be unique is very important.  When writing a web application that you know no code is going to depend on, then long package names just become boiler plate bloat that you always have to deal with but never see the benefits of.  So Plays philosophy is to keep things as short as possible, define conventions for where to put classes (eg models, controllers, views) and add default imports for example to templates for everything in these packages, and it's not afraid to break old conventions to do this.

If you want a great play experience, then I'd advise that you go with the flow and follow its conventions.