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

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. :)

Am Montag, 8. Oktober 2012 22:59:04 UTC+2 schrieb Tim P:

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.