All redbourne applications are documented and structured in a consistent manner. Each example is typically in two parts, the application itself and the administration of the application (always found under the "admin" subdirectory). The documentation for each example can always be found as the file examplex.html in the root of the zipped application archive and is the file that is displayed from the index page. The documentation follows this format:
The first link at the top of the page runs the example application on the Redbourne system. Other links connect to sections of the documentation.
Contains an overview of the functionality of the example application.
The typical applications of the example.
The limitations consider such things as security restrictions, possible enhancements and other functionality constraints.
A key way of gaining a feel for the operation of an application is from the structure diagram for the application. The symbolic diagram represents each page of the application and the way events cause the application to flow between each page. If you are familiar with programming techniques you might have come across the concept of "state machines". The symbolic diagram really represents the application as a state machine. Each "state" is represented by a circle identifying the web page displayed. Each event is represented by a line joining one state/page to another; the lable attached to the line showing what event causes the transition from one state/page to the other.
Two thinknesses of line represent the type of transition:
Symbol | Description |
|---|---|
 | A thin line represents a client driven transition from one page to another such as an ordinary hyperlink (<A> tag) or form input (<FORM> tag). |
 | A thick line represents a server driven transition from one page to another such as a redirect (<rb:redirect> tag or ROM equivalent) or error handling. Server included files (<rb:include> tag or ROM equivalent) are also represented by a think line. |
The following four symbols are placed at the end the above lines to indicate the destination window for the page transition:
Symbol | Description |
|---|---|
 | Inline, the target window is the same as the previous window. |
 | New window, the target window is a new window. |
| The target is the parent window of the current window. | |
 | No window, the "destination" page is some sort of include. |
The following three symbols represent individual pages of collections of pages:
Symbol | Description |
|---|---|
 | A dynamically generated "rhtm" page. |
 | A static, conventional page not produced by the Redbourne Presentation Engine. |
 | A task or activity comprising a number of separate, linked pages. This symbol is used to overlay a hierarchy on complex applications so that the overall structure can still be seen. |
This is simply a table identifying each numbered page from the symbolic diagram with a filename including a brief description of the functionality contained within the page.
The download icon at the top of the section gets all of the source code as a zipped archive including folder structure. Individual files can be viewed by selecting the appropriate link from the table, this opens the source in the browser window. The source file can then be downloaded by selecting the download icon to the right of the title bar. The source code is documented predominately at the start of each major function within the file.
An important concept in nearly all Redbourne applications is the way that an input made from a form is processed. In general the Redbourne script that process a form is in the same pattern page as generated the form. This makes it much easier to structure a program and format or process a form. Control is passed to other pages as necessary by using "redirect" tags or ROM calls. In this way a completely structured application can be generated with code held in self-contained page modules.
(Compare this with a methodology that placed the form processing in a different page to the form and consider the example where a form could do two different things. To achieve this the original page would need two forms on it each submitting to different destination pages. The two separate destination pages would have to perform common functions, yet be in different files. It is much harder to get your head around a structure that has the source (form) page doing half the work and the destination page doing the other half of the work!)
This section contains any detailed information pertinant to the application. However in most cases the source code of the application is self-documenting and contains all necessary details.