All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
Code Block | ||
---|---|---|
| ||
<item-submission> <!-- Where submission processes are mapped to specific Collections --> <submission-map> <name-map collection-handle="default" submission-name="traditional" /> ... </submission-map> <!-- Where "steps" which are used across many submission processes can be defined in a single place. They can then be referred to by ID later. --> <step-definitions> <step id="collection"> <processing-class>org.dspace.submit.step.SelectCollectionStep</process;/processing-class> <workflow-editable>false</workflow-editable> </step> ... </step-definitions> <!-- Where actual submission processes are defined and given names. Each <submission-process> has many <step> nodes which are in the order that the steps should be in.--> <submission-definitions> <submission-process name="traditional"> ... <!-- Step definitions appear here! --> </submission-process> ... </submission-definitions> </item-submission> |
...
For example:
Code Block | ||
---|---|---|
| ||
<step-definitions>
<step id="custom-step">
...
</step>
...
</step-definitions> |
For example:
Code Block | ||
---|---|---|
| ||
<submission-process> <step> ... </step> </submission-process> |
...
For example, the following defines a Submission Process where the License step directly precedes the Initial Questions step (more information about the structure of the information under each <step> tag can be found in the section on Structure of the <step> Definition below):
Code Block | ||
---|---|---|
| ||
<submission-process> <!--Step 1 will be to Sign off on the License--> <step> <heading>submit.progressbar.license</heading> <processing-class>org.dspace.submit.step.LicenseStep</processing-classing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPLicenseStep</jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.LicenseStenseStep</xmlui-binding> <workflow-editable>false</workflow-editable> </step> <!--Step 2 will be to Ask Initial Questions--> <step> <heading>submit.progressbar.initial-questions</heading> <processing-class>org.dspace.submit.step.InitialQuestionsStep</process;/processing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPInitialQuestionsSteonsStep</jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.InitialQutialQuestionsStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> ...[other steps]... </submission-process> |
...
The structure of the <step> Definition is as follows:
Code Block | ||
---|---|---|
| ||
<step> <heading>submit.progressbar.describe</heading> <processing-class>org.dspace.submit.step.DescribeStep</processing-classing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPDescribeStep</jspuilt;/jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.DescribeScribeStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> |
...
For example, the following fragment shows how the collection with handle "12345.6789/42" is assigned the "custom" submission process:
Code Block | ||
---|---|---|
| ||
<submission-map> <name-map collection-handle=" 12345.6789/42" submission-name=" custom" /> ... </submission-map> <submission-definitions> <submission-process name=" custom"> ... </submission-definitions> |
...
The XML configuration file has a single top-level element, input-forms, which contains three elements in a specific order. The outline is as follows:
Code Block | ||
---|---|---|
| ||
<input-forms> <-- Map of Collections to Form Sets --> <form-map> <name-map collection-handle="default" form-name="traditional" /> ... </form-map> <-- Form Set Definitions --> <form-definitions> <form name="traditional"> ... </form-definitions> <-- Name/Value Pairs used within Multiple Choice Widgets --> <form-value-pairs> <value-pairs value-pairs-name="common_iso_languages" dc-term="language_iso"> ... </form-value-pairs> </input-forms> |
...
For example, the following fragment shows how the collection with handle "12345.6789/42" is attached to the "TechRpt" form set:
Code Block | ||
---|---|---|
| ||
<form-map> <name-map collection-handle=" 12345.6789/42" form-name=" TechRpt"/> ... </form-map> <form-definitions> <form name="TechRept"> ... </form-definitions> |
...
A form must contain at least one and at most six pages. They are presented in the order they appear in the XML. Each page element must include a number attribute, that should be its sequence number, e.g.
Code Block | ||
---|---|---|
| ||
<page number="1"> |
The page element, in turn, contains a sequence of field elements. Each field defines an interactive dialog where the submitter enters one of the Dublin Core metadata items.
...
...
This feature is currently only available for use with the XMLUI. A field can be made visible depending on the value of dc.type. A new field element, <type-bind>, has been introduced to facilitate this. In this example the field will only be visible if a value of 'theses' or 'ebook' "thesis" or "ebook" has been entered for into dc.type on an earlier page:-
Code Block | ||
---|---|---|
| ||
<field> |
...
<dc-schema>dc</dc-schema> |
...
<dc-element>identifier</dc-element> |
...
<dc-qualifier>isbn</dc-qualifier> |
...
<label>ISBN</label> |
...
<type- |
...
bind>thesis,ebook</type-bind> |
...
</field> |
...
You may notice that some fields are automatically skipped when a custom form page is displayed, depending on the kind of item being submitted. This is because the DSpace user-interface engine skips Dublin Core fields which are not needed, according to the initial description of the item. For example, if the user indicates there are no alternate titles on the first "Describe" page (the one with a few checkboxes), the input for the title.alternative DC element is automatically elidedomitted, even on custom submission pages.
...
The answers to the first two questions control whether inputs for certain of the DC metadata fields will displayed, even if they are defined as fields in a custom page. Conversely, if the metadata fields controlled by a checkbox are not mentioned in the custom form, the checkbox is elided omitted from the initial page to avoid confusing or misleading the user.
The two relevant checkbox entries are "The item has more than one title, e.g. a translated title", and "The item has been published or publicly distributed before". The checkbox for multiple titles trigger the display of the field with dc-element equal to '"title' " and dc-qualifier equal to '"alternative'". If the controlling collection's form set does not contain this field, then the multiple titles question will not appear on the initial questions page.
...