https://ark.lparchaeology.com/wiki/api.php?action=feedcontributions&user=Sofia&feedformat=atomARK - User contributions [en]2024-03-29T12:35:07ZUser contributionsMediaWiki 1.27.1https://ark.lparchaeology.com/wiki/index.php?title=Exporting_Data&diff=942Exporting Data2009-06-05T08:51:05Z<p>Sofia: </p>
<hr />
<div>In order to allow your users to use the export functionality of ARK you need to set a few settings in the mod_settings files. An example is [http://ark.lparchaeology.com/wiki/index.php/Mod_settings.php#Export here].<br />
<br />
You will also need to set up a couple of settings in settings.php, namely:<br />
<br />
// EXPORTS<br />
//export file location (where ARK exports will be saved - needs to be an absolute path)<br />
$export_dir = "C:/ms4w/Apache/htdocs/$ark_dir/tmp"; absolute path on server to save the export file(s)<br />
$web_export_dir = "$ark_dir/tmp/"; RELATIVE path where the export files(s) are saved.<br />
<br />
<br />
If you want to add new export types - then you will need to write handlers for both the export itself (a function called exportCSV() and then a function that handles the elements named elemCSV()). It may be better to get a Developer to do this.<br />
[[category: Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=User_Administration&diff=846User Administration2009-06-05T08:45:02Z<p>Sofia: /* Adding Users */</p>
<hr />
<div>__TOC__<br />
<br />
===Adding Users===<br />
<br />
In order for team members to become visible within Ark, a user account must first be created. From the 'Users' [[Basic Navigation|navigation tab]], select 'Add User' from the left panel. The system will ask for a number of bits of information. When these have all been entered, select 'Create User' to create and enable the user account.<br />
<br />
<br />
All users are assigned a '''username''' according to their surname (family name) and their <br />
initials in the form ''''dufton_ad''''. In cases where multiple team members share the same <br />
initials an alternative set of initials will be used to avoid duplicates within the system.<br />
<br />
===Editing Users===<br />
User information can be altered by using the 'Edit User' command. Basic information like firstname and lastname is changed by altering the text field. To change the password, a new password must be entered and confirmed. The username is created automatically through a combination of lastname and initials. This cannot be changed after the user has been initially added.<br />
<br />
Beyond this basic information, users can also be assigned groups from the 'Edit User' menu. Users within the 'Admin' group will have greater privileges within Ark such as creating or activating user accounts, checking context records, and the like. Currently all users will be assigned to the 'User' group as the 'Admin' group has yet to be given special privileges. This will be updated at a later date to allow for specific project administrators.<br />
<br />
Finally, accounts can be enabled/disabled from the 'Edit User' menu. Enabled accounts have full access to the Ark system. Disabled accounts will not be able to log in or enter data. It is important to understand that users created in the 'Add User' option will not automatically be activated, and will not be able to access the system until their user account has been enabled.<br />
<br />
<br />
[[category: Usermanual]][[Category: Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Subform_Reference&diff=755Subform Reference2009-06-05T08:41:13Z<p>Sofia: /* Complex Subforms */</p>
<hr />
<div>The following is a list of all current ARK subforms. Each subform page includes detailed configuration information and an example subform setup.<br />
<br />
'''NB - AS OF ARK 0.7 THE CONFIGURATION OF SUBFORMS USING MODTYPES WILL CHANGE TO RELY SOLELY ON THE [[Conditional Subforms]] OPTION.'''<br />
<br />
===Text Subforms===<br />
*'''[[sf_txt]]''' - subform to enter text data<br />
<br />
===Number Subforms===<br />
*'''[[sf_number]]''' - subform to add number data<br />
<br />
===Attribute Subforms===<br />
*'''[[sf_finds]]''' - subform to attach attributes of a given type (findtypes) and to set a boolean for each one<br />
*'''[[sf_attr_bytype]]''' - subform to attach attributes of a given type<br />
*'''[[sf_attr_boolean]]''' - subform to set boolean attribute<br />
<br />
===Spatial Subforms===<br />
*'''[[sf_spat]]''' - a subform to display spatial data about an item ''THIS SUBFORM IS DEPRECATED AND SHOULD NOT BE USED FOR ANY NEW ARK SYSTEMS''<br />
*'''[[sf_wfs_spat]]''' - the new subform to display spatial data about an item<br />
<br />
===Span Subforms===<br />
*'''[[sf_span_rel]]''' - subform to enter span relationships not in matrix form<br />
*'''[[sf_spanmatrix]]''' - subform to enter span relationships in matrix form<br />
<br />
===File Subforms===<br />
*'''[[sf_file]]''' - subform to handle files<br />
<br />
===XMI Subforms===<br />
*'''[[sf_xmi]]''' - subform to enter XMI links between records<br />
<br />
===Complex Subforms===<br />
Complex subforms combine different data classes.<br />
<br />
*'''[[sf_modtype]]''' - subform to handle modules with different item types<br />
*'''[[sf_interp]]''' - subform to handle interpretative text fragments with actor/date pairings<br />
*'''[[sf_assemblage]]''' - a subform to handle bulk assemblages<br />
*'''[[sf_event]]''' - subform to handle actor/date pairs<br />
*'''[[sf_frame]]''' - subform to display many subforms within a single subform<br />
<br />
===Other Subforms===<br />
Other subforms are forms that don't really fit anywhere else.<br />
<br />
*'''[[sf_flickr]]''' - subform to dynamically pull photos from a flickr stream<br />
*'''[[sf_websites]]''' - subform to generate a list of websites that can take dynamic variables (for instance a link to youTube searching all of the videos according to a value held in ARK)<br />
<br />
<br />
[[category:administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Mod_settings.php&diff=941Mod settings.php2009-06-05T08:19:13Z<p>Sofia: /* Micro View */</p>
<hr />
<div>__TOC__<br />
<br />
These files contain settings for each installed module. Each module will require different settings depending on the data structure. For this documentation a standard single-context recording 'mod_cxt_settings.php' file will be discussed as an example.<br />
<br />
===Display Options===<br />
<br />
The display options influence how specific types of context record are displayed in navigation forms. Context data often requires brackets denoting the type of context. The code for configuring display looks like this:<br />
<pre><br />
$conf_br = array('type_2_L' => '(', 'type_2_R' => ')','type_1_L' => '[', 'type_1_R' => <br />
']','type_6_L' => '*', 'type_6_R' => '*', 'type_4_L' => '', 'type_4_R' => '');<br />
</pre><br />
In the above, 'type_#' refers to the type number in cxt_lut_cxttype. The L or R refers to the whether the symbol will be displayed to the left or right of the context number. The symbol itself appears after => between ' '. Please note that in some cases (as in type 6 in the above example) a symbol can be placed only to one side of the item number.<br />
<br />
===Custom Fields===<br />
<br />
Although most fields will be setup in [[field_settings.php]], some fields are classified as 'custom' and are set-up in each modules settings file. <br />
<br />
The three most common custom fields are as follows:<br />
*'''conf_field_itemkey''' - This value is always setup within the module settings<br />
*'''conf_field_modtype''' - This may be setup if there are any modtypes for the module<br />
*'''conf_field_modxmi''' - Custom fields for xmi are also often needed, and should be included in the module settings file.<br />
<br />
Please see below for an example of the custom field 'conf_field_itemkey' for the module Contexts:<br />
<br />
<pre><br />
<br />
$conf_field_itemkey =<br />
array(<br />
'dataclass' => 'itemkey',<br />
'classtype' => 'cxt_cd', //this is needed to correctly request the qtype<br />
'alias_tbl' => 'cor_tbl_module',<br />
'alias_col' => 'itemkey',<br />
'alias_src_key' => 'cxt_cd',<br />
'alias_type' => '1',<br />
'module' => 'cxt',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $key_add_validation,<br />
'edt_validation' => $key_edt_validation<br />
);<br />
</pre><br />
<br />
====Custom Validation====<br />
<br />
Some custom fields will also require module specific custom validation rules. These must also be configured in the module settings. Custom validation rules can be inserted into the validation arrays for each field using the following:<br />
<pre><br />
$field['add_validation'][] = $your_custom_rule;<br />
</pre><br />
<br />
All custom validation must be set BEFORE adding a field using custom validation to any subform. In the example of mod_cxt_settings, custom validation for the item_key is setup with other custom fields and looks like this:<br />
<pre><br />
$conf_field_itemkey['add_validation'][] = $key_vd_modtype;<br />
$conf_field_itemkey['edt_validation'][] = $key_vd_modtype;<br />
</pre><br />
<br />
===Subforms===<br />
The configuration of subforms is an essential step to setting up the module settings. Given the complexity of the task, please see the dedicated [[Administrator Manual#Subforms|Subforms]] chapter.<br />
<br />
===Spatial Data===<br />
<br />
To display spatial data, a spatial viewer subform will be required. The configuration of this subform is discussed in detail in [[Subforms]]. There are also other spatial settings that need to be set within the module settings, as follows:<br />
<br />
*'''$refmap_show''' - decide if you want to show a reference map when the spatial subform is in primary column, options TRUE, FALSE<br />
*'''$view_map_default''' - decide if you want maps to display on default, options TRUE, FALSE<br />
*'''$refmap_type''' - sets the parameters from the reference map, options SCALE (to zoom to set scale) or SHAPE (to zoom to outline of a specific shape)<br />
*'''$refmap_scale''' - set as NULL if zooming to SHAPE, else set as integer for desired scale (ie. $refmap_scale = 500 will zoom to scale 1:500)<br />
*'''$refmap_width''' - OPTIONAL, a value for specifying a non-default width for reference map. If not specified, the value is taken directly from the $map object.<br />
*'''$refmap_height''' - OPTIONAL, a value for specifying a non-default height for reference map. If not specified, the value is taken directly from the $map object.<br />
*'''$refmap_layer''' - OPTIONAL, if zoomtype SHAPE is stated this value is the name of the layer to zoom to, if not set as NULL<br />
*'''$refmap_field''' - OPTIONAL, if zoomtype SHAPE is stated this value is the name of attribute field of the shape to zoom to, if not set as NULL<br />
*'''$refmap_fieldvalue''' - OPTIONAL, if zoomtype SHAPE is stated this value is the specific value in the attribute field of the shape to zoom to, if not set as NULL<br />
<br />
===Data Entry Forms===<br />
<br />
Data Entry Forms are forms used for entering new items to the module or adding further details on items already issued in the module. The data entry form needs a different package for each of its different views. Each package is essentially a series of subforms contained within a single column. Data Entry views are as follows:<br />
*'''Registers''' - for issuing new items to the module<br />
*'''Detform''' - for detailed record entry to pre-existing items<br />
*'''Optional''' - additional views specific to an ARK project. <br />
<br />
====Register====<br />
<br />
The register form is used for issuing new items to the module. In most cases the register is used as a standalone form, although sometimes a register is embedded within other module pages. The basic steps to setting up the Register form are as follows:<br />
<br />
# Set up any validation rules needed in the vd_settings file. In most cases this should already be completed. Any module specific validation should be set up in the module settings file, as discussed [[mod_settings.php#Custom Validation|above]].<br />
# Set up any fields needed within the form. Most fields are entered in the [[field_settings.php]] file. Module specific fields have already been created for this module in the [[mod_settings.php#Custom Fields|Custom Fields]] section above.<br />
# Set up the register subform using the standard [[Subforms]] format.<br />
# Set up the register column<br />
<br />
The register column requires a set of specific column variables. From our example of mod_cxt_settings, the register column is configured using the following code:<br />
<pre><br />
$conf_dat_regist =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'register_col',<br />
'subforms' => array(<br />
$conf_register<br />
)<br />
);<br />
</pre><br />
<br />
The variables needed for the register column are:<br />
*'''col_id''' - in the case of a data entry register, there is only one column so this should always be set as 'main_column'<br />
*'''col_alias''' - variable stating whether or not the column has an alias, set as TRUE or FALSE<br />
*'''col_type''' - the type of column, for registers this should always be set as 'register_col'<br />
*'''subforms''' - the [[Subforms|subforms]] to add to the register column, in this case only the $conf_register<br />
<br />
====Detfrm====<br />
<br />
The detform is a form used for rapid data entry of a single record. The detfrm is a series of subforms contained within a single column. Unlike the [[mod_settings.php#Register|register]], the detfrm does not generally need an additional specific subform. Instead the [[Subforms]] created already within the module settings are inserted directly into the detfrm column. Set up the detfrm in the following steps:<br />
<br />
# Set up any validation rules needed in the vd_settings file. In most cases this should already be completed. Any module specific validation should be set up in the module settings file, as discussed [[mod_settings.php#Custom Validation|above]].<br />
# Set up any fields needed within the form. Most fields are entered in the [[field_settings.php]] file. Module specific fields have already been created for this module in the [[mod_settings.php#Custom Fields|Custom Fields]] section above.<br />
# Set up the detfrm column<br />
<br />
The detfrm column requires the same variables as the register column discussed [[mod_settings.php#Register|above]]. From our mod_cxt_settings.php example, the column for the detfrm looks like this:<br />
<pre><br />
$conf_dat_detfrm =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'collaps_col',<br />
'subforms' => array(<br />
$conf_mcd_short_desc,<br />
$conf_mcd_description,<br />
$conf_mcd_matrix,<br />
$conf_mcd_span_rels,<br />
$conf_mcd_interp,<br />
$conf_mcd_event<br />
)<br />
);<br />
</pre><br />
<br />
Differences between the register and detfrm columns are needed for the following variables:<br />
*'''col_type''' - states the column type, for detfrm use either 'single_col' (a simple single column) or collaps_col (for collapsing columns, useful with more complex data entry sheets)<br />
*'''subforms''' - unlike the register, in the detfrm we have not created a specific detfrm subform, instead include the subforms specific to the module settings as configured [[mod_settings.php#Subforms|above]].<br />
<br />
====Optional Views====<br />
<br />
Like the register and detfrm, optional views are displayed in a single column for rapid data entry. Different optional views are defined by the ARK administrator. Additional custom validation is usually required for optional views. Like the detfrm, the steps required to set up an optional view are:<br />
# Set up any validation rules needed in the vd_settings file. In most cases this should already be completed. Any module specific validation should be set up in the module settings file, as discussed [[mod_settings.php#Custom Validation|above]].<br />
# Set up any fields needed within the form. Most fields are entered in the [[field_settings.php]] file. Module specific fields have already been created for this module in the [[mod_settings.php#Custom Fields|Custom Fields]] section above.<br />
# Set up the optional view column<br />
<br />
The column fields for the optional view will be the same as the [[mod_settings.php#Register|register]] and [[mod_settings.php#Detfrm|detfrm]]. There are no optional views for the example mod_cxt_settings, but here is an example taken from mod_smp_settings.php<br />
<pre><br />
$conf_dat_materi =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'collaps_col',<br />
'subforms' => array(<br />
$conf_mcd_botanictypes,<br />
$conf_mcd_botanic,<br />
<br />
<br />
)<br />
);<br />
</pre><br />
<br />
===Micro View===<br />
<br />
The micro view page is used to display a single record. This page makes use of the [[mod_settings.php#Subforms|subforms]] set up above and assembles them into columns according to the settings within this section. These columns are then joined/packaged together into a single package for convenience. As the micro view is used for displaying the data in the most suitable format, it is important to note that the organisation of this form does NOT in any way need to follow that of the [[mod_settings.php#Detfrm|detfrm]] used for data entry.<br />
<br />
To configure the micro view:<br />
# Create the micro view columns<br />
# Package the columns into an array<br />
# Set the display options<br />
<br />
====Micro View Columns====<br />
In our example from mod_cxt_settings, we are using 2 columns for the micro view. They are configured like this:<br />
<pre><br />
$conf_mcd_col_1 =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'primary_col',<br />
'subforms' => array(<br />
$conf_mcd_interp,<br />
$conf_mcd_short_desc,<br />
$conf_mcd_matrix,<br />
$conf_mcd_description,<br />
$conf_mcd_event<br />
)<br />
);<br />
<br />
$conf_mcd_col_2 =<br />
array(<br />
'col_id' => 'second_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'secondary_col',<br />
'subforms' => array(<br />
$conf_mcd_spat, <br />
$conf_mcd_sphxmi,<br />
$conf_mcd_span_rels,<br />
$conf_mcd_smpxmi,<br />
$conf_mcd_spfxmi<br />
)<br />
);<br />
</pre><br />
<br />
The subforms contained in each column have already been defined [[mod_settings.php#Subforms|above]]. Variables needed for the micro view columns are:<br />
*'''col_id''' - where is the column to be displayed (main_column, second_column, third_column, etc)<br />
*'''col_alias''' - does column have an alias (FALSE/TRUE)<br />
*'''col_type''' - the type of column (primary_col, secondary_col)<br />
*'''subforms''' - subforms to add to each column<br />
<br />
====Column Package====<br />
<br />
The above columns are now grouped into a single column package. In our mod_cxt_settings.php this looks like this:<br />
<pre><br />
$cxt_conf_mcd_cols =<br />
array(<br />
'op_display_type' => 'cols',<br />
'op_top_col' => 'main_column',<br />
'columns' =><br />
array(<br />
$conf_mcd_col_1,<br />
$conf_mcd_col_2<br />
) <br />
);<br />
</pre><br />
<br />
The variables used in the columns package are:<br />
*'''op_display_type''' - how are the columns displayed, set as cols (columns) or tabs (tabs)<br />
*'''op_top_col''' - sets which column is the first (main_column)<br />
*'''columns''' - an array with all columns in the order they are to appear<br />
<br />
===Data View===<br />
<br />
The data view page is used to display many records from different modules, often simultaneously. Within each module settings file it is mandatory to set what information is <br />
displayed in the data view. <br />
<br />
The data view displays search results as table, chat, or map. The configuration for each view is discussed below.<br />
<br />
====Table====<br />
<br />
The data is expressed as a series of xhtml tables. Each module needs configuration of the columns for display and the column headers for each field. The table configuration is basically a simple subform package and follows all the rules of [[Subforms]].<br />
<br />
In our mod_cxt_settings.php example, the data view configuration for the table looks like this:<br />
<pre><br />
$conf_mac_table =<br />
array(<br />
'fields' =><br />
array(<br />
$conf_field_itemkey,<br />
$conf_field_cxttype,<br />
$conf_field_short_desc,<br />
$conf_field_issuedto,<br />
$conf_field_issuedon,<br />
$conf_reg_op_no_qed<br />
)<br />
);<br />
</pre><br />
<br />
In this case we only need to specify a single variable:<br />
*'''fields'' - an array of fields to be displayed in the table<br />
<br />
====Chat====<br />
<br />
The view as chat option is dictated by the results array, and will automatically return any fields which satisfy the search query. No additional configuration is required.<br />
<br />
====Map====<br />
<br />
The view as map option is configured within the [[Settings.php]] file and not in the module specific settings.<br />
<br />
===XMI View===<br />
<br />
Any module item will likely be viewed in a reduced form from within another module. Therefore it is necessary to configure the XMI view settings in each mod_settings file. The XMI view describes how a specific module represents itself when called into an XMI view by another module.<br />
<br />
In our example of mod_cxt_settings.php, the XMI configuration looks like this:<br />
<pre><br />
$cxt_xmiconf =<br />
array(<br />
'op_xmi_hdrbar' => 'link', // we put optional stuff in here <br />
'op_xmi_label' => TRUE, // we put optional stuff in here <br />
'fields' => <br />
array(<br />
$conf_field_short_desc,<br />
$conf_field_issuedto,<br />
$conf_field_issuedon,<br />
)<br />
);<br />
</pre><br />
<br />
The variables we are using for the XMI settings are:<br />
*'''op_xmi_hdrbar''' - how to display the header of each XMI record, options 'link' (as a link), 'name' (display the name only) <br />
*'''op_xmi_label''' - set whether the record type will be displayed, set as TRUE/FALSE<br />
*'''fields''' - which fields, as set up [[mod_settings.php#Custom Fields|above]] or in [[field_settings.php]] should be displayed with each record in XMI view<br />
<br />
===Export===<br />
<br />
The export configuration sets up the export page. The export can be done in different formats, as listed here with variables. Each export method needs to be listed within the main array. '''Please note that the export functionality is not fully developed for ARK v0.6'''. Check also [[Exporting Data]] for further information on how to configure data exports, specifically other settings you will need in the settings.php file.<br />
<br />
In the example mod_cxt_settings.php the export configuration is:<br />
<pre><br />
$cxt_export_conf = <br />
array(<br />
'CSV' =><br />
array(<br />
'op_field_delimiter' => ',',<br />
'op_text_delimiter' => ' ',<br />
'op_gis' => TRUE,<br />
'export_fields' =><br />
array(<br />
$conf_field_issuedon,<br />
$conf_field_definition,<br />
<br />
)<br />
),<br />
'XMLItemList' =><br />
array('empty'<br />
),<br />
'XMLItem' =><br />
array('empty'<br />
)<br />
<br />
);<br />
</pre><br />
<br />
In this example the CSV (Comma Separated Values) and XML exports are configured. The following variables are needed:<br />
*'''empty''' - empty must be used if there are no other variables (as in XMLItemList above)<br />
*'''op_field_delimiter''' - delimiter between fields (use a comma for CSV exports)<br />
*'''op_text_delimiter''' - delimiter between text (use a space for CSV exports)<br />
*'''op_gis''' - if this is set then the headers will be made lowercase and the spaces in them will be underscores (mainly so ArcGIS can read it). If you DON'T want this then take the op out completely.<br />
*'''fields''' - the fields to be exported, as configured [[mod_settings.php#Custom Fields|above]] or in [[field_settings.php]]<br />
<br />
[[Category:administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Mod_settings.php&diff=744Mod settings.php2009-06-05T08:14:22Z<p>Sofia: /* Spatial Data */</p>
<hr />
<div>__TOC__<br />
<br />
These files contain settings for each installed module. Each module will require different settings depending on the data structure. For this documentation a standard single-context recording 'mod_cxt_settings.php' file will be discussed as an example.<br />
<br />
===Display Options===<br />
<br />
The display options influence how specific types of context record are displayed in navigation forms. Context data often requires brackets denoting the type of context. The code for configuring display looks like this:<br />
<pre><br />
$conf_br = array('type_2_L' => '(', 'type_2_R' => ')','type_1_L' => '[', 'type_1_R' => <br />
']','type_6_L' => '*', 'type_6_R' => '*', 'type_4_L' => '', 'type_4_R' => '');<br />
</pre><br />
In the above, 'type_#' refers to the type number in cxt_lut_cxttype. The L or R refers to the whether the symbol will be displayed to the left or right of the context number. The symbol itself appears after => between ' '. Please note that in some cases (as in type 6 in the above example) a symbol can be placed only to one side of the item number.<br />
<br />
===Custom Fields===<br />
<br />
Although most fields will be setup in [[field_settings.php]], some fields are classified as 'custom' and are set-up in each modules settings file. <br />
<br />
The three most common custom fields are as follows:<br />
*'''conf_field_itemkey''' - This value is always setup within the module settings<br />
*'''conf_field_modtype''' - This may be setup if there are any modtypes for the module<br />
*'''conf_field_modxmi''' - Custom fields for xmi are also often needed, and should be included in the module settings file.<br />
<br />
Please see below for an example of the custom field 'conf_field_itemkey' for the module Contexts:<br />
<br />
<pre><br />
<br />
$conf_field_itemkey =<br />
array(<br />
'dataclass' => 'itemkey',<br />
'classtype' => 'cxt_cd', //this is needed to correctly request the qtype<br />
'alias_tbl' => 'cor_tbl_module',<br />
'alias_col' => 'itemkey',<br />
'alias_src_key' => 'cxt_cd',<br />
'alias_type' => '1',<br />
'module' => 'cxt',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $key_add_validation,<br />
'edt_validation' => $key_edt_validation<br />
);<br />
</pre><br />
<br />
====Custom Validation====<br />
<br />
Some custom fields will also require module specific custom validation rules. These must also be configured in the module settings. Custom validation rules can be inserted into the validation arrays for each field using the following:<br />
<pre><br />
$field['add_validation'][] = $your_custom_rule;<br />
</pre><br />
<br />
All custom validation must be set BEFORE adding a field using custom validation to any subform. In the example of mod_cxt_settings, custom validation for the item_key is setup with other custom fields and looks like this:<br />
<pre><br />
$conf_field_itemkey['add_validation'][] = $key_vd_modtype;<br />
$conf_field_itemkey['edt_validation'][] = $key_vd_modtype;<br />
</pre><br />
<br />
===Subforms===<br />
The configuration of subforms is an essential step to setting up the module settings. Given the complexity of the task, please see the dedicated [[Administrator Manual#Subforms|Subforms]] chapter.<br />
<br />
===Spatial Data===<br />
<br />
To display spatial data, a spatial viewer subform will be required. The configuration of this subform is discussed in detail in [[Subforms]]. There are also other spatial settings that need to be set within the module settings, as follows:<br />
<br />
*'''$refmap_show''' - decide if you want to show a reference map when the spatial subform is in primary column, options TRUE, FALSE<br />
*'''$view_map_default''' - decide if you want maps to display on default, options TRUE, FALSE<br />
*'''$refmap_type''' - sets the parameters from the reference map, options SCALE (to zoom to set scale) or SHAPE (to zoom to outline of a specific shape)<br />
*'''$refmap_scale''' - set as NULL if zooming to SHAPE, else set as integer for desired scale (ie. $refmap_scale = 500 will zoom to scale 1:500)<br />
*'''$refmap_width''' - OPTIONAL, a value for specifying a non-default width for reference map. If not specified, the value is taken directly from the $map object.<br />
*'''$refmap_height''' - OPTIONAL, a value for specifying a non-default height for reference map. If not specified, the value is taken directly from the $map object.<br />
*'''$refmap_layer''' - OPTIONAL, if zoomtype SHAPE is stated this value is the name of the layer to zoom to, if not set as NULL<br />
*'''$refmap_field''' - OPTIONAL, if zoomtype SHAPE is stated this value is the name of attribute field of the shape to zoom to, if not set as NULL<br />
*'''$refmap_fieldvalue''' - OPTIONAL, if zoomtype SHAPE is stated this value is the specific value in the attribute field of the shape to zoom to, if not set as NULL<br />
<br />
===Data Entry Forms===<br />
<br />
Data Entry Forms are forms used for entering new items to the module or adding further details on items already issued in the module. The data entry form needs a different package for each of its different views. Each package is essentially a series of subforms contained within a single column. Data Entry views are as follows:<br />
*'''Registers''' - for issuing new items to the module<br />
*'''Detform''' - for detailed record entry to pre-existing items<br />
*'''Optional''' - additional views specific to an ARK project. <br />
<br />
====Register====<br />
<br />
The register form is used for issuing new items to the module. In most cases the register is used as a standalone form, although sometimes a register is embedded within other module pages. The basic steps to setting up the Register form are as follows:<br />
<br />
# Set up any validation rules needed in the vd_settings file. In most cases this should already be completed. Any module specific validation should be set up in the module settings file, as discussed [[mod_settings.php#Custom Validation|above]].<br />
# Set up any fields needed within the form. Most fields are entered in the [[field_settings.php]] file. Module specific fields have already been created for this module in the [[mod_settings.php#Custom Fields|Custom Fields]] section above.<br />
# Set up the register subform using the standard [[Subforms]] format.<br />
# Set up the register column<br />
<br />
The register column requires a set of specific column variables. From our example of mod_cxt_settings, the register column is configured using the following code:<br />
<pre><br />
$conf_dat_regist =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'register_col',<br />
'subforms' => array(<br />
$conf_register<br />
)<br />
);<br />
</pre><br />
<br />
The variables needed for the register column are:<br />
*'''col_id''' - in the case of a data entry register, there is only one column so this should always be set as 'main_column'<br />
*'''col_alias''' - variable stating whether or not the column has an alias, set as TRUE or FALSE<br />
*'''col_type''' - the type of column, for registers this should always be set as 'register_col'<br />
*'''subforms''' - the [[Subforms|subforms]] to add to the register column, in this case only the $conf_register<br />
<br />
====Detfrm====<br />
<br />
The detform is a form used for rapid data entry of a single record. The detfrm is a series of subforms contained within a single column. Unlike the [[mod_settings.php#Register|register]], the detfrm does not generally need an additional specific subform. Instead the [[Subforms]] created already within the module settings are inserted directly into the detfrm column. Set up the detfrm in the following steps:<br />
<br />
# Set up any validation rules needed in the vd_settings file. In most cases this should already be completed. Any module specific validation should be set up in the module settings file, as discussed [[mod_settings.php#Custom Validation|above]].<br />
# Set up any fields needed within the form. Most fields are entered in the [[field_settings.php]] file. Module specific fields have already been created for this module in the [[mod_settings.php#Custom Fields|Custom Fields]] section above.<br />
# Set up the detfrm column<br />
<br />
The detfrm column requires the same variables as the register column discussed [[mod_settings.php#Register|above]]. From our mod_cxt_settings.php example, the column for the detfrm looks like this:<br />
<pre><br />
$conf_dat_detfrm =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'collaps_col',<br />
'subforms' => array(<br />
$conf_mcd_short_desc,<br />
$conf_mcd_description,<br />
$conf_mcd_matrix,<br />
$conf_mcd_span_rels,<br />
$conf_mcd_interp,<br />
$conf_mcd_event<br />
)<br />
);<br />
</pre><br />
<br />
Differences between the register and detfrm columns are needed for the following variables:<br />
*'''col_type''' - states the column type, for detfrm use either 'single_col' (a simple single column) or collaps_col (for collapsing columns, useful with more complex data entry sheets)<br />
*'''subforms''' - unlike the register, in the detfrm we have not created a specific detfrm subform, instead include the subforms specific to the module settings as configured [[mod_settings.php#Subforms|above]].<br />
<br />
====Optional Views====<br />
<br />
Like the register and detfrm, optional views are displayed in a single column for rapid data entry. Different optional views are defined by the ARK administrator. Additional custom validation is usually required for optional views. Like the detfrm, the steps required to set up an optional view are:<br />
# Set up any validation rules needed in the vd_settings file. In most cases this should already be completed. Any module specific validation should be set up in the module settings file, as discussed [[mod_settings.php#Custom Validation|above]].<br />
# Set up any fields needed within the form. Most fields are entered in the [[field_settings.php]] file. Module specific fields have already been created for this module in the [[mod_settings.php#Custom Fields|Custom Fields]] section above.<br />
# Set up the optional view column<br />
<br />
The column fields for the optional view will be the same as the [[mod_settings.php#Register|register]] and [[mod_settings.php#Detfrm|detfrm]]. There are no optional views for the example mod_cxt_settings, but here is an example taken from mod_smp_settings.php<br />
<pre><br />
$conf_dat_materi =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'collaps_col',<br />
'subforms' => array(<br />
$conf_mcd_botanictypes,<br />
$conf_mcd_botanic,<br />
<br />
<br />
)<br />
);<br />
</pre><br />
<br />
===Micro View===<br />
<br />
The micro view page is used to display a single record. This page makes use of the [[mod_settings.php#Subforms|subforms]] set up above and assembles them into columns according to the settings within this section. These columns are then joined packaged together into a single package for convenience. As the micro view is used for displaying the data in the most suitable format, it is important to note that the organisation of this form does NOT in any way need to follow that of the [[mod_settings.php#Detfrm|detfrm]] used for data entry.<br />
<br />
To configure the micro view:<br />
# Create the micro view columns<br />
# Package the columns into an array<br />
# Set the display options<br />
<br />
====Micro View Columns====<br />
In our example from mod_cxt_settings, we are using 2 columns for the micro view. They are configured like this:<br />
<pre><br />
$conf_mcd_col_1 =<br />
array(<br />
'col_id' => 'main_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'primary_col',<br />
'subforms' => array(<br />
$conf_mcd_interp,<br />
$conf_mcd_short_desc,<br />
$conf_mcd_matrix,<br />
$conf_mcd_description,<br />
$conf_mcd_event<br />
)<br />
);<br />
<br />
$conf_mcd_col_2 =<br />
array(<br />
'col_id' => 'second_column',<br />
'col_alias' => FALSE,<br />
'col_type' => 'secondary_col',<br />
'subforms' => array(<br />
$conf_mcd_spat, <br />
$conf_mcd_sphxmi,<br />
$conf_mcd_span_rels,<br />
$conf_mcd_smpxmi,<br />
$conf_mcd_spfxmi<br />
)<br />
);<br />
</pre><br />
<br />
The subforms contained in each column have already been defined [[mod_settings.php#Subforms|above]]. Variables needed for the micro view columns are:<br />
*'''col_id''' - where is the column to be displayed (main_column, second_column, third_column, etc)<br />
*'''col_alias''' - does column have an alias (FALSE/TRUE)<br />
*'''col_type''' - the type of column (primary_col, secondary_col)<br />
*'''subforms''' - subforms to add to each column<br />
<br />
====Column Package====<br />
<br />
The above columns are now grouped into a single column package. In our mod_cxt_settings.php this looks like this:<br />
<pre><br />
$cxt_conf_mcd_cols =<br />
array(<br />
'op_display_type' => 'cols',<br />
'op_top_col' => 'main_column',<br />
'columns' =><br />
array(<br />
$conf_mcd_col_1,<br />
$conf_mcd_col_2<br />
) <br />
);<br />
</pre><br />
<br />
The variables used in the columns package are:<br />
*'''op_display_type''' - how are the columns displayed, set as cols (columns) or tabs (tabs)<br />
*'''op_top_col''' - sets which column is the first (main_column)<br />
*'''columns''' - an array with all columns in the order they are to appear<br />
<br />
===Data View===<br />
<br />
The data view page is used to display many records from different modules, often simultaneously. Within each module settings file it is mandatory to set what information is <br />
displayed in the data view. <br />
<br />
The data view displays search results as table, chat, or map. The configuration for each view is discussed below.<br />
<br />
====Table====<br />
<br />
The data is expressed as a series of xhtml tables. Each module needs configuration of the columns for display and the column headers for each field. The table configuration is basically a simple subform package and follows all the rules of [[Subforms]].<br />
<br />
In our mod_cxt_settings.php example, the data view configuration for the table looks like this:<br />
<pre><br />
$conf_mac_table =<br />
array(<br />
'fields' =><br />
array(<br />
$conf_field_itemkey,<br />
$conf_field_cxttype,<br />
$conf_field_short_desc,<br />
$conf_field_issuedto,<br />
$conf_field_issuedon,<br />
$conf_reg_op_no_qed<br />
)<br />
);<br />
</pre><br />
<br />
In this case we only need to specify a single variable:<br />
*'''fields'' - an array of fields to be displayed in the table<br />
<br />
====Chat====<br />
<br />
The view as chat option is dictated by the results array, and will automatically return any fields which satisfy the search query. No additional configuration is required.<br />
<br />
====Map====<br />
<br />
The view as map option is configured within the [[Settings.php]] file and not in the module specific settings.<br />
<br />
===XMI View===<br />
<br />
Any module item will likely be viewed in a reduced form from within another module. Therefore it is necessary to configure the XMI view settings in each mod_settings file. The XMI view describes how a specific module represents itself when called into an XMI view by another module.<br />
<br />
In our example of mod_cxt_settings.php, the XMI configuration looks like this:<br />
<pre><br />
$cxt_xmiconf =<br />
array(<br />
'op_xmi_hdrbar' => 'link', // we put optional stuff in here <br />
'op_xmi_label' => TRUE, // we put optional stuff in here <br />
'fields' => <br />
array(<br />
$conf_field_short_desc,<br />
$conf_field_issuedto,<br />
$conf_field_issuedon,<br />
)<br />
);<br />
</pre><br />
<br />
The variables we are using for the XMI settings are:<br />
*'''op_xmi_hdrbar''' - how to display the header of each XMI record, options 'link' (as a link), 'name' (display the name only) <br />
*'''op_xmi_label''' - set whether the record type will be displayed, set as TRUE/FALSE<br />
*'''fields''' - which fields, as set up [[mod_settings.php#Custom Fields|above]] or in [[field_settings.php]] should be displayed with each record in XMI view<br />
<br />
===Export===<br />
<br />
The export configuration sets up the export page. The export can be done in different formats, as listed here with variables. Each export method needs to be listed within the main array. '''Please note that the export functionality is not fully developed for ARK v0.6'''. Check also [[Exporting Data]] for further information on how to configure data exports, specifically other settings you will need in the settings.php file.<br />
<br />
In the example mod_cxt_settings.php the export configuration is:<br />
<pre><br />
$cxt_export_conf = <br />
array(<br />
'CSV' =><br />
array(<br />
'op_field_delimiter' => ',',<br />
'op_text_delimiter' => ' ',<br />
'op_gis' => TRUE,<br />
'export_fields' =><br />
array(<br />
$conf_field_issuedon,<br />
$conf_field_definition,<br />
<br />
)<br />
),<br />
'XMLItemList' =><br />
array('empty'<br />
),<br />
'XMLItem' =><br />
array('empty'<br />
)<br />
<br />
);<br />
</pre><br />
<br />
In this example the CSV (Comma Separated Values) and XML exports are configured. The following variables are needed:<br />
*'''empty''' - empty must be used if there are no other variables (as in XMLItemList above)<br />
*'''op_field_delimiter''' - delimiter between fields (use a comma for CSV exports)<br />
*'''op_text_delimiter''' - delimiter between text (use a space for CSV exports)<br />
*'''op_gis''' - if this is set then the headers will be made lowercase and the spaces in them will be underscores (mainly so ArcGIS can read it). If you DON'T want this then take the op out completely.<br />
*'''fields''' - the fields to be exported, as configured [[mod_settings.php#Custom Fields|above]] or in [[field_settings.php]]<br />
<br />
[[Category:administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Key_Administration_Concepts&diff=1028Key Administration Concepts2009-06-05T08:11:36Z<p>Sofia: /* mod_settings.php */</p>
<hr />
<div>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.<br />
<br />
===Settings Files===<br />
<br />
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.<br />
<br />
====env_settings.php====<br />
<br />
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.<br />
<br />
====settings.php====<br />
<br />
This is the main ARK settings file and contains settings relating to the entire instance of ARK.<br />
<br />
====vd_settings.php====<br />
<br />
This contains the validation rules. (See below).<br />
<br />
====field_settings.php====<br />
<br />
This contains the settings directives for fields. (See below).<br />
<br />
====mod_settings.php====<br />
<br />
These files contain settings for each installed module. Each module will require different settings depending on the data structure. (See below)<br />
<br />
===Forms Overview===<br />
<br />
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.<br />
<br />
====Validation Rules====<br />
<br />
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.<br />
<br />
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:<br />
<br />
#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.<br />
#They tell the update script how to validate that particular element of a fragment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
====Fields====<br />
<br />
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.<br />
<br />
====Subforms====<br />
<br />
[[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.<br />
<br />
[[category: Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Key_Administration_Concepts&diff=742Key Administration Concepts2009-06-05T08:11:05Z<p>Sofia: /* mod_settings.php */</p>
<hr />
<div>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.<br />
<br />
===Settings Files===<br />
<br />
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.<br />
<br />
====env_settings.php====<br />
<br />
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.<br />
<br />
====settings.php====<br />
<br />
This is the main ARK settings file and contains settings relating to the entire instance of ARK.<br />
<br />
====vd_settings.php====<br />
<br />
This contains the validation rules. (See below).<br />
<br />
====field_settings.php====<br />
<br />
This contains the settings directives for fields. (See below).<br />
<br />
====mod_settings.php====<br />
<br />
These files contain settings for each installed module. Each module will require different settings depending on the data structure.<br />
<br />
===Forms Overview===<br />
<br />
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.<br />
<br />
====Validation Rules====<br />
<br />
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.<br />
<br />
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:<br />
<br />
#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.<br />
#They tell the update script how to validate that particular element of a fragment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
====Fields====<br />
<br />
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.<br />
<br />
====Subforms====<br />
<br />
[[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.<br />
<br />
[[category: Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Field_settings.php&diff=1080Field settings.php2009-06-05T08:08:42Z<p>Sofia: /* Other Obligatory Settings */</p>
<hr />
<div>This is the documentation for the field settings file. It contains a technical description of the elements that must be and may optionally be present in fields.<br />
<br />
===Common/Obligatory Attributes===<br />
<br />
====Basics====<br />
<br />
The two top settings are essential for the good working of the field:<br />
<br />
*'''dataclass''' = This tells the system what [[Data Class]] the field is.<br />
*'''classtype''' = This tells the system what [[Classtype]] the field is.<br />
<br />
There is not currently an ARK function to create new classtypes. In order to add a new classtype, please access the database using PHPMyAdmin and add the classtype directly in the cor_lut_classtype table (eg. cor_lut_actiontype, cor_lut_datetype, etc...).<br />
<br />
====Alias Settings====<br />
<br />
The alias for the field requires the following 3 attributes:<br />
<br />
*'''alias_tbl''' = the table for the getAlias call<br />
*'''alias_col''' = the col for the getAlias call<br />
*'''alias_src_key''' = the alias_src_key for the getAlias call<br />
*'''alias_type''' = the alias_type for the getAlias call<br />
<br />
It is important to add all alias values to cor_tbl_alias when configuring fields. This can be completed using the [[Alias Administration]] tools.<br />
<br />
====Other Obligatory Settings====<br />
<br />
*'''editable''' = set TRUE to process this field in forms set FALSE for display only<br />
*'''hidden''' = set TRUE to make the field <input type="hidden" /><br />
*'''add_validation''' = validation rules for this field when on an add routine<br />
*'''edt_validation''' = validation rules for this field when on an edt routine<br />
<br />
====Examples====<br />
<br />
An example of a standard text field:<br />
<pre>$conf_field_desc =<br />
array(<br />
'dataclass' => 'txt',<br />
'classtype' => 'desc',<br />
'alias_tbl' => 'cor_lut_txttype',<br />
'alias_col' => 'txttype',<br />
'alias_src_key' => 'desc',<br />
'alias_type' => '1',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $txt_add_validation,<br />
'edt_validation' => $txt_edt_validation<br />
);<br />
</pre><br />
<br />
An example of a standard attribute field:<br />
<pre><br />
$conf_field_samplecondition =<br />
array(<br />
'dataclass' => 'attr',<br />
'classtype' => 'samplecondition',<br />
'alias_tbl' => 'cor_lut_attributetype',<br />
'alias_col' => 'attributetype',<br />
'alias_src_key' => 'sampleconditions',<br />
'alias_type' => '1',<br />
//'alias_classtype' => 'Condition',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $attr_add_validation,<br />
'edt_validation' => $attr_edt_validation<br />
);<br />
</pre><br />
<br />
An example of a standard number field:<br />
<pre><br />
$conf_field_total =<br />
array(<br />
'dataclass' => 'number',<br />
'classtype' => 'total',<br />
'alias_tbl' => 'cor_lut_numbertype',<br />
'alias_col' => 'numbertype',<br />
'alias_src_key' => 'total',<br />
'alias_type' => '1',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $number_add_validation,<br />
'edt_validation' => $number_edt_validation<br />
);<br />
</pre><br />
<br />
An example of a standard date field:<br />
<pre><br />
$conf_field_issuedon =<br />
array(<br />
'dataclass' => 'date',<br />
'datestyle' => 'dd,mm,yr',<br />
'classtype' => 'issuedon',<br />
'alias_tbl' => 'cor_lut_datetype',<br />
'alias_col' => 'datetype',<br />
'alias_src_key' => 'issuedon',<br />
'alias_type' => '1',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $date_add_validation,<br />
'edt_validation' => $date_edt_validation<br />
);<br />
</pre><br />
<br />
An example of a standard span field:<br />
<pre><br />
$conf_field_sameas =<br />
array(<br />
'dataclass' => 'span',<br />
'classtype' => 'sameas',<br />
'alias_tbl' => 'cor_lut_spantype',<br />
'alias_col' => 'spantype',<br />
'alias_src_key' => 'sameas',<br />
'alias_type' => '1',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $span_add_validation,<br />
'edt_validation' => $span_edt_validation<br />
);<br />
</pre><br />
<br />
An example of a standard xmi field:<br />
<pre><br />
$conf_field_romxmi = <br />
array(<br />
'dataclass' => 'xmi',<br />
'classtype' => 'xmi_list',<br />
'alias_tbl' => 'cor_tbl_module',<br />
'alias_col' => 'itemkey',<br />
'alias_src_key' => 'rom_cd',<br />
'alias_type' => '1',<br />
'module' => 'mus',<br />
'xmi_mod' => 'rom', <br />
'op_xmi_itemkey' => 'rom_cd',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $xmi_add_validation,<br />
'edt_validation' => $xmi_edt_validation<br />
);<br />
</pre><br />
<br />
And finally, an example of a standard file field:<br />
<pre><br />
$conf_field_file =<br />
array(<br />
'dataclass' => 'file',<br />
'classtype' => 'file',<br />
'alias_tbl' => 'cor_tbl_col',<br />
'alias_col' => 'id',<br />
'alias_src_key' => '6',<br />
'alias_type' => '1',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $file_add_validation,<br />
'edt_validation' => $file_edt_validation<br />
);<br />
</pre><br />
<br />
===Class specific settings===<br />
<br />
Each class has some specific settings some of which may be optional or required.<br />
<br />
====Class: action====<br />
<br />
An example of an action class field.<br />
<br />
<pre>$conf_field_issuedto = <br />
array(<br />
'dataclass' => 'action',<br />
'classtype' => 'issuedto',<br />
'alias_tbl' => 'cor_lut_actiontype',<br />
'alias_col' => 'actiontype',<br />
'alias_src_key' => 'issuedto',<br />
'actors_mod' => 'abk',<br />
'actors_type' => 'people',<br />
'actors_element' => 'name',<br />
'actors_style' => 'single',<br />
'actors_elementclass' => 'txt',<br />
'actors_grp' => FALSE,<br />
'alias_type' => '1',<br />
'editable' => TRUE,<br />
'hidden' => FALSE,<br />
'add_validation' => $action_add_validation,<br />
'edt_validation' => $action_edt_validation<br />
);<br />
</pre><br />
<br />
*'''actors_mod''' = The module holding the actors (normally abk)<br />
*'''actors_type''' = The mod type as listed in mod_lut_modtype<br />
*'''actors_element''' = The text type to display within the dropdown<br />
*'''actors_style''' = whether actor information is displayed in a list style ('list') or as a single actor/date pairing ('single')<br />
*'''actors_elementclass''' = Class of data to be displayed for a given actor (ie. txt, number, etc)<br />
*'''actors_grp''' = Group functionality will allow the selection of a group of actors (in development)<br />
<br />
===Event Fields===<br />
<br />
Event fields are effectively wrappers for action/date fields. All fields<br />
must be set up above. One can also use actions and dates without having the event wrapper, but this allows one to group multiple events into a single subform.<br />
<br />
See below for an example of a configured event field:<br />
<br />
<pre><br />
$conf_event_compiled = <br />
array(<br />
'type' => 'compiled',<br />
'date' => $conf_field_compiledon,<br />
'action' => $conf_field_compiledby<br />
);<br />
</pre><br />
<br />
[[Category: Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=1030Initial setup2009-06-05T08:06:01Z<p>Sofia: /* Simple one data class subforms */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
===A Name===<br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
===What do you want to record?===<br />
<br />
ARK is designed to be a flexible system, therefore you can pretty much record/store any type of information. However, whilst not essential, it does help to have some idea at the start of the project as to what you want to record. Most archaeological projects will already have paper recording sheets and some idea of how they record in the field. It may be that you already have a computerised database structure that you want to recreate within an ARK instance. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|Fields]]. An excavation recording system for instance could perhaps have a number of different modules including the Context module and perhaps a Site Photo module, each of which will have a number of fields ('''SEE AMAZING IMAGE TO EXPLAIN THIS'''). A Sites and Monuments Record type application on the other hand may have a Monument module with a number of different fields (such as monument_type, etc.). <br />
<br />
[[Category: Administrator]]<br />
It may help to sketch out on a piece of paper the initial structure you want and then you can start building it up as you go along. One of the strengths of ARK is that it can be adapted to suit your recording practices, so if you don't know exactly what you want to record at the beginning of the project - you can just add more later. Below is an example of a sketch-up of the Sintana project containing two modules: the completely made up module of Sintana which contained a set of finds points and the Bibliography module. Both modules have a series of fields attached which can be [[Data Class|data classes]]<br />
<br />
===What subforms do you want?===<br />
<br />
ARK comes packaged with a number of different [[Subforms|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the different fields depending on which data class they use.<br />
<br />
====Simple one data class subforms====<br />
These subforms are very simple since they only require one type of field. The most used example is the text subform (sf_txt) which can display any number of text-type fields for each module. In addition the number subform (sf_number) will take one or more number fields and display, the links subform (sf_xmi) which records links between module items and the matrix subform (sf_spanmatrix) which can be used to record all types of spans as matrices. This last subform is often used for matrices describing context relationships with a span from one context to the next describing how the first context cuts the next. However, this matrix subform has been used with big success in other modules like the file module to describe the relationship between files where one file can be derived from an older file.<br />
<br />
====Combined data class subforms====<br />
Nevertheless, some subforms display a combination of fields with different data-types. One such is the interpretation subform (sf_interp) which takes a text field, an action field and a date field. This displays one interpretation for a module item (e.g. a context or a special find) which is again [[Chains|chained]] to a date and an action.<br />
Another example of these combined data-type subforms is the events subform (sf_event) which can use a date field or an action field or both a date and action field to display an event which has happened on a specific date by a specific person.</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=739Initial setup2009-06-05T08:05:03Z<p>Sofia: /* What do you want to record? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
===A Name===<br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
===What do you want to record?===<br />
<br />
ARK is designed to be a flexible system, therefore you can pretty much record/store any type of information. However, whilst not essential, it does help to have some idea at the start of the project as to what you want to record. Most archaeological projects will already have paper recording sheets and some idea of how they record in the field. It may be that you already have a computerised database structure that you want to recreate within an ARK instance. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|Fields]]. An excavation recording system for instance could perhaps have a number of different modules including the Context module and perhaps a Site Photo module, each of which will have a number of fields ('''SEE AMAZING IMAGE TO EXPLAIN THIS'''). A Sites and Monuments Record type application on the other hand may have a Monument module with a number of different fields (such as monument_type, etc.). <br />
<br />
[[Category: Administrator]]<br />
It may help to sketch out on a piece of paper the initial structure you want and then you can start building it up as you go along. One of the strengths of ARK is that it can be adapted to suit your recording practices, so if you don't know exactly what you want to record at the beginning of the project - you can just add more later. Below is an example of a sketch-up of the Sintana project containing two modules: the completely made up module of Sintana which contained a set of finds points and the Bibliography module. Both modules have a series of fields attached which can be [[Data Class|data classes]]<br />
<br />
===What subforms do you want?===<br />
<br />
ARK comes packaged with a number of different [[Subforms|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the different fields depending on which data class they use.<br />
<br />
====Simple one data class subforms====<br />
These subforms are very simple since they only require one type of field. The most used example is the text subform (sf_txt) which can display any number of text-type fields for each module. In addition the number subform (sf_number) will take one or more number fields and display, the links subform (sf_xmi) which records links between module items and the matrix subform (sf_spanmatrix) which can be used to record all types of spans as matrices. This last subform is often used for matrices describing context relationships with a span from one context to the next describing how the first context cuts the next. However, this matrix subform has been used with big succes in other modules like the file module to describe the relationship between files where one file can be derived from an older file. <br />
<br />
====Combined data class subforms====<br />
Nevertheless, some subforms display a combination of fields with different data-types. One such is the interpretation subform (sf_interp) which takes a text field, an action field and a date field. This displays one interpretation for a module item (e.g. a context or a special find) which is again [[Chains|chained]] to a date and an action.<br />
Another example of these combined data-type subforms is the events subform (sf_event) which can use a date field or an action field or both a date and action field to display an event which has happened on a specific date by a specific person.</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Initial_setup&diff=738Initial setup2009-06-05T08:04:19Z<p>Sofia: /* What do you want to record? */</p>
<hr />
<div>Once you have all of the [[Installation#Dependencies|dependencies]] up and running, you need to begin to design how you want your instance of ARK to work.<br />
<br />
There are a number of things to think about before you begin editing the configuration files.<br />
<br />
===A Name===<br />
<br />
Every ark instance should have a name, typically this is something like 'Chersonesos ARK' or 'The LP Map Collection'.<br />
<br />
===What do you want to record?===<br />
<br />
ARK is designed to be a flexible system, therefore you can pretty much record/store any type of information. However, whilst not essential, it does help to have some idea at the start of the project as to what you want to record. Most archaeological projects will already have paper recording sheets and some idea of how they record in the field. It may be that you already have a computerised database structure that you want to recreate within an ARK instance. <br />
<br />
The best way to begin designing your ARK instance is to think in terms of [[Module|Modules]] and [[Field|Fields]]. An excavation recording system for instance could perhaps have a number of different modules including the Context module and perhaps a Site Photo module, each of which will have a number of fields ('''SEE AMAZING IMAGE TO EXPLAIN THIS'''). A Sites and Monuments Record type application on the other hand may have a Monument module with a number of different fields (such as monument_type, etc.). <br />
<br />
[[Category: Administrator]]<br />
It may help to sketch out on a piece of paper the initial structure you want and then you can start building it up as you go along. One of the strengths of ARK is that it can be adapted to suit your recording practices, so if you don't know exactly what you want to record at the beginning of the project - you can just add more later. Below is an example of a sketch-up of the Sintana project containing two modules: The completely made up module of Sintana which contained a set of finds points and the Bibliography module. Both modules have a series of fields attached which can be [[Data Class|data classes]]<br />
<br />
===What subforms do you want?===<br />
<br />
ARK comes packaged with a number of different [[Subforms|subforms]], each of which can be used to present different types of information. The subforms can be seen as packages which combine the different fields depending on which data class they use.<br />
<br />
====Simple one data class subforms====<br />
These subforms are very simple since they only require one type of field. The most used example is the text subform (sf_txt) which can display any number of text-type fields for each module. In addition the number subform (sf_number) will take one or more number fields and display, the links subform (sf_xmi) which records links between module items and the matrix subform (sf_spanmatrix) which can be used to record all types of spans as matrices. This last subform is often used for matrices describing context relationships with a span from one context to the next describing how the first context cuts the next. However, this matrix subform has been used with big succes in other modules like the file module to describe the relationship between files where one file can be derived from an older file. <br />
<br />
====Combined data class subforms====<br />
Nevertheless, some subforms display a combination of fields with different data-types. One such is the interpretation subform (sf_interp) which takes a text field, an action field and a date field. This displays one interpretation for a module item (e.g. a context or a special find) which is again [[Chains|chained]] to a date and an action.<br />
Another example of these combined data-type subforms is the events subform (sf_event) which can use a date field or an action field or both a date and action field to display an event which has happened on a specific date by a specific person.</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Basic_Installation&diff=749Basic Installation2009-06-05T08:03:14Z<p>Sofia: /* Browse to ARK directory */</p>
<hr />
<div>Preconfigured ARK setups are available from the ARK team. If you are unfamiliar with the setup and adminisration of webservers along with the security risks to your system and data this entails, please consider contacting us to aquire a fully running ARK. For those of you who have already got a server and want to go though the installation proceedure, we have provided the following notes:<br />
<br />
===Dependencies===<br />
<br />
ARK requires the following open source software packages to be installed on your server:<br />
<br />
#Apache 2<br />
#PHP 5<br />
#MySQL 5<br />
#PEAR Liveuser<br />
<br />
In order to benefit from the spatial integration offered by ARK, you will also need the following packages:<br />
<br />
#PHP Mapscript<br />
<br />
====Apache PHP MySQL====<br />
<br />
On most Linux distributions these packages will be installed by default. ARK is not particularly fussy about the version numbers of these packages and should run ok on PHP4 and MySQL4, although this may require some minor modifications. It is important to ensure that you have the gd and dbase php extensions enabled.<br />
<br />
You will need to make sure that you set the short_open_tag option to On in your [http://uk2.php.net/ini.core php.ini].<br />
<br />
For Mac OSX and Windows, these packages are available as binary distributions. ARK is known to run on [http://www.mamp.info/en/index.php MAMP], the binary distribution for Mac and [http://www.wampserver.com/en/ WAMP] or [http://www.maptools.org/ms4w/index.phtml MS4W], the binary distributions for Windows.<br />
<br />
The MS4W distribution also contains Mapserver and if this is installed only MySQL needs to be added.<br />
<br />
ARK runs on top of these packages and does not provide any set up of them or additional security to them. If you are using your server exposed to the internet, it is essential that you follow good standard security practice for the configuration of your packages. This setup is outside of the scope of this documentation and you are advised to undertake your research carefully.<br />
<br />
====PEAR LiveUser====<br />
<br />
The PEAR Liveuser is used to ensure effective security for the ARK system. ARK makes use of PEAR LiveUser, LiveUser_Admin, MDB2, and MDB2_driver_mysql, DB, and Event_Dispatcher. All of these packages will need to be installed in order for ARK user authentication to function.<br />
<br />
For details on how to install and configure live user, and the associated packages required, please see the [http://pear.php.net/package/LiveUser/ PEAR] website. '''PLEASE NOTE that ALL the PEAR SQL tables are already included with the basic ARK database, and do not need to be added to the database again during PEAR setup. ALSO the required PEAR depencies are included with the v0.6 files in the 'examples' directory.'''<br />
<br />
====MS4W====<br />
MS4W [http://www.maptools.org/ms4w/] is a no fuss installer for setting up MapServer on Microsoft Windows platforms. It includes a Apache HTTP version, PHP, Mapserver and loads of nice tools.<br />
<br />
MS4W is super simple to install on a server. Either download [http://www.maptools.org/ms4w/index.phtml?page=downloads.html] the base package which consists of a folder which unpacks to the C-drive of the server or try out the new installer. <br />
<br />
If you are using the base package you need to start the Apache server by running C:\ms4w\apache-install.bat. If the installation is succesful you should get the main page by pointing you browser to http://localhost/ or http://127.0.0.1/.<br />
<br />
If this does not work it is very likely that your port 80 is already in use. Go to C:\ms4w\Apache\conf\httpd.conf and on line 120 change LISTEN 80 to LISTEN 8080 or another port which is not in use.<br />
<br />
====Mapscript====<br />
<br />
Mapscript runs on all three major operating systems. The installation instructions vary depending on many factors. Detailed installation instructions are available on the [http://mapserver.gis.umn.edu/ Mapserver] website.<br />
<br />
===Installing ARK===<br />
<br />
Ark is installed by unpacking the source code into the document root of the webserver where you intend to host it. The second phase of installation is then the initial setup and creation of the empty database.<br />
<br />
====Download source====<br />
<br />
Download the latest source code from http://ark.lparchaeology.com/downloads and unpack it into the document root of your server. If you are unsure of the correct location of the document root, you could try reading the manual of your apache distribution.<br />
<br />
====Install a database====<br />
<br />
In order for ark to work, you need to install an ARK database on your MySQL server. Preconfigured sample databases are available for download from the download area of the ARK site. At present you must install the sql dump on the server manually using your tool of choice. We think that [http://www.phpmyadmin.net/home_page/index.php phpMyAdmin] is a good way to do this.<br />
<br />
#Download your chosen database dump file<br />
#Point your browser at the phpMyAdmin installation on your web-server<br />
#Make an empty database, by going to the Databases screen and filling in the Create new database box. Make the Collation utf8_unicode_ci and that should deal with most character sets.<br />
#Once the database is created, switch to it and choose Import<br />
#Using the Browse button, point it at the file that you have downloaded (it should be a tar.gz) - make the character set utf8<br />
#Click Go and wait a little while, and the database structure should be loaded up fine.<br />
#You will need to set up a user and give it at least SELECT, INSERT, UPDATE and DELETE privileges to the new db.<br />
<br />
===Update the DB Settings===<br />
<br />
You will now need to update the server-specific DB settings in [[settings.php#Server Specific Information|settings.php]]. '''THE DATABASE WILL NOT WORK UNTIL THESE SETTINGS HAVE BEEN UPDATED'''.<br />
<br />
===Browse to ARK directory===<br />
<br />
After browsing to the ARK directory you should now be able to see the login pages for the database. The tutorial database is created with the following two user accounts:<br />
<br />
<pre><br />
username: janedoe<br />
password: janedoe<br />
<br />
username: johnsmith<br />
password: johnsmith<br />
</pre><br />
<br />
If there are any problems, please check your [[settings.php]] and [[env_settings.php]] files to ensure you are using the correct settings.<br />
<br />
[[category:Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Basic_Installation&diff=736Basic Installation2009-06-05T08:02:33Z<p>Sofia: /* Install a database */</p>
<hr />
<div>Preconfigured ARK setups are available from the ARK team. If you are unfamiliar with the setup and adminisration of webservers along with the security risks to your system and data this entails, please consider contacting us to aquire a fully running ARK. For those of you who have already got a server and want to go though the installation proceedure, we have provided the following notes:<br />
<br />
===Dependencies===<br />
<br />
ARK requires the following open source software packages to be installed on your server:<br />
<br />
#Apache 2<br />
#PHP 5<br />
#MySQL 5<br />
#PEAR Liveuser<br />
<br />
In order to benefit from the spatial integration offered by ARK, you will also need the following packages:<br />
<br />
#PHP Mapscript<br />
<br />
====Apache PHP MySQL====<br />
<br />
On most Linux distributions these packages will be installed by default. ARK is not particularly fussy about the version numbers of these packages and should run ok on PHP4 and MySQL4, although this may require some minor modifications. It is important to ensure that you have the gd and dbase php extensions enabled.<br />
<br />
You will need to make sure that you set the short_open_tag option to On in your [http://uk2.php.net/ini.core php.ini].<br />
<br />
For Mac OSX and Windows, these packages are available as binary distributions. ARK is known to run on [http://www.mamp.info/en/index.php MAMP], the binary distribution for Mac and [http://www.wampserver.com/en/ WAMP] or [http://www.maptools.org/ms4w/index.phtml MS4W], the binary distributions for Windows.<br />
<br />
The MS4W distribution also contains Mapserver and if this is installed only MySQL needs to be added.<br />
<br />
ARK runs on top of these packages and does not provide any set up of them or additional security to them. If you are using your server exposed to the internet, it is essential that you follow good standard security practice for the configuration of your packages. This setup is outside of the scope of this documentation and you are advised to undertake your research carefully.<br />
<br />
====PEAR LiveUser====<br />
<br />
The PEAR Liveuser is used to ensure effective security for the ARK system. ARK makes use of PEAR LiveUser, LiveUser_Admin, MDB2, and MDB2_driver_mysql, DB, and Event_Dispatcher. All of these packages will need to be installed in order for ARK user authentication to function.<br />
<br />
For details on how to install and configure live user, and the associated packages required, please see the [http://pear.php.net/package/LiveUser/ PEAR] website. '''PLEASE NOTE that ALL the PEAR SQL tables are already included with the basic ARK database, and do not need to be added to the database again during PEAR setup. ALSO the required PEAR depencies are included with the v0.6 files in the 'examples' directory.'''<br />
<br />
====MS4W====<br />
MS4W [http://www.maptools.org/ms4w/] is a no fuss installer for setting up MapServer on Microsoft Windows platforms. It includes a Apache HTTP version, PHP, Mapserver and loads of nice tools.<br />
<br />
MS4W is super simple to install on a server. Either download [http://www.maptools.org/ms4w/index.phtml?page=downloads.html] the base package which consists of a folder which unpacks to the C-drive of the server or try out the new installer. <br />
<br />
If you are using the base package you need to start the Apache server by running C:\ms4w\apache-install.bat. If the installation is succesful you should get the main page by pointing you browser to http://localhost/ or http://127.0.0.1/.<br />
<br />
If this does not work it is very likely that your port 80 is already in use. Go to C:\ms4w\Apache\conf\httpd.conf and on line 120 change LISTEN 80 to LISTEN 8080 or another port which is not in use.<br />
<br />
====Mapscript====<br />
<br />
Mapscript runs on all three major operating systems. The installation instructions vary depending on many factors. Detailed installation instructions are available on the [http://mapserver.gis.umn.edu/ Mapserver] website.<br />
<br />
===Installing ARK===<br />
<br />
Ark is installed by unpacking the source code into the document root of the webserver where you intend to host it. The second phase of installation is then the initial setup and creation of the empty database.<br />
<br />
====Download source====<br />
<br />
Download the latest source code from http://ark.lparchaeology.com/downloads and unpack it into the document root of your server. If you are unsure of the correct location of the document root, you could try reading the manual of your apache distribution.<br />
<br />
====Install a database====<br />
<br />
In order for ark to work, you need to install an ARK database on your MySQL server. Preconfigured sample databases are available for download from the download area of the ARK site. At present you must install the sql dump on the server manually using your tool of choice. We think that [http://www.phpmyadmin.net/home_page/index.php phpMyAdmin] is a good way to do this.<br />
<br />
#Download your chosen database dump file<br />
#Point your browser at the phpMyAdmin installation on your web-server<br />
#Make an empty database, by going to the Databases screen and filling in the Create new database box. Make the Collation utf8_unicode_ci and that should deal with most character sets.<br />
#Once the database is created, switch to it and choose Import<br />
#Using the Browse button, point it at the file that you have downloaded (it should be a tar.gz) - make the character set utf8<br />
#Click Go and wait a little while, and the database structure should be loaded up fine.<br />
#You will need to set up a user and give it at least SELECT, INSERT, UPDATE and DELETE privileges to the new db.<br />
<br />
===Update the DB Settings===<br />
<br />
You will now need to update the server-specific DB settings in [[settings.php#Server Specific Information|settings.php]]. '''THE DATABASE WILL NOT WORK UNTIL THESE SETTINGS HAVE BEEN UPDATED'''.<br />
<br />
===Browse to ARK directory===<br />
<br />
In browsing to the ARK directory you should now be able to see the login pages for the database. The tutorial database is created with the following two user accounts:<br />
<br />
<pre><br />
username: janedoe<br />
password: janedoe<br />
<br />
username: johnsmith<br />
password: johnsmith<br />
</pre><br />
<br />
If there are any problems, please check your [[settings.php]] and [[env_settings.php]] files to ensure you are using the correct settings.<br />
<br />
[[category:Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Key_Administration_Concepts&diff=741Key Administration Concepts2009-06-05T07:57:42Z<p>Sofia: /* mod_settings.php */</p>
<hr />
<div>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.<br />
<br />
===Settings Files===<br />
<br />
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.<br />
<br />
====env_settings.php====<br />
<br />
This small file contains only settings relating to the specific server environment. This is specifically for the ends of multiple sever environments.<br />
<br />
====settings.php====<br />
<br />
This is the main ARK settings file and contains settings relating to the entire instance of ARK.<br />
<br />
====vd_settings.php====<br />
<br />
This contains the validation rules. (See below).<br />
<br />
====field_settings.php====<br />
<br />
This contains the settings directives for fields. (See below).<br />
<br />
====mod_settings.php====<br />
<br />
These files contain settings for each installed module.<br />
<br />
===Forms Overview===<br />
<br />
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.<br />
<br />
====Validation Rules====<br />
<br />
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.<br />
<br />
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:<br />
<br />
#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.<br />
#They tell the update script how to validate that particular element of a fragment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
====Fields====<br />
<br />
Fields are made up of settings directives which typically include validation rules. Fields describe fragments and the way they are handled by the system.<br />
<br />
====Subforms====<br />
<br />
[[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.<br />
<br />
[[category: Administrator]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Views&diff=849Views2009-06-05T07:55:47Z<p>Sofia: /* Data View */</p>
<hr />
<div>===Views===<br />
ARK consists of different views<br />
<br />
====Data Entry====<br />
The Data Entry view allows the users to enter the data through to main forms: registration and data entry forms. Furthermore, an administrator can add their own data entry forms. <br />
<br />
====Data View==== <br />
This view is used for filtering the data and displaying it as lists or tables with the functionallity of exporting the lists.<br />
<br />
====Micro View====<br />
These pages provide a more compact view of the data in the different modules and can also be used to present data which have been input through other means like spatial features. <br />
<br />
====Map View====<br />
The Map View is used to display the spatial features of the ARK project.<br />
<br />
[[Category: Administrator]][[Category: Usermanual]]</div>Sofiahttps://ark.lparchaeology.com/wiki/index.php?title=Basic_Installation&diff=735Basic Installation2009-06-05T07:53:03Z<p>Sofia: /* Apache PHP MySQL */</p>
<hr />
<div>Preconfigured ARK setups are available from the ARK team. If you are unfamiliar with the setup and adminisration of webservers along with the security risks to your system and data this entails, please consider contacting us to aquire a fully running ARK. For those of you who have already got a server and want to go though the installation proceedure, we have provided the following notes:<br />
<br />
===Dependencies===<br />
<br />
ARK requires the following open source software packages to be installed on your server:<br />
<br />
#Apache 2<br />
#PHP 5<br />
#MySQL 5<br />
#PEAR Liveuser<br />
<br />
In order to benefit from the spatial integration offered by ARK, you will also need the following packages:<br />
<br />
#PHP Mapscript<br />
<br />
====Apache PHP MySQL====<br />
<br />
On most Linux distributions these packages will be installed by default. ARK is not particularly fussy about the version numbers of these packages and should run ok on PHP4 and MySQL4, although this may require some minor modifications. It is important to ensure that you have the gd and dbase php extensions enabled.<br />
<br />
You will need to make sure that you set the short_open_tag option to On in your [http://uk2.php.net/ini.core php.ini].<br />
<br />
For Mac OSX and Windows, these packages are available as binary distributions. ARK is known to run on [http://www.mamp.info/en/index.php MAMP], the binary distribution for Mac and [http://www.wampserver.com/en/ WAMP] or [http://www.maptools.org/ms4w/index.phtml MS4W], the binary distributions for Windows.<br />
<br />
The MS4W distribution also contains Mapserver and if this is installed only MySQL needs to be added.<br />
<br />
ARK runs on top of these packages and does not provide any set up of them or additional security to them. If you are using your server exposed to the internet, it is essential that you follow good standard security practice for the configuration of your packages. This setup is outside of the scope of this documentation and you are advised to undertake your research carefully.<br />
<br />
====PEAR LiveUser====<br />
<br />
The PEAR Liveuser is used to ensure effective security for the ARK system. ARK makes use of PEAR LiveUser, LiveUser_Admin, MDB2, and MDB2_driver_mysql, DB, and Event_Dispatcher. All of these packages will need to be installed in order for ARK user authentication to function.<br />
<br />
For details on how to install and configure live user, and the associated packages required, please see the [http://pear.php.net/package/LiveUser/ PEAR] website. '''PLEASE NOTE that ALL the PEAR SQL tables are already included with the basic ARK database, and do not need to be added to the database again during PEAR setup. ALSO the required PEAR depencies are included with the v0.6 files in the 'examples' directory.'''<br />
<br />
====MS4W====<br />
MS4W [http://www.maptools.org/ms4w/] is a no fuss installer for setting up MapServer on Microsoft Windows platforms. It includes a Apache HTTP version, PHP, Mapserver and loads of nice tools.<br />
<br />
MS4W is super simple to install on a server. Either download [http://www.maptools.org/ms4w/index.phtml?page=downloads.html] the base package which consists of a folder which unpacks to the C-drive of the server or try out the new installer. <br />
<br />
If you are using the base package you need to start the Apache server by running C:\ms4w\apache-install.bat. If the installation is succesful you should get the main page by pointing you browser to http://localhost/ or http://127.0.0.1/.<br />
<br />
If this does not work it is very likely that your port 80 is already in use. Go to C:\ms4w\Apache\conf\httpd.conf and on line 120 change LISTEN 80 to LISTEN 8080 or another port which is not in use.<br />
<br />
====Mapscript====<br />
<br />
Mapscript runs on all three major operating systems. The installation instructions vary depending on many factors. Detailed installation instructions are available on the [http://mapserver.gis.umn.edu/ Mapserver] website.<br />
<br />
===Installing ARK===<br />
<br />
Ark is installed by unpacking the source code into the document root of the webserver where you intend to host it. The second phase of installation is then the initial setup and creation of the empty database.<br />
<br />
====Download source====<br />
<br />
Download the latest source code from http://ark.lparchaeology.com/downloads and unpack it into the document root of your server. If you are unsure of the correct location of the document root, you could try reading the manual of your apache distribution.<br />
<br />
====Install a database====<br />
<br />
In order for ark to work, you need to install an ARK database on your MySQL server. Preconfigured sample databases are available for download from the download area of the ARK site. At present you must install the sql dump on the server manually using your tool of choice. We think that [http://www.phpmyadmin.net/home_page/index.php phpMyAdmin] is a good way to do this.<br />
<br />
#Download your chosen database dump file<br />
#Point your browser at the phpMyAdmin installation on your web-server<br />
#Make an empty database, by going to the Databases screen and filling in the Create new database box. Make the Collation utf8_unicode_ci and that should deal with most character sets.<br />
#Once the database is created, switch to it and choose Import<br />
#Using the Browse button, point it at the file that you have downloaded (it should be a tar.gz) - make the character set utf8<br />
#Click Go and wait a little while, and the database structure should be loaded up fine.<br />
#You will need to set up a user and give it at least SELECT, INSERT, UPDATE andDELETE privileges to the new db.<br />
<br />
===Update the DB Settings===<br />
<br />
You will now need to update the server-specific DB settings in [[settings.php#Server Specific Information|settings.php]]. '''THE DATABASE WILL NOT WORK UNTIL THESE SETTINGS HAVE BEEN UPDATED'''.<br />
<br />
===Browse to ARK directory===<br />
<br />
In browsing to the ARK directory you should now be able to see the login pages for the database. The tutorial database is created with the following two user accounts:<br />
<br />
<pre><br />
username: janedoe<br />
password: janedoe<br />
<br />
username: johnsmith<br />
password: johnsmith<br />
</pre><br />
<br />
If there are any problems, please check your [[settings.php]] and [[env_settings.php]] files to ensure you are using the correct settings.<br />
<br />
[[category:Administrator]]</div>Sofia