B04.JEE Frameworks‎ > ‎03.Play Framework‎ > ‎Cookbook‎ > ‎

CH1 - Basics of the Play Framework

HTTP Routing

About REST....
  • Application functionality is divided into resources
  • Every resource is uniquely addressable using a URI
  • All resources share a uniform interface for the transfer of state between client and resource.
For example:

GET       /               Application.index
POST     /users        Application.createUser
GET       /user/{id}  Application.showUser
DELETE   /user/{id}  Application.deleteUser

# Map static resources from the /app/public folder to the /public path
GET      /public        staticDir:public

If using reqular expressions in the URL is actually pretty simple, for example, that only numbers are a valid userID. like /user/alex now would not work, but /user/1234 instead would work. You can do this:

GET      /user/{<[0-9]+>id}       Application.showUser

You can even create a List from the arguments in the URL with the following line of code:(you could use a List<Integer> IDs and show several users at once, when the URL /showUsers/1234/1/2 is called. Your controller code would start like this:)

public static void showUsers(@As("/") List<Integer> ids) { // code.... }

GET     /showUsers/{<[\0-9+]>ids}/?      Application.showUsers

Configuring your application via application.conf

open conf/application.conf with your any editor supporing UTF-8, be it Eclipse、Vim、or even notepad.

configuration option follows the scheme:

#some comment
key = value


Most importantly, adding and configuring modules, it via defining its path:

module.CRUD=${play.path}/modules/CRUD

But from play-1.2 modules are not configured via this mechanism, but via the new dependencies.yml file. You can still configure modules this way.

Understanding session management

Usually a session in a servlet-based web application is stored on a server side. This used to happen in memory, bur can also be configured to be written on disk in order to be able to restart the servlet container without losing session data.

Play! goes the way of sharing the session, but in a slightly different way. 
  • The real session used to identify the client is stored as a Cookie on the Client. 
  • This cookie is encrypted and cannot be tampered with.
  • the maximun cookie size is only 4KB.
  • Cannot work about store big data in this session, like a very large shopping cart or a rendered graphic.
For example:

setting session - session.put("login", userlogin);
getting session - String login = session.get("login");

Play! has another mechanism to store big data. Caches are good at storing temporary data as efficient and fast accessible as possible. You can also built-in cache functionality instead of the session to store data on the server side.

For example:

setting cache - Cache.set(login, shoppingCart, "20mn");
getting cache - Cache.get(login);



參考章節:


Comments