The fourth commit has been pushed to GitHub.
Starting to set up the client
This sets up the beginnings of the Angular.js / Play app. Though the app doesn't do anything yet.
A quick run-down on its contents:
This contains the application start-up code for Play. At the moment, it has three things to set up:
Set up the database, looking in
application.conffor connection details (which in turn looks up some environment variables)
Set the home action for
DataAction is particularly designed for "single page apps" such as this one.
When the app is running in the client, Angular.js is going to request data in JSON format from the server, and render it appropriately in HTML.
DataAction uses the
AcceptsHTTP header to tell the difference between a request from our Angular.js app, and a request from a browser asking for HTML.
If a request is made with an
Acceptsheader looking for a JSON response, then the DataAction will run and return (asynchronously) data in JSON format. But if the request is made with an
Acceptsheader asking for HTML, then it returns the home action (delivering our Angular.js app to the browser to get started).
Set the look up method for
This configures how items are retrieved from the database. The basic handy library, (where
RefManyById, amongst others, are defined) is database agnostic, so this is how we wire it up to our ReactiveMongo database layer.
DAOclasses we have defined automatically inherit partial functions for looking up the classes they handle. (The
DAOtrait in handy-reactivemongo defines an appropriate partial function). So, the lookup method just has to call the partial functions from the DAO classes to see which one applies.
(If you're new to Scala, a "partial function" is essentially a function that can say "actually, no I can't handle that argument after all". So, we can keep a set of partial functions for looking up different classes of item by their ID, and the partial functions themselves can decide whether or not they apply to the reference we gave them.)
This contains a few key "actions" for our app.
This action delivers the HTML for our Angular.js app
The default action
Angular.js includes its own routing (its own handling of URLs) in the browser. In a single page app, the routing on the client side is somewhat decoupled from the routing on the server side.
This means it's perfectly possible that there will be a valid URL in the client that isn't defined as an explicit action on the server.
But we still need to handle the request if the user hits "refresh" and causes their browser to make an HTTP GET request to the server for that URL.
The default action causes those requests to return the index action (containing our Angular.js app).
The partials action
Periodically, Angular.js needs to request the HTML for a new template to show. As we define new views, we will be defining new partial templates.
If we gave each partial template its own entry in the
routesfile, then in development, every time we add a new partial template, Play would want to recompile all the controllers as the routes file (containing all the controllers' action URLs) would have changed. If we instead put all the partials into this one action, then adding a new partial template only causes the Application controller to recompile.
We have set it up, though, so that when all the (zero) libraries have loaded, require should tell Angular.js to bootsrap.
This is where we'll embed the HTML for Angular.js template directives. But at the moment, there aren't any.