User.getUser(Long id) and User.getUsers(Long page, int cnt) methods retrieve data from the cache using different keys. So modifying and saving an object retrieved by getUser does not update the cached collection returned by getUsers, leading to inconsistencies. Play's caching at the model level does not consider relationships between entities.

1. JavaTWO專業技術大會

2. Play!Framework for JavaEE Developers

3. Who am IExp : JSP/Servlet , Tapestry , Spring/Hibernate/JavaEE , Wicket , Android , Grails , Play! Frameworkhttp://gplus.to/smallufohttp://twitter.com/smallufosmallufo@gmail.com

4. Web Framework ExperiencesJSP/Servlet

5. Too old , cumbersome

6. Tapestry (old experience, T5 is very good)

7. Complicated , evolution/deprecation too fast

8. Wicket

9. Too elaborate , fail to see the wood for the trees

10. May lead to over-engineered architecture for OO-purism

11. Spend too much time refactoring

12. Maybe web component reuse is just a myth

13. Grails (old experience, without Groovy++)

14. Slow

15. Too many inconsistent DSLs (URL-mapping , DB , logging...)

16. Not Java , IDE unfriendlyConventional JavaEE Stack

17. Conventional JavaEE StackWant standard page ?

18. Let's define JSP/JSTL (JSR-53)

19. And let Apache (or others) to implement Jakata Taglibs

20. Want web components ?

21. Let's define Java Server Faces (JSR-127)

22. And let communities to implement MyFaces, PrimeFaces, ICEfaces...

23. Want restful ?

24. Let's define JAX-RS (JSR-311)

25. And let communities to implement CXF, Jersey, RESTEasy, Wink...Conventional JavaEE StackLots of ...

26. Specs

27. Implementations

28. Configurations

29. Tedious , Error-prone

30. Unless you use a full-fledged JavaEE Server (Glassfish or WebLogic ...)

31. Layered

32. Defined by Standards/Specs

33. Assembled by InterfacesOVER ARCHITECTED

35. Play’s App Looks Like ?conf/routesapp/App.javaGET /hello App.hellopublic class App extends Controller { public static void hello() { User user = User.findById(1L); render(user); }} views/App/hello.htmlHello World : ${user.name}http://localhost:9000/hello

36. And Play is ...A full stack framework (platform)

37. Totally independent of JavaEE environment

38. RESTful

39. No session

40. Stateless

41. Pure server side

42. Similar to Rails / Django

43. Rich domain model

44. Unlike JavaEE's anemic domain modelFull Stack Framework?Bundles compiler , embedded server , hibernate , logger , test runner , email , groovy template engine, scala...

45. Can be packaged as a WAR and deployed to servlet containersPlay! A Glued Pure Web FrameworkShallow!Most libs are directly exposed to Play! & replaceableWhere Magic Happens

46. Play! URLs are RESTful & SEO-friendlyUGLYGRACEFUL/car/1

47. /listcar/page1/count10

48. /listcar/page1?count=10

49. /listcar/page/1/count/10

50. /car.jsp?id=1

51. /listcars.jsp?page=1&count=10

52. http://www.facebook.com/ photo.php? fbid=2121715487568& set=o.172881386106136& type=1&theaterPlay is not based on ServletMany java server side frameworks (Spring MVC / Struts / Wicket / JSF / Tapestry ...) are based on servlets, but Play! is not!You cannot do such things :session.setAttribute("user" , user);

53. Use HttpSessionListener to count sessions (online users)

54. ServletFilter

55. Servlet-related securities

56. @ServletSecurity

57. <auth-constraint /> , <security-role />Play! is StatelessPlay! shares nothing between each request!

58. The most important feature you have to keep in mind

59. No session!

60. Session is the source of all problems of the JavaEE platform!

61. Session replication