Related buzzwords: Layout design, Interaction & Visual design, CSS, Usability, Accessibility, User Centred Design, Customer Experience, look&feel

Front End Concepts
Context
The purpose of many web systems is to retrieve data from a data repository and display it for the user in the front end. After the user manipulates the data in front end, the system retrives and updates the data in repository DB, and generates the response the front end.
We can say that the front end is just an interface between the user and the back end. The front end is responsible for enabling interaction with the user and waiting for the requested response from the server.
The key flow of information is between the data stored on some server repository DB and the frontend user interface in browser. The presentation layer, i.e. look&feel of user interface tends to change much more frequently than the data storage system.

The Front end is related to:
- Layout design,
- Visual design,
- Interaction design,
- Usability,
- Accessibility,
- User Centred Design,
- and Customer Experience.

Simply said, front-end engineers are GUI developers, i.e. graphical user interface designers. Their development environment is browser.


----------------------------------
Layout Templates Pattern
----------------------------------
Frontend rendering can have several layouts that provide a predefined structure to the page, but you cannot customize these layouts. If you need more flexibility in designing the layout, you can convert the various templates to magic dynamic pages renderings.

Rearrange data_fields inside layout template
Let's say that you have a periodic report that you need to create each month for your staff. You only need a subset of the report information and you prefer to lay out the data in a customized way. You can just move and arrange cells in a design layout that you want, delete the cells that are not necessary for the monthly staff report, and then format the cells and worksheet to suit your preference.
----------------------------------
Model View Controller Pattern
----------------------------------
The MVC is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data. The MVC pattern hinges on a clean separation of objects into one of three categories:
- models for maintaining data, in some data repository on server;
- views for displaying all or a portion of the data in the clients Frontend, i.e. in the browser;
- and controllers for handling events that affect the model or view(s).

The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes [Burbeck92]:

Model.
The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

View.
The view manages the display of information in the browser.

Controller.
The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.

Because of this separation, multiple views and controllers can interface with the same model. Even new types of views and controllers that never existed before can interface with a model without forcing a change in the model design.

---------------------------
RoR MVC vs Django MTV
---------------------------
Django call their separation of layers MTV (model-template-view) instead of the traditional MVC. In MTV context, the template is referred to data structure, to field names and types. Using template instead of Rail’s view seems more obvious to me. The MVC pattern does not fit optimally in the rapid web development.


---------------------------
Securing a Front-end
---------------------------
Securing a Front-end/Back-end Solution
There are additional factors to take into account when establishing User-Level security for a solution that has been split into a back-end database that contains only tables, and a front-end database that contains the remaining objects plus links to the tables in the back-end database. You may not know the name of the specific network location for the back-end database in advance, or you may want to allow a database administrator to move the back-end database. In either situation, users must be able to relink the tables in the back-end database.
Because users have Modify Design permission for the linked tables in the front-end database, they can reset the links to the back-end tables if the location of the back-end database changes. They can't make any modifications to the design of the actual tables in the back-end database.