Approach to Developing a Redbourne Application

Site Map
 
Home
 
Application Guide
Reference
  Installation
  Configuration
  XML Markup
  JavaScript Classes
  ROM
  Templates
  Environment
  Dev Process
    Introduction
    SOR
    Static
    Dynamic
    Test
    Acceptance
    Deploy
  Tools
  External Links
  Example libraries
Community
Contact Whitebeam
To-Do
Download
Credits
Licence
Whitebeam Users
 
 
 

Approach to Developing a Redbourne Application

Developing a Redbourne Application

Review the application and allow the client to testFully exercise the site, testing full operationDesign and implement the dynamic behaviour of the siteDesign the site layout and overall look and feelAgree the clients expectations and requirements.Make the web application live on the Internet.The Process

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:

wherewhy
Client Side CookieLimited data - can be deleted.
Redbourne SessionSpace not a problem - data lost at end of session
Contact TemplateIf people have to register with your application then you can store information - such as preferences - against that users record in the Contact Template. This option provides the most reliable solution.

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

Whitebeam release 1.3.36
(loadtime : 14ms)