EMPS on the Web - Part 2

This is the second part of the web design for Edinburgh Movie Production Society (EMPS). For the first part, please visit EMPS on the Web - Part 1.

In the first part I have explained that a direct link from a web browser to a web page on the web server is not a good idea.

http://www.emps.tk/home_folder/sub_folder/sub_sub_folder/sub_sub_sub_folder/dspHelloWorld.html

Example of a link to a nested web page, a BAD design

In addition, I have defined two words for this design.

the web browser is named the VIEW

the web page is named the MODEL

A direct link from a VIEW to a MODEL is NOT recommended, because of the complexity of maintaining this 'spaghetti' of links by the web designer.

What IS recommended is the use of a central point of entry, through which the underlying web page(s) are called.

the central script on the web server is named the CONTROLLER

If, for example a script 'index.php' is stored on the web server than each link from a web browser (VIEW) to a web page (MODEL) is as follows:

http://www.emps.tk/index.php?fuseaction=circuit.fuseaction

An example of circuit is 'public'
An exampe of fuseaction is 'pageView'

Thus,

http://www.emps.tk/index.php?fuseaction=public.pageView


This solution, that 'hides' all the folder information from the web visitor, is following a design pattern, known as Model-View-Controler (MVC).

Hence, I will give an example of how this has been used for the web design of EMPS. Ready... here we go!



The request for a web page by means of the MVC design pattern

STEPS (summary):

1 - An EMPS web visitor requests a web page by typing in the browser http://www.emps.tk/index.php?fuseaction=public.pageView [view details]

2 - The request for public.pageView is received by the script 'index.php' in the default web server folder, named 'htdocs'. This script forwards the request to the script in the sibling folder, named 'scripts' and further down into the 'fusebox' folder. [view details]

NOTE: for security the htdocs and scripts folders are siblings, not nested. This prevents direct access to the scripts folder by web visitors.

3 - The 'fusebox' folder holds the logic that may direct the request to the 'controller' folder. Hence, it is in the 'controller' folder where requests are orchestrated. [view details]

4 - After a lookup in a list of requests by name, this particular request is forwarded to the 'view' folder. [view details]

5 - The 'view' folder holds scripts that format information and generate a web page, which is sent back to the Internet. [view details]

6 - The Internet delivers the web page to the browser, it appears on the web visitor's screen. [view details]

A lot of navigation and orchestration one would think, does that have an advantage over direct access to the web page?

To answer that question with "YES", I will have to explain the inner workings of the FuseBox.

Hold on... it is a bumpy ride !

STEPS (detailed)

1 - Although it is possible that a web visitor has enough information about the web site that (s)he decides to type the full request in the web browser, it is more likely that (s)he just hits a hyperlink on a previous web page that starts the request. For example, the previous web page has a button "Next Page" that can be clicked. This does not influence the effectiveness of the MVC design pattern.


2 - The script on the Server that is referenced in the request, hence 'index.php', has the following content:


Content of htdocs/index.php

Because of the fusebox application path code line: "../scripts/fusebox" the script will automatically forward the request to the file fusebox.xml.php in the scripts/fusebox folder.



Content of scripts/fusebox/fusebox.xml.php

This needs some additional explanation:

FUSEBOX (by www.fusebox.org)

...


3 -
...

4 -
...

5 -
...

6 -
...