New Project Paradigm

Workbench (Diver Solution and Diver Platform 7.x) introduces the concept of discrete projects. Projects in Workbench are a collection of related files within a single directory tree that are associated with a Diver Solution or Diver Platform implementation. Prior to Workbench, informal projects were used to organize the parts of the application into a folder structure. Only developers were conscious of this structure. In Workbench, a project is specifically defined and the software acts upon this definition.

The following are the main Workbench project features:

• Abstraction—what is the project for?
• Simplified file organization for required files
• Easily transportable—all pieces encapsulated
• Self-contained access control files
• Local user projects (for working offline) and support for retro projects (for 6.x projects not yet converted to 7.x)

With the release of 7.0(28.2), a new home project feature allows you to automate the creation of end-user home directories within the home project (see Home Project Overview).

Project Files

When you define a new project, a recommended structure is presented to organize the parts, but there is flexibility. You can choose to start with an empty structure or use the default structure and delete or rename folders to suit the needs of your project and reduce visual clutter.

A project directory typically has folders for:

• Raw data or source files
• Temporary data in the process of being manipulated
• Finalized data files
• Document libraries
• Image libraries
• Scripts, often organized by type such as build, divetab, or prd

The following is a typical project directory structure.

See Default Folder Structure for more information about the expected usage of the default directories.

See File Extensions for descriptions of new file types, their extensions, and the equivalents from earlier versions of the Diver Solution software tools.

Security

Access control is part of the project. Projects have self-contained access control rules that are organized by users, groups, or user properties. Access control options allow you to specify rules for accessing files and directories, rules for viewing data records in cBases, Models, DiveTab areas (buttons) and pages, as well as whole-project access. See Access Control Overview.

Project Paths

Files within a project are referred to by their project path. The project root is a forward slash ("/"), and then all other files are stored under that. So if you have a folder called cbases within your project, and a sales.cbase file within it, the path to the file is:

/cbases/sales.cbase

Project paths make projects completely portable. A project can be stored in one place on one machine and in a completely different place on another. All references to project files within scripts are easily resolved regardless of the project placement on the server. Because of this, and in order to keep scripts, markers, and dives as clear as possible, the use of relative paths to reach parent or sibling directories (../data/foo.txt) is discouraged. See Project Paths for more information.

Aliases

You can create aliases to bring in data from outside the project. The aliases can be to folders in another project on the DiveLine or to a system drive. Alias functions are like a UNIX link. See Aliases Tab for information on how to set up aliases in Workbench.

Mailing Lists

Workbench maintains mailing lists on the project level to keep projects portable. You can create mailing lists that are used to send notifications for the success or failure of whole Production scripts or specific nodes as they are processed. See Mailing Lists Tab for information on setting up mailing lists.