Experiences on a Design Approach for Interactive Web Applications
•
2 j'aime•658 vues
Presentation at USENIX WebApps '11
Recommandé
Contenu connexe
Tendances
Tendances (18)
Similaire à Experiences on a Design Approach for Interactive Web Applications
Similaire à Experiences on a Design Approach for Interactive Web Applications (20)
Dernier
Dernier (20)
Experiences on a Design Approach for Interactive Web Applications
- 1. Experiences on a Design Approach for Interactive Web Applications
- 2. Experiences on a Design Approach for Interactive Web Applications Janne Kuuskeri Tampere University of Technology Stratagen Systems
- 3. Current Browser Server
- 4. Current Browser GET /myapp/index.html Server
- 5. Current Browser GET /myapp/userlist.html Server
- 6. Current Browser POST /myapp/userdata Server
- 7. Current • resume app state Browser •execute app logic •update model •find view •update session •generate page Server
- 9. Current Browser Java
- 10. Current Browser HTML Java
- 11. Java HTML ipt JavaScr Current Browser
- 12. Java HTML ipt JavaScr S CS Current Browser
- 13. Java HTML ipt JavaScr S CS Current JSP Browser
- 14. Current JavaScr Browser HTML Java ipt CS JSP HTML page S
- 15. Java Current String hql = "from Person p where p.age > :age"; Query q = session.createQuery(); q.setInteger("age", 33); List people = q.list(hql); JavaScr Browser HTML Java JSP ipt CS <table> JSP S <% for (Person p : people) { %> <tr> <td>p.getName()</td> <td>p.getAge()</td> </tr> <% } %> </table>
- 16. JSP <% Current if (request.getParameter("age") != null) { age=Integer.parseInt(request.getParameter(“age”)); } JavaScr Browser String hql = "from Person p where p.age > :age"; HTML Java Query q = session.createQuery(); q.setInteger("age", age); List people = q.list(hql); ipt CS %> JSP S <table> <% for (Person p : people) { %> <tr> <td>p.getName()</td> <td>p.getAge()</td> </tr> <% } %> </table>
- 17. JavaScript Current var onClick = function () { $.ajax({ url: ‘/people/’, dataType: ‘json’, JavaScr Browser data: { age: 33 }, success: function (data) { HTML Java var rows = []; $.each(data, function (person) { rows.push(‘<tr><td>’ + person.name + ipt CS ‘</td><td>’ + person.age +‘</td></tr>’); JSP S } $(‘#peopletable > tbody:last’).append( ‘’.join(rows)); } }
- 18. MVC
- 19. MVC Browser View Server Controller, Model
- 20. MVC View Browser Controller, Model Server ?
- 21. MVC View Browser Controller, Model Server REST
- 22. MVC Single page web application Server REST
- 23. HTML <html> MVC <head> <link type="text/css" href="someframework.css"> <script src=”someframework.js”></script> <script src=”myapp.js”></script> </head> <body> </body> Single page web application </html> Server REST
- 24. MVC Single page web application Server REST
- 25. MVC Single page web application Server REST
- 26. Case:Valvomo
- 27. Valvomo Browser Server Transit API Paratransit System
- 28. Valvomo Browser Single page UI Server Transit API RESTful API Paratransit System
- 29. Valvomo Web Browser Application HTML Server Transit API Valvomo Web Application Paratransit System
- 30. Valvomo Browser JSON Server Transit API Paratransit System
- 31. DEMO
- 32. Pros • browsers • mobile devices • programmatic clients • HTTP • Accessible API
- 33. Pros • can have several different server • Accessible API implementations • same UI can be placed • Reusable API “on top” of another server implementation as long as it is the same API • no predefined application flow
- 34. Pros • Accessible API • responsibilities are easier to assign • Reusable API • data validation • error handling • Decoupling • localization
- 35. Pros • Accessible API • unambiguously assign responsibilities for state • Reusable API handling • server is responsible • Decoupling for resources and their states • Application flow / state • application (client) is responsible for the application flow and state
- 36. Pros • Accessible API • fewer technologies to worry about • Reusable API • one language for the client • Decoupling • one language (maybe even the same) for the • Application flow / state server • client and server are • Development model easier to develop in parallel
- 37. Pros • Accessible API • Reusable API • client and server may be tested separately • Decoupling • server API may be tested using isolated • Application flow / state HTTP request and checking the result • Development model codes and content • UI may be tested • Testing without the server or the network traffic
- 38. Pros • Accessible API • Reusable API • REST offers minimal HTTP overhead • Decoupling • network is utilized only when necessary • Application flow / state (no page reloads) • no data (e.g. HTML or • Development model CSS) overhead when transferring only payload • Testing data (e.g. JSON or XML) • Network traffic
- 39. Cons • some server frameworks have REST support • MVC support on • Framework support client depends solely on the chosen toolkit
- 40. Cons • single page web applications are difficult • Framework support to crawl and index • RESTful API could be • Search engine support crawled and indexed but difficult to rank
- 41. Cons • highly dynamic JavaScript UIs require • Framework support extra work to be accessible for the • Search engine support visually impaired • some JavaScript • Accessibility toolkits offer support for accessibility
- 42. Future work • Authentication • Flexible authorization configuration • per resource • per request method • representations per auth level?
- 43. Thank You