Aliases

Each record in the system has a unique numerical identifier. These identifiers are used internally to refer to records in record-related actions, such as view, update, or delete actions. Since the system is a web-based application, each action is accessed through a URL and record identifiers are part of these URLs. A typical system URL is in the form of record type/record action/record id, e.g. plant/view/224. Al-though some system URLs are only used internally, some others, especially URLs of record view pages, are used to refer to the records externally, for example for giving links to the records. Since numerical identifiers are not easy to remember and do not give any insight in the contents of the record, the sys-tem supports the use of alpha-numeric aliases instead of numerical record identifiers. This leads to more meaningful, user- and search engine-friendly URLs, e.g. plant/view/exxonmobil_antwerp instead of plant/view/224. Alias records are used to store such aliases.

The data fields of the alias records are listed in Table 1.

Table 1. Alias data fields

Each alias record has a record code denoting the type of the record and a record ID, which should be unique. Multiple alias records are not allowed for the same record. Both record code and record ID are read-only and cannot be changed once the alias record is created. However, one could delete the alias record and create a new one with new record code and ID. The alias that should be used to identify the record instead of the numerical identifier should be specified. Only the alias in the base (system) language is mandatory. Aliases in other languages may be left blank. Similar to record identifiers, aliases (including multilingual ones) should be unique among the records of the same record type. If available, the system uses the alias in the active (user interface) language to generate URLs, so that all URL components are concordant to each other. For example, the URL plant/view/tupras_refinery in English becomes tesis/goster/tupras_rafinerisi in Turkish. If the alias in the active language is not available, the one in the base language is used as the default alias. If the multilingual aliases of a record are deemed to be in final form, the alias record can be locked to prevent the automatic alias updating described below. Alias records can be listed by record type, record ID, alias (in multiple languages), and locked status (Figure 1).

In order to facilitate aliasing of records, the system provides two mechanisms. The first one is automated aliasing of records once they are created. A user-defined combination of record data fields, which is designated by the "alias" attribute of the data definition section of the record form, is used to generate such aliases. Aliases are generated for all supported languages by using the data field values in different languages wherever possible. If a generated alias exists in the database, a sequential numerical prefix is appended to the alias to obtain a unique alias. Unless the alias record is locked, aliases are automatically updated if the record is modified. For example, if the name field is designated as the auto-mated alias field for a record type and the user modifies the name of a record, then the alias is also automatically modified in line with the name change. The automated aliasing mechanism provides an efficient way to create aliases without any user intervention.

The second mechanism provided by the system is the alias entry form, which is displayed at each record view page for the records defined as alias-able (Figure 2). By using the form, existing aliases can be easily modified, deleted, or locked by the administrators. Once the aliases are modified on the form, the Ok button should be clicked to save the data. The form communicates with the server asynchronously; therefore, no form submission is required. Similar to other record types, alias records can also be up-dated or deleted by using alias-specific record update and delete pages.