Difference between revisions of "Eprint fields.pl"

From EPrints Documentation
Jump to: navigation, search
(Properties)
m
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= EPrint Fields =
+
{{dirs}}
eprint_fields.pl defines all the optional fields which an EPrint object has. These fields all have mappings to the database. There are a variety of field types which you can see here [[:Category:EPrints_Metadata_Fields|here]].
+
{{cfgd}}
  
EPrints have a broad range of field types which enforce various constraints. Each field type has it's own method of storing in the database, retriving the value from the database, rendering the value in HTML, and rendering the input component HTML for use in workflows etc.
+
'''eprint_fields.pl''' defines all the optional fields which an EPrint object has. These fields all have mappings to the database. There are a variety of field types which you can see here [[:Category:EPrints_Metadata_Fields|here]].  
  
EPrints also has compound fields. This is a field made up of compound field definations. This allows you to make very powerful data structures without having to worry about the complexities of how they are stored in the database.
+
EPrints have a broad range of field types which enforce various constraints. Each field type has its own method of storing in the database, retrieving the value from the database, rendering the value in HTML, and rendering the input component HTML for use in workflows, etc.
  
Note removing fields from eprint_fields.pl does not usually cause data to be deleted from the database. To add or remove fields from eprint_fields.pl you must run <eprintsroot>/bin/epadmin update_database_structure <repo_id> and then reload you configuration (or restart the webserver).
+
EPrints also has [[Compound_field|compound]] fields. This is a field made up of compound field definitions. This allows you to make very powerful data structures without having to worry about the complexities of how they are stored in the database.
  
==Properties==
+
Note removing fields from eprint_fields.pl does not usually cause data to be deleted from the database. To add or remove fields from eprint_fields.pl you must run:
 +
EPRINTS_PATH/bin/epadmin update_database_structure ARCHIVEID
 +
and then reload your configuration (or restart the webserver).
  
{| border="1" cellpadding="4" cellspacing="0"
+
==Field Definition==
|name
+
The field list is represented by an arrayref of hashrefs. Each hashref has at minimum a <code>name</code>, which is the field name used when referring to the field (e.g. in search) and a <code>type</code>, which describes the type of data the field will hold. Depending on a field's type there may also be other compulsory fields and some optional ones. [[:Category:EPrints_Metadata_Fields |See the details of field definition on the page for that <code>type</code>.]]
|The identifier used for this field in EPrints. The name used to refer to a field whe you $eprint->value(), as part of a search, in citations etc.
+
 
|-
+
<pre>$c->{fields}->{eprint} = [
|type
+
          {
|The type of the field. Different types of field can result in different data structures begin returned when $eprint->value() is called. Types also enforce some basic validation again what is entered into them. Types include: text, longtext, name, email, compound, int, set, namedset, subject and so on. For a full list of possible field types you can see a full list of types [[:Category:EPrints_Metadata_Fields]]
+
            'name' => 'note',
|-
+
            'type' => 'longtext',
|multiple
+
            'input_rows' => 3,
|A <code>multiple=>1</code> field can have many values. Say for example: an item can have multiple tags, the tags field in this case would be a multiple field. Note if you use $eprint->value() on a multiple field it returns and array ref rather than a single scalar.
+
          },
|-
+
          ...
|input_style
+
];</pre>
|The width of the input elements which are rendered when this field is viewed (in a workflow for example). Possible values are: small,medium, large. If this value is not specifed the field will pick a sensible default.
+
 
|-
+
[[Category:Configuration]]
|input_rows
 
|
 
|}
 

Latest revision as of 00:36, 6 March 2022

EPrints 3 Reference: Directory Structure - Metadata Fields - Repository Configuration - XML Config Files - XML Export Format - EPrints data structure - Core API - Data Objects


Back to cfg.d

eprint_fields.pl defines all the optional fields which an EPrint object has. These fields all have mappings to the database. There are a variety of field types which you can see here here.

EPrints have a broad range of field types which enforce various constraints. Each field type has its own method of storing in the database, retrieving the value from the database, rendering the value in HTML, and rendering the input component HTML for use in workflows, etc.

EPrints also has compound fields. This is a field made up of compound field definitions. This allows you to make very powerful data structures without having to worry about the complexities of how they are stored in the database.

Note removing fields from eprint_fields.pl does not usually cause data to be deleted from the database. To add or remove fields from eprint_fields.pl you must run:

EPRINTS_PATH/bin/epadmin update_database_structure ARCHIVEID

and then reload your configuration (or restart the webserver).

Field Definition

The field list is represented by an arrayref of hashrefs. Each hashref has at minimum a name, which is the field name used when referring to the field (e.g. in search) and a type, which describes the type of data the field will hold. Depending on a field's type there may also be other compulsory fields and some optional ones. See the details of field definition on the page for that type.

$c->{fields}->{eprint} = [
          {
            'name' => 'note',
            'type' => 'longtext',
            'input_rows' => 3,
          },
          ...
];