## Client-side Technology

### Motivation
- Historically, only static HTML pages with forms existed
- An *Application* was implemented by the Common Gateway Interface (CGI)
- **Common Gateway Interface:**
	- i.e., *0th generation of frameworks*
	- URLs link to binary files executed by the server
		- Environment variables and GET parameters are passed to the binary
		- Output is written to `stdout` and read by the Webserver 
	- State-less implementation (good scalability)
	- Language: Usually Perl
	- Disadvantage:
		- Start process on every request (resource intensive)

---

### Frameworks for Web Applications

### 1st Generation (Templates)
- **Integrate** the interpreter of the programming language in the Webserver
- Use *Template*s: 
	- Mix of code and HTML
	- e.g., PHP, ASP.net, Java Servlet
- Libraries:
	- URL parsing
	- Support of HTML generation
	- Session management
	- Database access
- e.g., PHP, ASP.net (Active Server Page), Java Servlet

#### 2nd Generation (MVC)
- **Model-View-Controller** (MVC) architectural pattern (*see below*)
- Goal:
	- Decompose Web applications
	- Apply architectural pattern to Web applications
	- Handle dynamic data
- Map objects to database
- e.g., Ruby on Rails, Django

#### 3rd Generation (JS)
- JS-based frameworks executed in the browser
- Goals:
	- More *application character*
	- Interactive, responsive applications
- Less requirements for the server-side
	- Node.js, NoSQL database
- Uses concepts of the MVC architeture and Templating
- e.g., AngularJS, ReactJS

---

### Model-View-Controller
- Architectural pattern to **separate** logics, visualization and storage
- Used in many frameworks
- Currently, applications consist of components which are structured in the MVC pattern
- Components:
	- *Model*: Manages application data
	- *View*: Presentation of website (e.g., HTML/CSS)
	- *Controller*: Application logic

![](images/09-mvc.png)
#### Model
- Manages application data (e.g., database, JS objects)
- Provide non-static data (which are required by view and controller)
- Are related/dependent on the database schema
- Often, an Object Relational Mapper (ORM) is used
- Database scheme is influenced by the Web application
- Possible conflict:
	- Database scheme and application model
	- e.g., applications are more dynamic and require more flexibility

#### View
- Finally, Application must provide HTML/CSS page
- Usually, use *templates*
- *Template*:
	- *Partial document*
	- Pre-defined document with placeholders for dynamic content (inserted by Web server/application)
	- Advantages:
		- HTML structure is preserved
		- Good estimation about the amount of dynamic content
		- May be rendered by server or by client

#### Controller
- Responsibility:
	- Connect model and views
	- e.g., communication with the server, transfer of data (create, update, ...)
	- Manages the displayed/rendered templates
	- React to user events (e.g., scripts, DOM events, interaction with server)
- 2nd generation framework: Controller on server-side
- 3rd generation framework: Controller executed inside the browser

#### Example: Django
- Python MVC framework
- Also called *MTV framework* because the naming is different
- *Model*: Model
- *Template*: View
- *View*: Controller

---

### Single Page Applications
- *Single Page Application*:
	- Web application reacting dynamically to user input without reloading the HTML
- Advantage:
	- Less communication
	- Better response time
- Problem: User navigation kills application state
	- Formerly, different sites had different URLs
	- User uses browser navigation features:
		- Menu bar of the browser
		- History next/back
		- Bookmarks
		- Reloading a page
		- Exchange of URLs between users
- Solution:
	- Replace the native navigation behavior of the browser to keep the application state
- Approaches:
	- *JS Warning*:
		- Warning if users leaves website
	- *Deep Linking* (with History API)

#### Deep Linking
- Goal:
	- URL should contain the *context* of an application (to recreate the state)
- *Question*: What belongs to the state?
	- *Defined by the developer*
	- What about popup windows?
	- Does the state depend on the user's browser (e.g., link sharing)?
	- What about navigation (e.g., reloading?)
- Approaches:
	- Link is updated dynamically
		- Good for reloading/bookmarking
		- Bad for sharing the link
	- Actively create a deep link
		- URL in address bar looks well
- Navigation inside the application:
	- Location API
	- Router
	- Browser behavior
	- History API

##### Location API
- Accessible using `window.location`
	- Manipulate the URL
- Parts: `protocol, hostname, pathname, search, hash`
	- `pathname`: Path component
	- `search/hash`: Additional information like query terms and fragment 

##### Router
- Usually, SPAs and frameworks have a routing component
	- Map an URL to a function/controller
- e.g., Observer pattern

##### Browser Behavior
- Usually, link clicks are handled by the browser
- Can be prevented with `e.preventDefault()`
- e.g., form submit (handle submission by JS)

##### History API
- Purpose:
	- Record the history of the browser (`window.history`)
- Idea:
	- Usually, web site is re-rendered (create a new `document` instance)
	- Instead, update the `document` instance
- Functions:
	- `go([delta])`:
		- Navigate `delta` steps forward
		- Fires a *popstate* event containing the state of the history entry (register at this event)
	- `pushState(state, title, url)`:
		- Create an entry in the history without reloading the site
		- `state`: Serializable JS-object (max. 640 KB)
		- `title`: Currently ignored by the browsers
		- `url`: URL (absolute/relative) for the entry (SOP)
		- After the call, older entries are lost 
	- `replaceState(state, title, url)`:
		- Replace an entry without reloading the site
		- Within the domain (*SOP*)
		- *see above*
- Goal:
	- Prevent the native behavior of links (`preventDefault()`) 
	- Use `pushState()` and `replaceState()`
- Exceptions:
	- *Click* with hold functional keys