The purpose of this section is to review a selection of languages and frameworks for Web application development, with a particular emphasis on Django, and to briefly compare them.
For good software engineering reasons, many interactive applications are designed using the model-view-controller framework to separate concerns:
.NET is Microsoft's collection of technologies for Web development. At one level, using ASP.NET is like using PHP or JSP with scripts written in any of the .NET languages, normally Visual Basic (VB) or C# (Microsoft's alternative to Java). Higher-level frameworks are based on the model-view-controller pattern. Development is expected to be performed in a proprietary develpment evenironment such as Visual Studio.
Java Enterprise Edition (Java EE) is a mature, complex platform for developing Web applications, developed and promoted by Sun. Several model-view-controller frameworks are available for Java EE. Traditional Java EE applications required several independent libraries for different purposes such as routing, object-relational mapping and templating. The learning curve was steep.
Play is a more recent framework that is modelled closely on Django (below) and Ruby on Rails
Many PHP applications are developed without using a framework at all. In this case, the developer is responsible for providing any reusable structure and for separation of concerns in the application. Often an HTML template system is used but no ORM is used.
Let's study a simple and familiar auction application. You can download a Zip archive of the source code to study it.
(You must be within the griffith University domain to use the application or download the Zip archive.)
This solution uses a model-view-controller pattern partially and incompletely:
PHP does provide several more complete model-view-controller frameworks, e.g.:
In my opinion, Python and Ruby are better foundations than PHP for building higher level frameworks.
There are also several content management frameworks based on PHP. These attempt to allow developers to build Web applications by specifying an information architecture and providing content without having to write any code at all. The two most widely used such frameworks are:
Ruby on Rails was developed to make Web development easier and faster. It addressed the low-level of PHP and the complexity of Java EE and ASP.NET. It aims to be "a framework that makes it easier to develop, deploy and maintain Web applications" (Thomas and Hansson, 2007).
Ruby on Rails (or Rails for short) is based on two main principles:
Systems developed with Rails are based on the model-view-controller architecture.
Rails has developed an enthusiastic and supportive user community and is becoming increasingly used for small to large applications, including twitter.
It's design takes advantage of the excellent object-oriented programming language Ruby.
Arguably, Rails takes principle 2 too far. This imposes restrictions on developers, which make it difficult to develop applications whose structure differs from the one expected by the Rails developers.
Django is a successor to Rails, which uses the excellent programming language Python instead of Ruby, and which attempts to offer developers greater flexibility than Rails does.
Django was recently adopted for use in the Google App Engine, a service that provides free or at least low-cost Web hosting to users.
Django is described in more detail below as a typical example of a modern Web application development framework.
Django is a free, open-source, widely available, practical, well-documented, labour-saving Python-based framework for Web application development. It can be easily installed on all common platforms.
It is used for implementing some of the Web's largest applications, including several online newspapers, including The Washington Post.
Like Rails, Django is also based on the model-view-controller pattern, but is more flexible (and uses different terminology).
A Django "project" (application) is a directory (e.g., blog_project) that contains:
Every "application" (component) directory (e.g., user, blog) contains:
From the "project" directory, you can give a command
$ python ./manage.py runserver [hostname:8000] &to launch the Django server for the application and then you can enter URLs of the form
http://hostname:8000/blog/into a browser to use the application.
The real advantage of Django over PHP is that it improves development, deployment and maintenance by making implementations shorter, better structured, and more flexible. Below are examples to support this claim. Many of these examples are specific cases of the DRY principle.
There is no need to create tables, corresponding to the Django models, as this is done automatically, based on the model class definitions.
There is no need to define SQL insertion and selection queries, as simple Python function calls are translated into SQL queries.
There is no need to sanitise user input to avoid SQL-injection attacks, as this is done automatically in translating Python function calls to SQL queries.
In the simplest case, we can construct a form directly from a model, and construct code to process form data directly from the form. So there is no need to repeat the list of fields in the model, in the SQL "create table" statement, in the form definition, in the SQL "select" statement, and in the script that processes the results of the SQL "select" statement.
It is also possible to automatically validate user input depending on the field type in forms.
It's possible to automate the display of a list of objects, with links to details of each object. By adding a single attribute, the list will be displayed one page of results at a time.
By editing the admin.py configuration files, it's automatically possible for registed users to have superuser access to all application tables. It's further possible for such superusers to assign authority to perform selected operations to selected users. A project-specific administration interface is constructed automatically. (Compare with the generic interface provided by phpMyAdmin.)
Django provides support to greatly simplify the management of user registration, logins and permissions.
It's unfamiliar to many developers.
There is a steep learning curve before you can write your first application.
There are performance problems in hosting many different Django sites on the same server.
Here we expand on the above points and work through an example.
The three books listed above are all available in print and/or online through the University Library.
A Django project is a directory where all information about a single self-contained Web application is stored. To create a project, give the command:
$ django-admin.py startproject projectname
This creates a directory projectname containing, in particular, the files README.txt, settings.py and urls.py. (These files may have slightly different contents on grue from the standard distribution.)
You can run a development server for this project with the commands
$ cd projectname $ python manage.py runserver 0.0.0.0:8000You can then access the (trivial) project by entering the following URL into your browser:
Normally, no stored data is associated with a Django project. Data is associated with specific apps (below) instead.
To create an app, inside a project directory, give the command:
$ python manage.py startapp appname
This command creates a directory appname containing, in particular, a file models.py (for defining the data used by the app) and a file views.py (for defining the Python methods, or views, called when HTTP requests to particular URLs are made). Other important files concerning URLs (urls.py), forms (forms.py) and admin (admin.py) are also stored in the app directory.
In general, there is a many-to-many relationship between projects and apps: one project may use several apps, and one app may be used in several projects. For this reason, it's important to try and keep the definition of each app independent of particular projects, if possible. (However, it is common for each app to be associated with a single project.)
The readme file of a project identifies the project and its author, summarises its purpose, describes how to use the project, and possibly summarises the implementation of the project. It is provided for the benefit of (other) developers (and examiners) who may need to maintain the project.
The settings file of a project is where information is stored about the database used, the database access details, the time zone used, the URLconfs used, the apps used, the templates used, the media files used, and so on.
A URL configuration file (aka a URLconf) is a mapping from URLs to Python methods called "views". A URLconf maps each URL to the Python method called when an HTTP request to that URL is made. For example, if we want every url of the form http://host/polls/ to be processed by a Python method index, and every url of the form http://host/polls/12/ to be processed by a Python method detail with argument 12, then the URLconf would need to contain lines of the form:
(r'^polls/$', index), (r'^polls/(?P<poll_id>\d+)/$', detail),
Here, "polls/\d+/" is a regular expression that matches any URL path of the form polls/digits/, where digits is a sequence of one or more digits, and poll_id is an identifier that is used in the view detail to store the particular digit sequence.
To keep each app independent, it's desirable to have a separate URLconf for each app. This requires the URLconf for a project that uses that app to contain a line of the form:
# App-specific URLS (r'^tag/', include('projectname.appname.urls')),
The mapping from each URL of the form /tag/anything/ to its corresponding view must then be defined in the URLconf urls.py of the app appname. (See the Django tutorial as a first example.)
The design of the URL patterns for a project and its apps is a particularly important task.
A model is basically a Python class definition, with extensions. Each such class definition is translated by Django into an equivalent SQL "create table" statement. It's important to note that the SQL table so created always has an automatically generated, non-null, integer, primary key called id. It's possible to specify a range of field types, foreign keys, and many-to-many relationships in such model definitions. Django can use this information for form input validation and query answering.
Each model belongs to a particular app.
After defining - or extending - a model, it can be translated into the corresponding relational table in your nominated database with the command
$ python manage.py syncdb
which performs the necessary object-relational mapping to create the tables in the database specified in the project's settings.py file.
The Django overview describes how to define models (tables), how to create and update model instances (rows), and how to query the sets of defined instances.
Django provides an API to selectively retrieve data without having to use SQL (though you can if you absolutely need to).
The Django overview describes how to create and update objects, retrieve single objects or lists of objects, follow one-many links and perform implicit joins, all using an (in principle) simple object-oriented API.
A view is a Python function that responds to an HTTP request for a particular URL and that normally returns an HTML document. Every view has request as its first argument. This argument may contain form data, described later.A view may also contain additional arguments, e.g., the poll_id value used in the example above. The simplest way to return an HTML document is by using the function render_to_response, which takes an HTML template and a context (a Python dictionary) as arguments, and returns the HTML document resulting from substituting the context into the template.
Each view belongs to a particular app.
A template is a skeleton of an HTML document. It may refer to "variables" whose values are passed in through contexts. Django uses its own template language, but others may be used instead. The Django template language is easy to learn from examples.
Typically, each app will use several different templates. To ensure each template in the same app has the same structure, it's convenient to use a single "base template" and to derive each separate template from the base template.
Templates associated with an app are normally stored in a templates subdirectory of that app (though some examples used in this course store them in a templates/app subdirectory of the app's project).
This approach of designing Web applications by separating the models (data), views (code) and templates (presentation) is called the MVT pattern. It's equivalent to (but clearer than) the more familiar model-view-controller (MVC) pattern used in Java and in Ruby on Rails.
(Because URLs are so important in this process, it is perhaps more precise to say that Django uses a UMVT pattern.)
Form data is transferred as a dictionary in the field request.GET or request.POST of the argument request. From this dictionary, one can obtain the value passed from the form, as the value for the key that equals the name of the corresponding form element, e.g., request.GET['quantity'].
In fact,there are much better, more concise ways of managing form data, directly from the corresponding model. Moreover, it is very easy to validate user-entered form data.
To summarise, to create a Django application, we must create a Django project and one or more Django apps.
In each app directory, we must edit the urls.py, models.py and views.py files, and normally create admin.py, forms.py, tests.py, and other files. We normally also create a templates subdirectory for define the templates for that app.
The key to designing the application is to focus on the (U)MVT pattern: URLs, models, views, templates. Also, transition design, as documented in a transition diagram.
Django provides very powerful facilites for administering users, groups, models (data), sites, and so on from a project-specific, Web-based interface.
Django is primarily designed to serve dynamic documents. It's
unnecessarily inefficient at serving static (or media)
files, video files, and so on. Such documents should be stored separately
so they can be served efficiently in a production environment. For
development, and in this course, it suffices to use the approach described
in the Django documentation: How to
serve static files and store them in a
subdirectory of the project.
Demonstration of application and inspection of source code...
This can be copied from ~s352978/pub/guestbook-queries_django.zip on dwarf, expanded and studied.