Difference between revisions of "SUNScholar/Submission System"

From Libopedia
Jump to navigation Jump to search
Line 6: Line 6:
 
==[[SUNScholar/Submissions/Steps|Submission Steps]]==
 
==[[SUNScholar/Submissions/Steps|Submission Steps]]==
  
−
==Forms==
+
==[[SUNScholar/Submissions/Forms|Submission Forms per Step]]==
−
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.
 
−
<pre>
 
−
<!-- 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".                                    -->
 
−
</pre>
 
−
For example:
 
−
<pre>
 
−
<form-map>
 
−
  <name-map collection-handle="123456789/1" form-name="simple" />
 
−
</form-map>
 
−
</pre>
 
−
 
 
−
===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'''.
 
−
<pre>
 
−
<!-- 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.                          -->
 
−
</pre>
 
−
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.
 
−
<pre>
 
−
<!-- 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.                  -->
 
−
</pre>
 
−
 
 
−
{{NANO}}
 
  
 
==Notes==
 
==Notes==

Revision as of 13:14, 27 September 2012

Introduction

This wiki help page assumes that you have used the three system setup procedures to install an Ubuntu server with DSpace software.

Items are submitted to collections using forms. Each collection can have its own customised submission forms and these forms can also have customised pages. Below is information about form pages and collection submissions.

Submission Steps

Submission Forms per Step

Notes

  • The <required> element contains the textual hint displayed to the submitter about why the field is required. Leave it empty for optional fields.
  • The <vocabulary> element is optional. It allows you to specify the controlled vocabulary that this field should select its values from. This field also has an optional closed attribute. If closed is set to true, a user can only select values from the controlled vocabulary. By default, closed is set to false, which allows a user to also enter in free text if he/she chooses. For example:
    <vocabulary closed=”true”>srsc</vocabulary>
  • The name of the controlled vocabulary must correspond to the name of the XML file (without “.xml”) which contains the vocabulary. So, in the above example, srsc references the vocabulary specified in the file located at [dspace]/config/controlled-vocabularies/srsc.xml
  • Valid input types (for <input-type>) are:
    • “date”
    • “name” (two text boxes, labeled last and first name)
    • “onebox” (a one-line textbox)
    • “twobox” (two textboxes on a single line)
    • “dropdown” (for which you must specify a value-pairs-name attribute referring to the <value-pairs> list of allowed values.
    • “qualdrop_value” (a textbox, which is preceded by a “qualifying” dropdown of values. Requires a value-pairs-name attribute, similar to “dropdown”. Also requires <repeatable> is set to “true”)
    • “textarea”
  • Setting the <repeatable> element to “true” creates an “Add more” button, which allows you to add multiple values into that particular field. Examples of this include the authors and keywords fields in the standard DSpace submission process.

Activation of modified workflows

Rebuild the DSpace webapps using the custom rebuild script.

References

Back to Customisation
Retrieved from "http://wiki.lib.sun.ac.za/index.php?title=SUNScholar/Submission_System&oldid=15374"