7

I own a Play 2.1 application.

Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.

Now, I clearly want my client side to be an AngularJS app.

However, while surfing the net, I find there are no clear way to achieve it:

  1. Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
    Advantage: Likely to be less messy, and front and backend teams would work easily separately. Drawback: Need another HTTP server for the AngularJS app.

  2. Try to totally integrate AngularJS app with the traditional Play's workflow.
    Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.

  3. Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
    Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.

I pointed out my own views of advantage and drawbacks.

What would be a great way to achieve the combination of Play with Angular?

Mik378
  • 21,881
  • 15
  • 82
  • 180

2 Answers2

3

Yes, I'm answering to my own question :)

I came across this way of doing: http://jeff.konowit.ch/posts/yeoman-rails-angular/

Rails?? No matter the framework is, the need remains exactly same.

It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).

Thus, what I've learned is:

  • During development phase, a developer would use two servers: localhost on two distinct ports.
  • During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.

With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)

Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.

I really find this whole practice very elegant and pleasant to work with.

Mik378
  • 21,881
  • 15
  • 82
  • 180
  • 1
    Live reload was brought to Play! by James Ward with this plugin https://github.com/jamesward/play-auto-refresh used together with its chrome plugin companion. – Rajish Sep 22 '13 at 22:34
  • Yes, that would be a nice solution. Personally, I prefer expecting Play framework to be agnostic of complex client side like an angularjs app. – Mik378 Sep 23 '13 at 18:16
  • 1
    Was looking for something like that. I think that is the way to go! THX – reen Oct 09 '13 at 10:26
1

There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ

johanandren
  • 11,249
  • 1
  • 25
  • 30