Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
1 Introduction
This document lists the main components of a web application, and their usual dependencies. Ideas about components of web application are emerging in the development community towards being regarded as relatively loose-coupled or even entirely orthogonal components that one can mix and match to build a concrete web application. Some standards about how to combine some of these components are emerging, and I believe that since this is an easily modularized problem, more and more such agreements will appear in the near future. Note: this document is written in the context of writing web applications in the language Python. For many reasons outside the scope of this document, we believe that Python forms the best basis in terms of language and features to build web applications. However, the concepts are reasonably language-agnostic.
Contents 1 Introduction 2 Motivation 3 Main Components 3.1 Server (also called Gateway) 3.2 Configuration 3.3 Client 3.4 Request 3.5 Response 3.6 Cookie Jar 3.7 Automatic Change Detection 3.8 Logging 3.9 Error Handling 3.10 Application Initialization 3.11 Data Store 3.12 Session Management 3.13 Easy/Pickled Storage 3.14 Authentication 3.15 Resource Mapping 3.16 Internationalization (I18N) 3.17 Form Definition and Processing 3.18 Rendering 3.19 Page Templates 3.20 Automated Testing 3.21 Email Server 4 Useful Extensions 4.1 Automatic Conversions and Caching 4.2 User Management Handlers 4.3 Issue Tracking for Feedback 4.4 Automatic Error Reporting 4.5 Asynchronous Tasks and Scheduler 4.6 Events 5 Innovative Ideas 6 Conclusion
2 Motivation
We would like to code our web application in a way that is as much as possible independent from any web application framework. As such, we need to define a set of minimal interfaces to specific components so that we can eventually completely change the underlying infrastructure, as more and more components mature or become available. This implies that we should eventually be in a position to easily change the underlying components of our web application by providing some glue between the new components and an existing application. This problem is begging for the definition of simple interfaces to provide an environment for a web application. This is where I want to get with this document.
Also, we need to identify dependencies between the various components in order to be able to make sensible decisions regarding the choice and setup code for the underlying framework providing the environment for our application.
3 Main Components
This section lists the components and related interfaces and dependencies.
5/4/12
Twisted Web, Python's own simple HTTPServer, ... The WSGI interface (PEP333) has been designed specifically to address the issue of standardizing the way that various backends communicate with the rest of the web applications. A concrete WSGI server implementation will need to provide a way to connect an application object to it. Application code may want to access some parameters of the server, such as the address or the port that it is listening on. It should be able to provide that. Interfaces IServer Dependencies (None)
3.2 Configuration
We want to be able to specify configurable parameters for our application behaviour in a single place. For example, our application may have a test mode, in which it provides a set of pages specifically for testing. Thus we need a module which provides some generic set of parameters and automatically detect when this input is changed and refresh it accordingly. Interfaces IConfiguration Dependencies (None)
3.3 Client
Information about the client should be made available to the application code, such as the client port, address and hostname. Interfaces IClient Dependencies Environment provided by the server.
3.4 Request
We need to be able to provide information about the request to the application, such as the URL path, and the HTTP headers. Interfaces IRequest Dependencies Environment provided by the server.
3.5 Response
A mechanism for returning a response to the client is required. Features include the need for setting encoding, compression, content type, headers, and the body of the response. We also need to be able to flush some part of the response to the server early. Also, this mechanism needs to allow redirection to another URL, which can be very convenient in many cases. Interfaces IResponse Dependencies Environment provided by the server for writing the response.
5/4/12
We need to provide a way for the application code to access or set cookies in the client browser. Generally, this will only be used for the session management code, but there could be application-specific uses as well, this is why we want to export "some" access to the cookie mechanism. Interfaces ICookieJar Dependencies Environment provided by the server, and for writing the response.
3.8 Logging
Since all the user-visible output goes to a client browser, there needs to be way that the application can trace its behaviour. In the available environment, there should be a simple mechanism for logging. Interfaces ILogger Dependencies (None)
5/4/12
Server mechanism to detect server generation. Perhaps some database access, for synchronizing between children.
3.14 Authentication
Built on top of the session management, the authentication module should provide a way to manage users, groups of users, and roles. Application code can then require a role at any point of its execution, thus providing a mechanism to restrict resource access very selectively (and therefore allow RESTful resource mapping). Interfaces
furius.ca/indra/doc/design.html 4/9
5/4/12
IAuthentication Dependencies Shared database storage (for users, groups and roles). Session management.
3.18 Rendering
Outputting HTML is best carried out by building a tree of nodes and then flattening the hierarchy into an HTML rendition. This has many advantages: the tree can be built in any order, and loops can be used to modify existing nodes. This is notoriously useful for building complex tables; the output is beautifully indented and can be made XHTML compliant more easily; some tricks can be used to embed stylesheet information in the tree elements, or to insert required javascript includes for
furius.ca/indra/doc/design.html 5/9
5/4/12
elements that require it; it allows the building of a template class (a Python class) that represents specific page layouts, with appropriate methods to add user-defined elements. For example, a page layout (class MainPages) that has a sidebar could have a method called a d s d t p t x ) that would add the necessary wrapping code for inserting a tip, maybe with a img reference d_iei(et and appropriate CSS classes and ids. This amounts to adding a higher level of abstraction over the stylesheet mechanism to provide more abstract, complex and dynamic page templates. This library provides an easy syntax for representing these trees of nodes in the source code. It should also provide some way to iterate the elements and attributes in order to rewrite URLs in various ways (this may be necessary for RESTfulness). Also, the rendering of forms or of form data into read-only tables can be achieved by providing "form renderers", which use the form definitions to produce a HTML subtree to be inserted in the final HTML tree. We can also provide some code to assist in the creating of tasks that are often carried out, like setting current tabs depending on which resource is chosen, i.e. mapping pages to current tabs. Interfaces A library providing HTML classes for building the HTML tree. IFormRenderer. Dependencies (None)
5/4/12
4 Useful Extensions
This section describes other useful modular codes.
5/4/12
4.6 Events
A notification interface for the application to call back on the children when specific events occur could be useful. e.g. application-start, session-start, session-end, etc. Interfaces ? Dependencies (None)
5 Innovative Ideas
This document presents some ideas that are not often discussed in web application frameworks. They are not that original, but strangely enough, most frameworks do not provide the following: a version of gettext that doesn't take into account newlines for strings; decoupling the form definition and rendering; templates using class code; automatically logging tracebacks of errors into a bug database; automatic reloading of modified source code; a fake-email for testing;
6 Conclusion
A set of specific interfaces are introduced that provide a standardized minimal environment to write web applications.
furius.ca/indra/doc/design.html
8/9
5/4/12
furius.ca/indra/doc/design.html
9/9