Tallaght Campus

Department of Computing

Dynamic Web Content
  1. Static vs. Dynamic Web Content

    Static vs. Dynamic Web Content

    • Initial content on the WWW was static: on receiving an HTTP request, the server would fetch the requested html page from its file system and send it to the client in the content section of the HTTP response message.
      Figure: WWW Session with Static Content (picture by E. Lee)
    • However, the content sent to the client does not have to come from a file. It can be created on the fly by the server, from partial HTML files, data read from a database or generated in some other way. This is server-side-generated dynamic content.
    • Finally, the content sent to the client does not have to remain the same as the client views it or interacts with it. It can be modified by scripts sent to the client together with the HTML content. This is client-side-generated dynamic content.
    • Dynamic content can differ depending on various factors, for example:
      • the location of the client (localisation)
      • the identity of the user on the client side (customisation)
      • data in the server-side database (for example a list of products on offer by from website owners)
      • time of day (e.g. a shop's website might display 'open' or 'closed')
      • elapsed time (e.g. animations)
  2. Server-Side-Generated Dynamic Content

    Server-Side-Generated Dynamic Content

    • A URL may refer to a script based on the server and when such a URL is requested the server runs the script to generate the HTML to be sent in response to the request.
      Figure: WWW Session with Server-Generated Dynamic Content (after picture by E. Lee)
    • The early API for server-side scripting was common gateway interfice (CGI), which could be used with many languages e.g. C, PHP and Perl. While servers still support it, not much development takes place in CGI any more.
    • Numerous server-side scripting languages are used today, for example: PHP, Ruby, Python, JavaScript, ASP.NET, C#, Java. Older ones are supported directly by web server implementations e.g. PHP on Apache.
    • Web application frameworks are 'software constructions' that make the development of web applications easier by providing ready-made functionality for reusable functions.
      • They generally provide an interface for a single language, e.g.
        • Laravel (PHP)
        • Ruby on Rails (Ruby)
        • Django (Python)
        • Express.js (JavaScript)
        • ASP.NET
        • Play (Java, Scala)
      • The type of functionality frameworks provide is:
        • 'scaffolding' for configuration of common activities
        • data access through object-relational mapping (ORM)
        • front-end template system
        • security, caching etc.
    • Web content management systems allow non-programmers to author content for the web and to carry out some configuration but do not provide a programming interface. Examples are WordPress and Joomla.
    • Server-side scripts use information sent by the client in the HTTP request as inputs for processing. Information can be transferred to the server in the form of:
      • parameters at the end of the URL
      • form input (including invisible fields)
      • cookies
  3. Client-Side-Generated Dynamic Content

    Client-Side-Generated Dynamic Content

    • Once content is loaded in the browser, it can be modified by scripts interpreted by the browser. This is how dynamic content is created on the client side.
      • The standard language for client-side scripting is ECMAScript:
        • standardised by ECMA International - European association for standardizing information and communication systems
        • a standard that grew out of an implementation - Javascript (an implemented language) came first and the standard was specified based on that language
        • has a number of implementations, for example Javascript, JScript (Microsoft), ActionScript (Macromedia, later Adobe) the European Computer Manufacturers' Association (ECMA)
      • JavaScript:
        • was invented by Brendan Eich in Netscape in 1995 (originally under the name LiveScript)
        • was the basis for the standard, ECMAScript, introduced in 1997 to underpin it
        • is used in all browsers today
        • is interpreted by the browser 'scripting engine'
        • derives its power from being given full 'write' access to the web page displayed in the browser, through document object model (DOM) object
          Figure: A portion of the DOM (picture by E. Lee)
        • is supported by a number of other APIs (in addition to DOM), e.g. geolocation, canvas, browser-based media APIs and third-party APIs such as Google Maps
        • is further supported by libraries such as JQuery that provide packaged functionality implemented in JavaScript
        • is always executed (by the browser) to handle an event, for example when:
          • the page is loaded (onload)
          • the page is unloaded (onunload)
          • an element is clicked (onclick)
          • the mouse pointer exits the area of an element (onmouseout)
        • is used for the implementation of diverse functionality, for example:
          • display a message box
          • edit and validate form information
          • create a new window
          • display of current date or other information that depends on the current context
        • can be used with a front-end framework such as React or Angular.js for the building of more complex 'single-page applications'
    • Other ways of producing dynamic content have been used in the past but are now obsolete or being phased out. For example:
      • Java applets - Java code that ran in Java Virtual Machine kicked off by the browser
      • Adobe Flash - animation format that can be played by a browser plug-in
    • The tasks performed by client-side scripts are generally not mission-critical, as relying on not-known-in-advance (from the point of view of the website developer) factors such as browser type or configuration is a risk. The more important tasks are left to the server side.
  4. References