Developing a Redbourne Application

Dynamic or Active Design

The basic application look and feel has now been determined, as have the pages that need to be produced. Now it is necessary top translate the design and the demonstration pages into a real web application. The following things should be considered when developing the application:

Common Look and Feel

The static design agreed a basic look and feel for the site, and probably agreed a single style to be applied to most, if not all pages within the site. When considering the site implementation investigate whether some or all of this look and feel can be encapsulated in a single file - to be included at the top of each page in the application. This has the following advantages:

• The look and feel can be forced onto all pages - no opportunities for it to evolve so some of the later pages look subtly different from the earlier ones. If the look and feel evolves then the changes apply to all pages - no need to revisit all pages at the end.
• Corporate images change. Companies change there logos, their names. If that information can be encapsulated in one place then the a new look can be rolled out over an entire site very quickly.
• If menus and other top level elements are defined in one place testing is much easier - test the look and feel on a single page and be pretty sure it'll work everywhere!

The Redbourne system incorporates some very powerful mechanisms (using include files and XML processing) that make it very easy to produce a "wrapping" for main page content. The page that you are currently looking at is designed as an HTML document with no left hand or top border, just a plain page the only addition being a single <rb:include src="/defaultstyle.inc" /> tag at the top. The borders and menus were generated by the Redbourne system based on the content of the defaultstyle.inc file when you requested the page. See the sample applications section where the source code is available and its operation is is explained in detail.

Feature Mapping/Design

Decide how the features required by the application are going to be mapped to the services offered by the Redbourne system. Obviously you will have some idea of this in-order to agree the specification of the application. This is now the addition of detail - and may require you to revisit the static as well.

Data Storage/Session Data

Most web applications need to store some context sensitive information. Part of the dynamic design is to decide where and how that information will be stored. Some of the options are:

For a discussion of these options see the 'Tracking User Sessions' technical note.