Play framework - Bristol Java meetup
•Als PPTX, PDF herunterladen•
1 gefällt mir•361 views
Covers the basics of Play 1 plus a quick overview of differences between Play 1 and Play 2. Aimed at developers wondering if they should consider building something with Play rather than being a in depth look at everything Play can do.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Play framework - Bristol Java meetup
Ähnlich wie Play framework - Bristol Java meetup (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Play framework - Bristol Java meetup
- 1. Play! Framework with Robin Warren
- 2. What’s in this presentation 1. Why you may want to use the Play! Framework 2. Overview of building a small app 3. Some other bits and bobs
- 3. What’s not in 1. A lot of Play 2 2. Funny jokes
- 4. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 5. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 6. Firstly... How I came to the Play Framework
- 7. At Covalent Software until December last year
- 8. Covalent 3 years ago
- 9. How I came to Play! ● Large existing code base ● Development team of 15 ● Existing active user base ● Time pressure (as always) ● + Opportunity to adopt some better tech
- 10. The options
- 11. The criteria 1. Community 2. Used in production 3. MVC 4. Ease of development 5. Bonus - no XML, no GWT style magic
- 12. The short list
- 13. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 14. How to Play!
- 15. Download
- 16. Extract
- 17. Create a project
- 18. Eclipsify (or netbeansify, or idealize) your project
- 19. Run your project
- 20. To the browser!
- 21. What have we got so far
- 22. app - MVC
- 23. configuration
- 24. application.conf
- 25. routes
- 26. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 27. Let’s make some changes We will build a tool to help our new clients...
- 29. A detailed spec The basics 1. Show list of known underpants locations 2. Ability to add underpants location 3. Ability to mark underpants as collected
- 30. Model
- 31. Controller
- 32. View
- 33. main.html
- 34. The basics 1. Show list of known underpants locations 2. Ability to add underpants location 3. Ability to mark underpants as collected
- 36. View changes
- 37. Nearly done for v1 The basics 1. Show list of known underpants locations 2. Ability to add underpants location 3. Ability to mark underpants as collected
- 39. New controller
- 40. New view
- 41. Done! The basics 1. Show list of known underpants locations 2. Ability to add underpants location 3. Ability to mark underpants as collected
- 42. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 43. Some useful additions More stuff 1. Jobs 2. Controller inheritance and @Before methods 3. Tags 4. Testing
- 44. Some useful additions More stuff 1. Jobs 2. Controller inheritance and @Before methods 3. Tags 4. Testing
- 45. Jobs Used for 1. Background tasks 2. Doing work asynchronously in controllers
- 46. Background tasks
- 47. Asynchronous work in controllers
- 48. Controller inheritance and @Before methods
- 49. Tags Tags can be ● Templates (html, js, whatevs) ● Java FastTag subclass Let’s create a profitable tag for the main view...
- 50. Tags
- 51. Tags
- 52. Some useful additions More stuff 1. Jobs 2. Controller inheritance and @Before methods 3. Tags 4. Testing
- 53. Testing
- 54. Unit test
- 55. Functional test
- 56. Selenium test
- 57. Test data
- 58. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 59. Even more useful additions A more stuff (in less detail) 1. Validation 2. Built in tags and Java extensions 3. Modules
- 61. Built in tags and extensions
- 62. Modules
- 63. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 64. Larger apps with Play Some thoughts...
- 65. Larger apps with Play! 1. Decompose controllers early 2. No catch all routes (remove magic) 3. Split app up into modules 4. Don’t use their selenium tag (unless you know better?) or the headless browser
- 68. No catch all routes
- 69. Split app up into modules
- 70. Don’t use their selenium tag or headless browser
- 71. Coming up ● How I came to Play! ● Getting started ● Building our first app ● More stuff ● A bit more stuff (in less detail) ● Building larger apps in Play! ● Play 2 vs Play 1
- 72. Play 2 vs Play 1
- 74. Most relevant for developers 1. Templates: Scala (from Groovy) 2. Less magic (aka bytecode generation etc.) 3. EBean instead of hibernate 4. bindFromRequest() 5. Asset directory - makes it easy to work with coffeescript etc.
- 75. fin
Hinweis der Redaktion
- Main thing Allow you to decide if you want to use the Play framework Build small app to help Other bits and bobs
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- Previously CTO at Covalent Software in Taunton. Now doing my own thing possibly looking for work if something interesting comes up in the mean time.
- Covalent 3 years ago Thick client Nav down the bottom Bit crappy looking Market leader, but… Failed efforts to revamp the UI Scared of the browser Looking 10 years ahead What the software would look like. Already losing deals to newer companies who were browser based. Lessons Don’t leave it too long to migrate If you’re in a position of technical leadership it’s your job to convince other senior managers that it can and should be done
- Reuse existing code base, so JVM Reuse existing skills, so Java Needs to work on large code base with multiple developers Needs to work with existing load (2k users per day) Also, this was a great opportunity to bring in some better tech and actually some better development practices
- I think I started with a list something like this Criteria were Size & quality of community StackOverflow Check existing sites, do they work? are they up to date? Plugins? Grails had very poor plugins with mutliple vulnerabilities in the paypal plugin for example (v0.6 or something to be fair) Being used in production MVC Other ideas nice but not so mainstream. I wanted something which was a safe bet here, a VHS perhaps to some other alternatives betamax. This was what we’d be building the company on so needed a safe choice Ease of development Needed to get team up to speed on it fast Didn’t want long/expensive learning curve Some of my own preferences No/minimal XML please GWT etc. not my cup of tea. You’re a software developer, learn JS and HTML
- I think I started with a list something like this Criteria were Size & quality of community StackOverflow Check existing sites, do they work? are they up to date? Plugins? Grails had very poor plugins with mutliple vulnerabilities in the paypal plugin for example (v0.6 or something to be fair) Being used in production MVC Other ideas nice but not so mainstream. I wanted something which was a safe bet here, a VHS perhaps to some other alternatives betamax. This was what we’d be building the company on so needed a safe choice Ease of development Needed to get team up to speed on it fast Didn’t want long/expensive learning curve Some of my own preferences No/minimal XML please GWT etc. not my cup of tea. You’re a software developer, learn JS and HTML
- Spring Felt like the defacto successor to Java EE Main framework being used by teams when I look at who was hiring for what skills Play Fitted criteria above well new v2 was poorly documented luckily someone suggested I look at v1 which was still being maintained and used in production by a number of companies Spring was the forerunner at this point as it felt like the safe choice. For the final test Tried to build a small app in each one to get a feel for what it was like to work with. Tried to add security Started with Spring, took a long time to get dependancies and everything working Built in Play in a matter of hours what had taken an age in Spring. Possibly my skillset, YMMV. So I had a choice which Was used in production by a number of companies (including LinkedIn) Was easy to develop with Had an easy learning curve and used mainstream ideas like MVC It’s time to get started
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- Let’s get started with an example application
- And add to PATH
- Show in browser
- If you’ve got less tabs than this you’re doing it wrong
- Key ones for us are app and conf
- Models, Views and Controllers Quick explain for anyone not familiar with web MVC frameworks We’ll see the actual app in a moment
- Will show application.conf and routes dependencies maps modules you depend on messages supports i18n
- database connections etc.
- GET or POST path Controller.method
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- So, we’ve got our detailed plans let’s get to work
- Not a lot of code Extends play model class Gives us some nice additions to JPA Includes a Long ID field - you can extend GenericModel if you don’t want that public variables Two annotations JPA - @Column and @Entity
- extends Controller public static void for endpoints findAll retrieves all the models render passes control to the view at the relevant location, any variables passed in will be accessible under that name in the view code
- #{tags /} or #{tag} #{/tag} ${output} Escapes html etc. Guide to more complex escaping here http://stackoverflow.com/questions/5764679/guide-to-proper-escaping-in-play-framework Extends main.html Take a look at that defines head calls #{get } calls #{doLayout /} - makes it extendable
- What we haven’t done Told Play how to match a controller method to a view Had to explicitly create a renderArgs Map for the view Lets add some more functionality - to mercurial
- addLocation endpoint Takes two Strings Could take a new UnderpantLocation object I prefer to keep view/controller/model more separate Github had a bug with this Develop should be able to expose values in Model without being concerned with how data gets from client into Controller redirects to index after adding new location - could show this in chrome Model just has new constructor for simplicity
- #{form} tag @Controller.method() route definition method param has content which is rendered as part of the form
- Onwards
- Moved underpant location endpoints out of Application to UnderpantLocations Added list and show views for UnderpantLocations list just copy of index previously index now just links to two endpoints in UnderpantLocations Added
- Reusing a view with uncollectedList new markCollected endpoint Finds existing location marks as collected and saves redirects to full list (should do something smarter, would probably be done as ajax in reality)
- show view All stuff we’ve seen before Extends main (most of your web app views will) sets a title ${output} #{form } tag Slight change to list to give locations a piss stain yellow background when collected
- That’s the basics done I’ll show you more stuff Even more stuff but in less detail Thoughts on writing larger apps in Play Play 2
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- Take the first 3 in with the next commit
- Annotation controls how often the run @Every(“1h”) @Every(“5min”) etc. @On("0 0 1 ? * MON") @OnApplicationStart implement doJob, would normally be something a bit more interesting in here
- implement doJobWithResult (if you need a result) Call now() which executes it asap call await(), which waits for the response and yields control of thread Necessary for high throughput applications.
- GnomeController is superclass for our UnderpantController, and could be use for others in the application @Before annotation means this method called before other endpoints renderArgs is Map built based on values passed into render() call, we can add our own values explicitly as well
- changes to main calling our new tag, passing profitable value in from renderArgs
- New tag file Located under tags directory Mostly what we’ve seen before (I’ve added some css for background colour)
- Built right into Play Unit tests Functional tests Selenium tests Getting data in for your tests cmd> play test localhost:9000/@tests
- Unit test has access to code but web apps not up and running
- Functional test Web app is up and running Has some handy extensions to assist in validating results Warning, doesn’t play well with async jobs in controllers for some reason.
- Selenium tag creates a HTML selenium test Warning if you have issues there aren’t a lot of people using this way of creating tests out there so finding solutions tricky I’d be tempted to stick with Java selenium tests which are then also easier to run with Selenium Grid over different browsers Unless you know any better?
- Can be easily loaded before individual tests or groups of tests Also ability to delete old data as well
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- You can also just add annotations to fields in your controller methods if you like Play Annotation JSR303 validation annotation @Required @MinSize There are others...
- Check the Play documentation
- Check out https://www.playframework.com/modules Secure module is the one I always end up using, worth checking out adding it to a project as it shows a few useful things Adding a module dependency Importing routes Adding annotations to controllers Overriding views Extending it (adding your own permissions)
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- shit slide
- Partials a things I’m loading over ajax _templates are #{includes } (not shown those yet) Then I’ve broken the controllers down into Main views (list, show etc) Partials for ajax Edit workflow Decompose controllers early. First sign of problem is probably dirs in your views folders (remember case sensitivity) Beware too many unless and onlys in @Before annotations Smell in your views package first, Then your Controller will start stinking up. Lots of methods, and @Before methods with lots of unless and onlys
- If your app directory is getting big, consider splitting your app into modules
- selenium tag No one else is using it We struggled, but possibly because we were also learning selenium at the same time Preference out there seems to be to write Java tests and execute using selenium grid (allowing execution on other browsers and phones/tablets from a jenkins build) Headless test browser You end up debugging issues in a browser you can’t open which don’t affect other browsers. Don’t do it, kills speed and motivation to write tests
- Experience with Play 1 Section at end on differences No guarantees on jokes being funny Good way to identify a joke if you spot one is to laugh
- Lot’s of differences, some of which you may care about some of which maybe you don’t Biggie Complete rewrite, written in Scala, supports apps in Java or Scala
- Templates You can override the default if you prefer Stick with default or choose an option which is well supported and used by a number of people (I think) Less magic May mean the test issues I had are fixed Probably means less likely to hit weird issues due to Play code in general EBean Maybe you care? bindFromRequest Fixes issue mentioned earlier by allowing controller to say what values on a model can be bound from a certain request Asset directory If you’re working with JS you’ve likely wired up Grunt or something Handles building assets at compile time