Today we start the chapter 4 about Web presentation
So let's go 😁
Web Apps and Web Servers
Preparing a Web app begins with the server software itself. Usually this has some form of configuration file that indicates which URLs are to be handled by which programs. Often a single Web server can handle many kinds of programs. These programs may be dynamic and can be added to a server by placing them in an appropriate directory. The Web server’s job is to interpret the URL of a request and hand over control to a Web server program.
Two forms of structuring programs in web server
- 1️⃣ Script Form
The script form is a program, usually with functions or methods to handle the HTTP call. Examples include CGI scripts and Java servlets. The program text can do pretty much anything a program can do, and the script can be broken down into subroutines, and can create and use other services. It gets data from the Web page by examining the HTTP request object, which is a string. In some
environments it does this by regular expression searching of the request string—Perl’s ease of doing this makes it a popular choice for CGI scripts. Other platforms, such as Java servlets, do this parsing for the programmer, which allows the programmer to access the information from the request through a keyword interface. This at least means less regular expressions to mess with. The output of the Web server is another string—the response—which the script can write to using the usual write stream operations in the language.
- 2️⃣ Server Pages Form
Writing an HTML response through stream commands is uncomfortable for programmers, and nearly impossible for nonprogrammers, who would otherwise be comfortable preparing HTML pages. This has led to the idea of server pages, where the program is structured around the returning text page. You write the return page in HTML and insert into the HTML scriptlets of code to execute at certain points. Examples of this approach include PHP, ASP, and JSP.The server page approach works well when there’s little processing of the response, such as “Show me the details of album # 1234.”
- 3️⃣ MVC is born
Because the script style works best for interpreting the request and the server page style works best for formatting a response, there’s the obvious option to use a script for request interpretation and a server page for response formatting. This separation is in fact an old idea that first surfaced in user interfaces with the pattern Model View Controller . Combine it with the essential notion that nonpresentation logic should be factored out and we have a very good fit for the concepts of this pattern.
- 🚩 The name "Controller"
Model View Controller is a widely referenced pattern but one that’s often misunderstood. Indeed, before Web apps appeared on the scene, most presentations of Model View Controller (330) I sat through would get it wrong. A main reason for the confusion was the use of the word “controller.” Controller is used in a number of different contexts, and I’ve usually found it used in a different way to that described in Model View Controller. As a result I prefer to use the term input controller for the controller in Model View Controller.
MVC : the how and the why ?
- 1️⃣ The How
A request comes in to an input controller, which pulls information off the request. It then forwards the business logic to an appropriate model object. The model object talks to the data source and does everything indicated by the request as well as gather information for the response. When it’s done it returns
control to the input controller, which looks at the results and decides which view is needed to display the response. It then passes control, together with the response data, to the view. The input controller’s handoff to the view often isn’t always a straight call but often involves forwarding with the data placed in an agreed place on some form of HTTP session object that’s shared between the input controller and the view.
- 2️⃣ The Why
The first, and most important, reason for applying Model View Controller (330) is to ensure that the models are completely separated from the Web presentation. This makes it easier to modify the presentation as well as easier to add additional presentations later. Putting the processing into separate Transaction Script (110) or Domain Model (116) objects will make it easier to test them as well.This is particularly important if you’re using a server page as your view.
Next time we will talk about the subject of View Pattern 😃
Top comments (0)