SUNScholar/Submissions/Forms
Contents
Forms
Go to the source folder by typing as follows:
cd /home/dspace/dspace-1.7.2-src-release/dspace/config
Edit the "input-forms.xml" file:
nano /home/dspace/dspace-1.7.2-src-release/dspace/config/input-forms.xml
Below are descriptions of the sections which can be customised.
Form maps (form2collection map)
Information from the file for setting up form maps.
<!-- The form-map maps collection handles to forms. DSpace does not --> <!-- require that a collection's name be unique, even within a community .--> <!-- DSpace does however insure that each collection's handle is unique. --> <!-- Form-map provides the means to associate a unique collection name --> <!-- with a form. The form-map also provides the special handle "default" --> <!-- (which is never a collection), here mapped to "traditional". Any --> <!-- collection which does not appear in this map will be associated with --> <!-- the mapping for handle "default". -->
For example:
<form-map> <name-map collection-handle="123456789/1" form-name="simple" /> </form-map>
Form definitions (form pages)
This is where you define what data is captured per page using the optional form common terms (controlled vocabularies) below.
Information from the file for setting up form definitions per form-name. Tip: Copy an existing definition to create a new one with a new form-name.
<!-- The form-definitions map lays out the detailed definition of all the --> <!-- submission forms.Each separate form set has a unique name as an --> <!-- attribute. This name matches one of the names in the form-map. One --> <!-- named form set has the name "traditional"; as this name suggests, --> <!-- it is the old style and is also the default, which gets used when --> <!-- the specified collection has no correspondingly named form set. --> <!-- --> <!-- Each form set contains an ordered set of pages; each page defines --> <!-- one submission metadata entry screen. Each page has an ordered list --> <!-- of field definitions, Each field definition corresponds to one --> <!-- metadata entry (a so-called row), which has a DC element name, a --> <!-- displayed label, a text string prompt which is called a hint , and --> <!-- an input-type. Each field also may hold optional elements: DC --> <!-- qualifier name, a repeatable flag, and a text string whose presence --> <!-- serves as a 'this field is required' flag. -->
Now you can customize the pages for the "simple" form by editing the pages in the new form-name definition.
Form common terms (controlled vocabularies)
This is where you define controlled vocabularies to be used per page per form per submission per collection.
<!-- form-value-pairs populate dropdown and qualdrop-value lists. --> <!-- The form-value-pairs element holds child elements named 'value-pairs' --> <!-- A 'value-pairs' element has a value-pairs-name and a dc-term --> <!-- attribute. The dc-term attribute specifies which to which Dublin Core --> <!-- Term this set of value-pairs applies. --> <!-- Current dc-terms are: identifier-pairs, type-pairs, and --> <!-- language_iso-pairs. The name attribute matches a name --> <!-- in the form-map, above. --> <!-- A value-pair contains one 'pair' for each value displayed in the list --> <!-- Each pair contains a 'displayed-value' element and a 'stored-value' --> <!-- element. A UI list displays the displayed-values, but the program --> <!-- stores the associated stored-values in the database. -->
- NANO Editor Help
| CTL+O | = Save the file and then press Enter |
| CTL+X | = Exit "nano" |
| CTL+K | = Delete line |
| CTL+U | = Undelete line |
| CTL+W | = Search for %%string%% |
| CTL+\ | = Search for %%string%% and replace with $$string$$ |
| CTL+C | = Show line numbers |
More info = http://en.wikipedia.org/wiki/Nano_(text_editor)