Difference between revisions of "Sf finds"

From ARK
Jump to: navigation, search
 
Line 1: Line 1:
These are some notes describing the sf_finds.
+
This is a subform that originally was set up to add attributes to items. It also used to provide 'add to list' functionality. In addition, it also used to provide a set boolean mechanism so that users can actively state that attribute x was NOT true.
  
===Description===
+
Need to check with HRO if this form has been superceeded by the more generic sf_attr_bytype form. Looks like she is still using it for Portus despite what it says in the [[sf_assemblage]] documentation.
 
 
sf_assemblage can be used for displaying and editing attributes that have numbers chained to them. As an example, this could be used for recording the numbers of a certain type of seed in a sample, or for attaching total numbers of findtypes.
 
 
 
===Usage===
 
 
 
This form should normally be used in conjunction with [[sf_attr_bytype]]. The attribute gets added to the item and then sf_assemblage will offer you the chance to add one or more numbers to that attribute.
 
 
 
===Set-Up===
 
 
 
sf_assemblage needs a number of different 'op' variables set in the sf_conf and also it will need some custom validation set up (to allow for the chains).
 
 
 
===Examples===
 
 
 
In this example, sf_assemblage is being used to chain coordinates to a projection system that is attached to the item.
 
 
 
====the sf_conf====
 
 
 
  $conf_mcd_coords =
 
    array(
 
        'view_state' => 'max',
 
        'edit_state' => 'view',
 
        'sf_nav_type' => 'full',
 
        'sf_title' => 'coordinates', //appears in the titlebar of the subform (mk nname)
 
        'sf_html_id' => 'fst_cd_coordinates', //the form id tag (must be unique)
 
        'script' => 'php/subforms/sf_assemblage.php',
 
        'op_assemblage_type' => 'projection',
 
        'op_label' => 'save',
 
        'op_input' => 'save',
 
        'fields' => array(
 
            $conf_field_easting,
 
            $conf_field_northing
 
        )
 
  );
 
 
 
As you can see here this is a normal sf_conf setup except:
 
 
 
*'op_assemblage_type' - this is the type of attribute (in cor_lut_attribute) that the fields will be chained to.
 
 
 
====the fields====
 
 
 
The fields that are sent to this form - are the numbers (or in fact txt) that you want to chain to the attribute. They will need some custom validation rules setup to ensure that the add routine works correctly.
 
 
 
  //set up some custom validation for the coordinate chains
 
$vd_chainkey =
 
    array(
 
      'rq_func' => 'reqManual',
 
      'vd_func' => 'chkSet',
 
      'var_name' => 'itemkey',
 
      'force_var' => 'cor_tbl_attribute',
 
);
 
$vd_chainval =
 
    array(
 
      'rq_func' => 'reqMulti',
 
      'vd_func' => 'chkSet',
 
      'var_name' => 'itemval',
 
      'lv_name' => 'itemval',
 
      'var_locn' => 'request',
 
);
 
$conf_field_easting =
 
    array(
 
        'dataclass' => 'number',
 
        'classtype' => 'easting',
 
        'alias_tbl' => 'cor_lut_numbertype',
 
        'alias_col' => 'numbertype',
 
        'alias_src_key' => 'easting',
 
        'alias_type' => '1',
 
        'editable' => TRUE,
 
        'field_op_hidden' => FALSE,
 
        'add_validation' => $number_add_validation,
 
        'edt_validation' => $number_edt_validation
 
);
 
$conf_field_northing =
 
    array(
 
        'dataclass' => 'number',
 
        'classtype' => 'northing',
 
        'alias_tbl' => 'cor_lut_numbertype',
 
        'alias_col' => 'numbertype',
 
        'alias_src_key' => 'northing',
 
        'alias_type' => '1',
 
        'editable' => TRUE,
 
        'field_op_hidden' => FALSE,
 
        'add_validation' => $number_add_validation,
 
        'edt_validation' => $number_edt_validation
 
);
 
//add in the custom validation
 
$conf_field_easting['add_validation'][] = $vd_chainkey;
 
$conf_field_easting['add_validation'][] = $vd_chainval;
 
$conf_field_northing['add_validation'][] = $vd_chainkey;
 
$conf_field_northing['add_validation'][] = $vd_chainval;
 
 
 
[[category: Administrator]]
 

Revision as of 11:55, 6 March 2008

This is a subform that originally was set up to add attributes to items. It also used to provide 'add to list' functionality. In addition, it also used to provide a set boolean mechanism so that users can actively state that attribute x was NOT true.

Need to check with HRO if this form has been superceeded by the more generic sf_attr_bytype form. Looks like she is still using it for Portus despite what it says in the sf_assemblage documentation.