Difference between revisions of "Key Administration Concepts"

From ARK
Jump to: navigation, search
(Settings Files)
 
(19 intermediate revisions by 6 users not shown)
Line 1: Line 1:
for a more generalised overview of ARK, check out the [[about http://ark.lparchaeology.com/about]] section of the website. This is a review fo concepts that are key for administreing an ARK instance effectively.
+
For a more generalised overview of ARK, check out the [http://ark.lparchaeology.com/about about] section of the website. This is a review of concepts that are key for administering an ARK instance effectively.
  
==Items and Fragments Overview==
+
===Settings Files===
  
A more detailed explanation fo items anf fragments can be found in the [[about http://ark.lparchaeology.com/about]] section of the website. Items are effectively key records. These are the records that the end users will recognise as a 'record'. Items are effectively just an index system, the data which makes up the record is contained in fragments that are attached to the items in many ways. Fragments are therefore in effect the atomic particles of ARK, they are the smallest unit of data that the system can handle. Fields are a way of describing each fragment within ARK. This differs slightly from the normal database use of the term. In ARK the field is more like a unit of settings which describe the data that may be contained within the field. These data are fragments.
+
ARK is setup by means of plain text files. In order to configure ARK you need to edit these files using a text editor. The files are described briefly below. More detailed developer level documentation is available describing every directive found in the files. For most administrators a brief overview should be sufficient.
  
==Validation Rules==
+
====[[env_settings.php]]====
 +
 
 +
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.
 +
 
 +
====[[settings.php]]====
 +
 
 +
This is the main ARK settings file and contains default settings relating to the entire instance of ARK.
 +
 
 +
====[[page_settings.php]]====
 +
 
 +
This contains settings related to page navigation, display, toolbars, and left panel set ups.
 +
 
 +
====[[vd_settings.php]]====
 +
 
 +
This contains the validation rules. (See below).
 +
 
 +
====[[field_settings.php]]====
 +
 
 +
This contains the settings directives for fields. (See below).
 +
 
 +
====[[mod_settings.php]]====
 +
 
 +
These files contain settings for each installed module. Each module will require different settings depending on the data structure. (See below)
 +
 
 +
===Forms Overview===
 +
 
 +
A more detailed explanation of items and fragments can be found in the [http://ark.lparchaeology.com/about about] section of the website. Items are effectively key records. These are the records that the end users will recognise as a 'record'. Items are effectively just an index system, the data that make up the record is contained in fragments that are attached to the items in many ways. Fragments are therefore, in effect, the atomic particles of ARK, they are the smallest unit of data that the system can handle. Fields are a way of describing each fragment within ARK. This differs slightly from the normal database use of the term. In ARK the field is more like a unit of settings which describe the data that may be contained within the field. These data are fragments.
 +
 
 +
====Validation Rules====
  
 
Validation rules are the things which make up one of the main components of a field. These could be described as the sub-atomic particles of an ARK fragment, although in fact, they refer to the field not the fragments.
 
Validation rules are the things which make up one of the main components of a field. These could be described as the sub-atomic particles of an ARK fragment, although in fact, they refer to the field not the fragments.
  
Validation rules for ARK's forms are contained in the vd_settings.php file. This helps to keep them together. In short validation rules serve two purposes:
+
Validation rules for ARK's forms are contained in the vd_settings.php file. This helps to keep them together. In short, validation rules serve two purposes:
  
 
#They tell a given element of a field how to request itself from the system when it is involved in any kind of form edit routine.
 
#They tell a given element of a field how to request itself from the system when it is involved in any kind of form edit routine.
 
#They tell the update script how to validate that particular element of a fragment.
 
#They tell the update script how to validate that particular element of a fragment.
  
Unfortunately these are teh hardest of the three main elements of forms to understand and yet they are the most essential. ARK comes with preconfigured validation rules for all the dataclasses and you should be able to make use of these rules in most cases.
+
Unfortunately these are the hardest of the three main elements of forms to understand and yet they are the most essential. ARK comes with preconfigured validation rules for all the dataclasses and you should be able to make use of these rules in most cases.
  
 
The main exception to this rule is in the case of a custom validation for particular fields as used within a module and especially when we want to force a var to a certain manual value. This can be accomplished by using in-line syntax as documented within the mod_settings files.
 
The main exception to this rule is in the case of a custom validation for particular fields as used within a module and especially when we want to force a var to a certain manual value. This can be accomplished by using in-line syntax as documented within the mod_settings files.
  
==Fields==
+
====Fields====
  
 
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.
 
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.
  
==Subforms==
+
====Subforms====
  
Subforms are made up of settings directives which describe units within forms that are visible to end users. Typically they contain a list of fields to display. The fields already know how to display and validate themselves when used within a form, so the subform is relatively easy to set up.
+
[[Subforms]] are made up of settings directives which describe units within forms that are visible to end users. Typically they contain a list of fields to display. The fields already know how to display and validate themselves when used within a form, so the subform is relatively easy to set up.
  
 
[[category: Administrator]]
 
[[category: Administrator]]

Latest revision as of 12:15, 25 February 2011

For a more generalised overview of ARK, check out the about section of the website. This is a review of concepts that are key for administering an ARK instance effectively.

Settings Files

ARK is setup by means of plain text files. In order to configure ARK you need to edit these files using a text editor. The files are described briefly below. More detailed developer level documentation is available describing every directive found in the files. For most administrators a brief overview should be sufficient.

env_settings.php

This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.

settings.php

This is the main ARK settings file and contains default settings relating to the entire instance of ARK.

page_settings.php

This contains settings related to page navigation, display, toolbars, and left panel set ups.

vd_settings.php

This contains the validation rules. (See below).

field_settings.php

This contains the settings directives for fields. (See below).

mod_settings.php

These files contain settings for each installed module. Each module will require different settings depending on the data structure. (See below)

Forms Overview

A more detailed explanation of items and fragments can be found in the about section of the website. Items are effectively key records. These are the records that the end users will recognise as a 'record'. Items are effectively just an index system, the data that make up the record is contained in fragments that are attached to the items in many ways. Fragments are therefore, in effect, the atomic particles of ARK, they are the smallest unit of data that the system can handle. Fields are a way of describing each fragment within ARK. This differs slightly from the normal database use of the term. In ARK the field is more like a unit of settings which describe the data that may be contained within the field. These data are fragments.

Validation Rules

Validation rules are the things which make up one of the main components of a field. These could be described as the sub-atomic particles of an ARK fragment, although in fact, they refer to the field not the fragments.

Validation rules for ARK's forms are contained in the vd_settings.php file. This helps to keep them together. In short, validation rules serve two purposes:

  1. They tell a given element of a field how to request itself from the system when it is involved in any kind of form edit routine.
  2. They tell the update script how to validate that particular element of a fragment.

Unfortunately these are the hardest of the three main elements of forms to understand and yet they are the most essential. ARK comes with preconfigured validation rules for all the dataclasses and you should be able to make use of these rules in most cases.

The main exception to this rule is in the case of a custom validation for particular fields as used within a module and especially when we want to force a var to a certain manual value. This can be accomplished by using in-line syntax as documented within the mod_settings files.

Fields

Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.

Subforms

Subforms are made up of settings directives which describe units within forms that are visible to end users. Typically they contain a list of fields to display. The fields already know how to display and validate themselves when used within a form, so the subform is relatively easy to set up.