Specify Application Context

Specify Software Project Staff
29 Nov. 2012
Version 1.0

The Application Context (AC) refers to all of the application 'state' that is required for the application to run. When a user logs in they must choose the Collection they wish to work within. Since there is a lot of overhead associated with setting up the state per Collection and Discipline, when the user selects a Collection the Thick Client (TC) begins to construct the state into memory. Nearly every facet of Specify is configurable. Most all of the configuration is defined in XML files that ship with Specify. These 'static' XML files represent a default implementation (or instance) of the application for a giving Discipline and User Type. Specify can then be customized by changing the XML files and importing them into the View or Resource system. When the AC loads the Views or Resources it checks the database first and then defaults to the installation files.

There are four different User Types:

  1. Manager
  2. Full Access
  3. Limited Access
  4. Guest

In the User Type list the Manager has the most privileges and the Guest the least.

There are six different levels at which Specify can be configured:

  1. User
  2. User Type
  3. Collection
  4. Discipline
  5. Common
  6. Back Stop (Global)

The list above represents a hierarchy where the items higher in the list override the items lower in the list. For example, in the diagram below there are several forms shown and some of them have been customized at various levels. The black dotted lines show the search for the form with the arrow pointing to the form at the level that will be used. The Collecting Event form has be customized for the 'Manager' User Type and then also for the Collection the user is currently logged into. If a Manager user is logged in and wishes to display a Collecting Event form, then a customized form for a User Type will override a form customized for the Discipline. When Specify is installed there are no View or Resources at the User or Collection levels because those do not exist until a database is created. There is a default set of forms for all four User Types and for each Discipline. NOTE: Every level can be customized with the exception of the Back Stop level.

 

Diagram


As mentioned earlier, most parts of the application is configurable. Here is a list of some of the other resources that are defined in XML and can be customized:

  1. Statistics
  2. Express Searches
    1. Search against a table
    2. Related Search
  3. Privileges
  4. Labels
  5. Reports
  6. PickLists
  7. Preparation Types
  8. Query Configurators
  9. Tree Definitions
    1. Taxon
    2. Storage
    3. Geography
  10. Defaults Tasks
  11. Initial Field Visibility
  12. Field Formatter
  13. Data Object Formatters

Localization

Localization and the database schema are tighly coupled. There are two separate parts of Specify that needs to be localized:

  1. The names of the fields in the database i.e. their titles.
  2. The strings in the application itself, like the 'OK' button or a column header in a grid.

The localized strings in the application does not relate to the App Context so it will not be discussed here. Specify's schema was designed to include fields for all disciplines and each discipline uses a subset of the fields in the database. Some fields need to be required for some disciplines and not others. Setting a field to be required by the database schema means all disciplines would be required to fill it in. Specify solves the localization and field requirement issues by layering a logical schema on top of the physical database schema.

By customimizing the logical schema, it enables each discipline to pick and choose which fields (or even tables for that matter), that will be visible to the Specify configuration tools. It also enables the field to be set to 'required,' as well as, formatters, Pick Lists, etc. The Schema ConfigTtool also enables the fields to have localized discipline specific titles. The titles for the database Tables and Fields are located in a single place and can then be obtained by the form system, search results system , or anywhere else in the application they are needed. The 'Catalog Number' field title can be changed to 'Specimen Number' once and the change is then reflected everywhere in the app. Each field also has customizable/localizable 'usage notes.' Usage Notes are displayed when the user double clicks on a field's label in a form. This text instructs the user how the field should be used.

All of the logical schema information and customization is also loaded on a per discipline basis when the Applicxation Context is constructed.

 

Schema Config Tool for customizing tables and fields in the logical schema.

Summary

Specify is highly configurable through using the XML, the User Types, the Resource levels, and the Schema Localizer. It provides nearly an infinited number of ways for each Discipline or Collection to be used per user.