L10 Web Programming

1,068
-1

Published on

The web has become the default and standard user interface for enterprise programming. In this lecture we look at the challenges of adding a web user interface to enterprise systems. The main design pattern we look at is the classical Model View Controller.

The idea is to break user interface components into three distinct roles. The Controller is the entry of the request, and handles the parameters that come with the request. The controller uses the model for the "state" or domain logic, be it calculations or getting some data. The model will deliver some data that needs to be rendered. It is the responsibility of the view to render the user interface.

We will also briefly look at the Play! framework: http://www.playframework.org/

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,068
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

L10 Web Programming

  1. 1. Lecture 10 Web Programming
  2. 2. Reading  Fowler – Chapter 4 Web Presentation – Chapter 14 Web Presentation Patterns  Patterns – – – – – – – Model View Controller (330) Page Controller (333) Front Controller (344) Template View (350) Transform View (361) Two-Step View (365) Application Controller (379) 2
  3. 3. Agenda  The Web Layer – Model-View-Controller (330)  Input controller patterns – Page Controller (333) – Front Controller (344) – Application Controller (379)  View patterns – Template View (350) – Transform View (361) – Two Step View (365) 3
  4. 4. Play! Framework  We will be using Play! framework – Based on MVC
  5. 5. The Web Layer 5
  6. 6. The Challenge  How to design web applications?  How to separate user interface from the business logic? – User Interface is an HTML string  How to provide OO design? – Code reuse  How can we abstract underlying system – For example data base 6
  7. 7. Presentation and Web Layers  Embedded and Desktop clients  Web Browser is a different type of client 7
  8. 8. Web Applications 8
  9. 9. Web Layer Design  How to design Web Applications Web Browser ? Web Server HTML/HTTP Web Application DB Server ?  Two approaches – Script based – Code using HTML – Server Page based – HTML page with code 9
  10. 10. Web Applications  Client is a web Browser – All interface is HTML with graphics  Server is configured to map URLs to applications – The web application can be script or page 10
  11. 11. Script Based  Useful when the logic and the flow is important – Request is not easily mapped to a single page  Examples – CGI, ISAPI, Java Servlets 11
  12. 12. Server Page Based  Useful where there are lots of pages – Flow is not as important – Each request can easily be mapped to a page  Examples – PHP, JSP, ASP 12
  13. 13. Web Design  Web Layer must handle the request and the response 13
  14. 14. The Three Layers  Presentation – User’s interface to the system – User can be another system – Accepts input, displays views  Domain – The Application of the system – The “Business logic” – Has the tendency to creep into presentation and data source  Data Source – Connection to the database 14
  15. 15. Model-View-Controller 15
  16. 16. Model View Controller Splits user interface interactions into three distinct roles  Separates the user interface from the logic – Originally from 70s Smalltalk – Similar to Doc/View in MFC  MVC considers three roles – – – – Clear separations of concerns Model: The domain layer handles state View: Presentation logic Controller: Connects the model and the view 16
  17. 17. Model View Controller  How It Works – Model: The domain layer handles state – View: Presentation logic – Controller: Connects the model and the view 17
  18. 18. Model View Controller  Benefits – Separation of the view from the domain logic in the model – This is key in any presentation design  Importance of MVC – View and model are different concerns – View can change, usually the model is the same – Easy to test the model without the view  Coupling Dependencies – View depends on the model, but the model is not depending on the view 18
  19. 19. Model View Controller  When to Use It – The value is in the separation of concern – Separating the model and the view – As this separation is so fundamental in any software design, any non-trivial system should use MVC in some form 19
  20. 20. MVC in Web Design  Web Applications are request/response based  Input Controller – – – – Takes the request Examines the input parameters Calls the Model Decides how to handle the response – Sends the control to the View for rendering 20
  21. 21. MVC in Web Design 21
  22. 22. MVC Patterns  Input controller patterns – Page Controller (333) – Front Controller (344) – Application Controller (379)  View patterns – Template View (350) – Transform View (361) – Two Step View (365) 22
  23. 23. QUIZ What design principle is the most important in Model View Controller? ✔ A) Separation of different concerns B) All request go the same place C) Easy to test different components D) Easy to change the view
  24. 24. MVC Patterns  Input controller patterns – Page Controller (333) – Front Controller (344) – Application Controller (379)  View patterns – Template View (350) – Transform View (361) – Two Step View (365) 24
  25. 25. Page Controller An object that handles a request for a specific page or action on a Web site  One input controller for each logical page of the web site 25
  26. 26. Page Controller  How It Works – One Page Controller for each logical page  Page controller as Script – Servlet or CGI program – Useful for web application that need some logic and data  Page controller as a server page – – – – ASP, PHP, JSP Combines the Page Controller and Template View Helpers used to get data from the model Works fine if the logic is simple or none 26
  27. 27. Page Controller pattern 27
  28. 28. Page Controller  The basic responsibility of a Page Controller are – Decode the URL and extract any form data to figure out all data for the action – Create and invoke any model objects to process the data. • All relevant data from the HTML request should be passed to the model so that the mode objects don’t need any connection to the HTML request – Determine which view should display the result page and forward the information to it 28
  29. 29. Page Controller  When to Use It – Works well in a site where the controller logic is simple – When the controller logic is simple the Front Controller adds too much overhead  Examples – Simple Display with a Servlet Controller and a JSP View – Using a JSP as a Handler – Page Handler with Code Behind 29
  30. 30. Front Controller (344) A controller that handles all requests for a web site  One controller handles all requests – The handler dispatches to command objects for behaviour particular to the request 30
  31. 31. Front Controller  How It Works – Takes care of common tasks, for example security, authentication, i18n, and so on – Built on Commands – Usually implemented as script, not page  Two phases – Request handling – Web Handler – Command handling – Command classes 31
  32. 32. Front Controller  Request handling – Web Handler – – – – Any common logic Authentication, Web Security etc. Changes in one place apply for the whole site Handler creates the requested command  Command handling – Command classes – Specific functionality – Command classes extend abstract classes and implements process method – Can be separated form the web infrastructure 32
  33. 33. Front Controller  Handler takes the request – Examines the URL – Creates command and calls the command 33
  34. 34. Front Controller  Web handler can have commands statically or dynamically – Static case has the advantage of explicit logic and compile time error checking – Dynamic case has some property file to map request URL to command classes – Dynamic case has more flexibility to add new commands 34
  35. 35. Front Controller  When to Use It – Front controller is more complicated design than the Page Controller – Only one controller needs to be configured in the web server, the handler takes care of the dispatching – With dynamic commands, you can easily add new commands – Single point of entry allowing centralized logic 35
  36. 36. Application Controller A centralized point for handling screen navigation and the flow of an application  Applications that have significant amount of logic about the screens to use at different points – For example Wizard style applications – Screens depend on the state 36
  37. 37. Application Controller  How it works – Two responsibilities: Decide which domain logic to use and deciding the view 37
  38. 38. Application Controller  Can be used with Command pattern – Commands execute the domain logic – Not easy to determine what is domain logic and what is the application logic  State machine – The Controller must maintain a state  When to Use It – If the flow and application logic is complex and simple controllers need to share code 38
  39. 39. MVC Patterns  Input controller patterns – Page Controller (333) – Front Controller (344) – Application Controller (379)  View patterns – Template View (350) – Transform View (361) – Two Step View (365) 39
  40. 40. QUIZ We are designing an application for corporate tax reduction which have multiple of screens and various conditions and exceptions. What controller pattern might be useful A) B) C) ✔ D) Input Controller Page Controller Front Controller Application Controller
  41. 41. MVC Patterns  Input controller patterns – Page Controller (333) – Front Controller (344) – Application Controller (379)  View patterns – Template View (350) – Transform View (361) – Two Step View (365) 41
  42. 42. Template View Renders information into HTML by embedding markers in an HTML page  Place markers in HTML page that can be resolved into calls to get dynamic information 42
  43. 43. Template View  How it Works – Embed markers into static HTML page when it’s written – When the page is used to service a request, the markers are replaced by the results of some computation  Server Pages for presentation – ASP, PHP, JSP – Page receives data to work with – Allow scriptlets 43
  44. 44. Template View  Embedding the markers – – – – Markers are used for dynamic data <% and %> JSP, ASP Tags such as JSTL and customized Data is sent with the request  Helper Objects – Provide helper object that give the results – Avoids scriptlets and keeps the code in classes 44
  45. 45. Template View  Conditional display – Most Server Pages support conditional tags – Provides some presentation logic <c:if test="${!empty cookie.userName}"> Welcome back <c:out value="${cookie.userName.value}" /> </c:if> – Can lead to bad code and should be avoided if possible – Try to move the condition into helper object or tags 45
  46. 46. Example <jsp:include page="top.jsp" flush="true" /> <table cellpadding="4" cellspacing="4" border="0" width="100%"> <tr><td> <%@ page import="is.ru.honn.domain.User" session="true" %> <% User user = (User)request.getSession().getAttribute ("user"); if (user == null) { %> <h1>Sportvefurinn</h1> Ef þú ert nýr notandi getur þú skráð þig með því að smella á <b>Nýskrá</ Annars, smelltu á <b>Innskrá</b> til að skrá þig inn á vefinn. <% } else { %> <h1>Halló <%= user.getName() %></h1>Smelltu á <b>Leikir</b> til að sjá n <% } %> </td></tr></table> 46
  47. 47. Example 47
  48. 48. Template  Velocity template example
  49. 49. Template  Template Engine will execute the view and create HTML reads View Template Language Model Parameters generates Template Engine HTML
  50. 50. Transform View A view that processes domain data element by element and transforms it into HTML  Transformation of the domain data into HTML – Think how elements are transformed 50
  51. 51. Transform View  How It Works – Organized around separate transforms for each kind of input element – XSLT (EXtensible Stylesheet Language) is one way Each object can be serialized into XML which can be transform to any output using XSLT  When to Use It – – – – Comes down to preference XSLT is awkward to work with without tools Avoids too much logic in the view Easy to test and verify the output 51
  52. 52. Two Step View Turns domain data into HTML in two steps: first by forming some kind of logical page, then rendering the logical page into HTML  Splits the transformation from domain data to HTML into two steps – First transforms the model data into logical page – Second converts the logical page into HTML  Second step can provide additional elements – Global changes to big sites 52
  53. 53. Two Step View  How It Works – The process of transforming the data to HTML is in two steps  Intermediate form – Contains fields, header, footer, etc. – Logical information 53
  54. 54. Two Step View  When to Use It – When we need to separate the formatting from the logical page – Multi-appearance applications that have the same functionality but different looks – When global changes are needed – The second state can be Template View of Transform View 54
  55. 55. QUIZ What pattern is described like this? ✔ A) Template View B) Transform View C) Model View D) Two Step View
  56. 56. MVC Design 56
  57. 57. MVC Design 2. Call the model 57
  58. 58. MVC Design 58
  59. 59. Domain and Presentation  Data from the model need to be accessed by the view – Data is simple classes – Controller handles the flow and decides which view to call – View needs access to data  Two methods – Use Request if lifetime of the data is the request – Use Session if the data must span many requests 59
  60. 60. Domain and Presentation  Single Request – Same request object is used – Use getParameter to get input – Store the data in request using setAttribute – JSP can access the data using the request 60
  61. 61. Combining Model and View Input Controller HTTP/HTML handling Model Parameters View Template Model Domain Layer
  62. 62. Play! Framework 62
  63. 63. Play! framework  Open source web application framework – Written in Java – Build and deployment is all handled by scripts  Follows the model-view-controller architectural pattern  Goals – Optimize developer productivity by using convention over configuration, hot code reloading and display of errors in the browser 64
  64. 64. Play! features         Stateless: Play is fully RESTful No configuration: download, unpack and develop Easy round trips: no need to deploy to an application server Integrated unit testing: JUnit and Selenium support is included in the core Elegant API: rarely will a developer need to import any third party library Static methods: all controller entry points and business logic methods are declared as static CRUD module: easily build administration UI with little code Server built in: Jboss Netty web server is used 65
  65. 65. Play! MVC  Model – Domain specific Java classes  View – User Interface – HTML, XML, JSON  Controller – Java classes that take requests and operate on the model – Results are rendered by the view 66
  66. 66. Play! MVC 67
  67. 67. The Request Life Cycle 1. An HTTP Request is received by the framework 2. The Router component tries to find the most specific route able to accept this request. The corresponding action method is then invoked 3. The application code is executed 4. If a complex view needs to be generated, a template file is rendered 5. The result of the action method (HTTP Response code, Content) is then written as an HTTP Response 68
  68. 68. 69
  69. 69. Creating a Play! app  Unzip play-2.2.0.zip  Add to path  Open CMD or Terminal >play new RuBook  Creates a new appliction >cd RuBook >play run  Runs the Web App  Open a browser and goto localhost:9000 70
  70. 70. 71
  71. 71. 72
  72. 72. 73
  73. 73. 74
  74. 74. Play! in IntelliJ 75
  75. 75. Application.java  input controller – controllers.Application – Requests will go to this Java class package controllers; import play.*; import play.mvc.*; import views.html.*; public class Application extends Controller { public static Result index() { return ok(index.render("Your new application is ready.")); } 76
  76. 76. index.html  View is views.index.scala.html @(message: String) @main("Welcome to Play") { @play20.welcome(message, style = "Java") } 77
  77. 77. Routing  conf/routes contains the routing information # Routes # This file defines all application routes (Higher priority routes first) # ~~~~ # Home page GET / controllers.Application.index() # Map static resources from the /public folder to the /assets URL path GET /assets/*file controllers.Assets.at(path="/public", file) 78
  78. 78. Errors  Play! displays errors – CMD has more information 79
  79. 79. Summary  Web Presenation Patterns – – – – – – – Model View Controller (330) Page Controller (333) Front Controller (344) Template View (350) Transform View (361) Two-Step View (365) Application Controller (379)  Play! framework 80
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×