mirror of
https://github.com/DSpace/DSpace.git
synced 2025-10-15 22:13:08 +00:00
0bd461646d
git-svn-id: http://scm.dspace.org/svn/repo/dspace/trunk@5002 9c30dcfa-912a-0410-8fc2-9e0234be79fd
211 lines
58 KiB
HTML
211 lines
58 KiB
HTML
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 14. DSpace System Documentation: Customizing and Configuring Submission User Interface</title><meta content="DocBook XSL Stylesheets V1.75.2" name="generator"><link rel="home" href="index.html" title="DSpace Manual"><link rel="up" href="index.html" title="DSpace Manual"><link rel="prev" href="ch13.html" title="Chapter 13. DSpace System Documentation: Business Logic Layer"><link rel="next" href="ch15.html" title="Chapter 15. DSpace System Documentation: DRI Schema Reference"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF" marginwidth="5m"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 14. DSpace System Documentation: Customizing and Configuring Submission User Interface</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch13.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch15.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 14. DSpace System Documentation: Customizing and Configuring Submission User Interface"><div class="titlepage"><div><div><h2 class="title"><a name="N1837A"></a>Chapter 14. <a name="docbook-submission.html"></a>DSpace System Documentation: Customizing and Configuring Submission User Interface</h2></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch14.html#N18382">14.1. Understanding the Submission Configuration File</a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N18391">14.1.1. The Structure of <code class="literal">item-submission.xml</code></a></span></dt><dt><span class="section"><a href="ch14.html#N183B7">14.1.2. Defining Steps (<code class="literal"><step></code>) within the <code class="literal">item-submission.xml</code></a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N183CA">14.1.2.1. Where to place your <code class="literal"><step></code> definitions</a></span></dt><dt><span class="section"><a href="ch14.html#N1841E">14.1.2.2. The ordering of <code class="literal"><step></code> definitions <span class="bold"><strong>matters</strong></span>!</a></span></dt><dt><span class="section"><a href="ch14.html#N18443">14.1.2.3. Structure of the <step> Definition</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="ch14.html#N184D5">14.2. Reordering/Removing Submission Steps</a></span></dt><dt><span class="section"><a href="ch14.html#N1857F">14.3. Assigning a custom Submission Process to a Collection</a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N185D4">14.3.1. Getting A Collection's Handle</a></span></dt></dl></dd><dt><span class="section"><a href="ch14.html#N185F2">14.4. Custom Metadata-entry Pages for Submission</a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N185F8">14.4.1. Introduction</a></span></dt><dt><span class="section"><a href="ch14.html#N18623">14.4.2. Describing Custom Metadata Forms</a></span></dt><dt><span class="section"><a href="ch14.html#N18646">14.4.3. The Structure of <code class="literal">input-forms.xml</code></a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N1865F">14.4.3.1. Adding a Collection Map</a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N18698">Getting A Collection's Handle</a></span></dt></dl></dd><dt><span class="section"><a href="ch14.html#N186B6">14.4.3.2. Adding a Form Set</a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N186CC">Forms and Pages</a></span></dt><dt><span class="section"><a href="ch14.html#N186F5">Composition of a Field</a></span></dt><dt><span class="section"><a href="ch14.html#N1883C">Automatically Elided Fields</a></span></dt></dl></dd><dt><span class="section"><a href="ch14.html#N18888">14.4.3.3. Adding <code class="literal">Value-Pairs</code></a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N188C5">Example</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="ch14.html#N188DB">14.4.4. Deploying Your Custom Forms</a></span></dt></dl></dd><dt><span class="section"><a href="ch14.html#N188F3">14.5. Configuring the File Upload step</a></span></dt><dt><span class="section"><a href="ch14.html#N1891C">14.6. Creating new Submission Steps</a></span></dt><dd><dl><dt><span class="section"><a href="ch14.html#N189B2">14.6.1. Creating a Non-Interactive Step</a></span></dt></dl></dd></dl></div><p>This page explains various customization and configuration options that are available within DSpace for the Item Submission user interface.</p><div class="section" title="14.1. Understanding the Submission Configuration File"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N18382"></a>14.1. <a name="docbook-submission.html-configurationFile"></a>Understanding the Submission Configuration File</h2></div></div><div></div></div><p>The <code class="literal">[dspace]/config/item-submission.xml</code> contains the submission configurations for <span class="emphasis"><em>both</em></span> the DSpace JSP user interface (JSPUI) or the DSpace XML user interface (XMLUI or Manakin). This configuration file contains detailed documentation within the file itself, which should help you better understand how to best utilize it.</p><div class="section" title="14.1.1. The Structure of item-submission.xml"><div class="titlepage"><div><div><h3 class="title"><a name="N18391"></a>14.1.1. The Structure of <code class="literal">item-submission.xml</code></h3></div></div><div></div></div><pre class="screen"><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> </pre><p> Because this file is in XML format, you should be familiar with XML before editing this file. By default, this file contains the "traditional" Item Submission Process for DSpace, which consists of the following Steps (in this order):</p><p>
|
||
<code class="literal">Select Collection -> Initial Questions -> Describe -> Upload -> Verify -> License -> Complete</code>
|
||
</p><p>If you would like to customize the steps used or the ordering of the steps, you can do so within the <code class="literal"><submission-definition></code> section of the <code class="literal">item-submission.xml</code> .</p><p>In addition, you may also specify different Submission Processes for different DSpace Collections. This can be done in the <code class="literal"><submission-map></code> section. The <code class="literal">item-submission.xml</code> file itself documents the syntax required to perform these configuration changes.</p></div><div class="section" title="14.1.2. Defining Steps (<step>) within the item-submission.xml"><div class="titlepage"><div><div><h3 class="title"><a name="N183B7"></a>14.1.2. <a name="docbook-submission.html--stepDefinitions"></a>Defining Steps (<code class="literal"><step></code>) within the <code class="literal">item-submission.xml</code></h3></div></div><div></div></div><p>This section describes how Steps of the Submission Process are defined within the <code class="literal">item-submission.xml</code>.</p><div class="section" title="14.1.2.1. Where to place your <step> definitions"><div class="titlepage"><div><div><h4 class="title"><a name="N183CA"></a>14.1.2.1. Where to place your <code class="literal"><step></code> definitions</h4></div></div><div></div></div><p><code class="literal"><step></code> definitions can appear in one of two places within the <code class="literal">item-submission.xml</code> configuration file.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> Within the <code class="literal"><step-definitions></code> section </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>This is for globally defined <code class="literal"><step></code> definitions (i.e. steps which are used in multiple <code class="literal"><submission-process></code> definitions). Steps defined in this section <span class="bold"><strong>must</strong></span> define a unique <code class="literal">id</code> which can be used to reference this step.</p></li><li class="listitem"><p>For example:</p><pre class="screen"><step-definitions>
|
||
<step id="custom-step">
|
||
...
|
||
</step>
|
||
...
|
||
</step-definitions></pre></li><li class="listitem"><p> The above step definition could then be referenced from within a <code class="literal"><submission-process></code> as simply <code class="literal"><step id="custom-step"/></code></p></li></ul></div></li><li class="listitem"><p>Within a specific <code class="literal"><submission-process></code> definition </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>This is for steps which are specific to a single <code class="literal"><submission-process></code> definition.</p></li><li class="listitem"><p>For example: </p><pre class="screen"><submission-process>
|
||
<step>
|
||
...
|
||
</step>
|
||
</submission-process></pre></li></ul></div></li></ol></div></div><div class="section" title="14.1.2.2. The ordering of <step> definitions matters!"><div class="titlepage"><div><div><h4 class="title"><a name="N1841E"></a>14.1.2.2. The ordering of <code class="literal"><step></code> definitions <span class="bold"><strong>matters</strong></span>!</h4></div></div><div></div></div><p>The ordering of the <code class="literal"><step></code> tags within a <code class="literal"><submission-process></code> definition directly corresponds to the order in which those steps will appear!</p><p>For example, the following defines a Submission Process where the <span class="emphasis"><em>License</em></span> step directly precedes the <span class="emphasis"><em>Initial Questions</em></span> step (more information about the structure of the information under each <step> tag can be found in the section on <a class="link" href="ch14.html#docbook-submission.html-stepStructure">Structure of the <step> Definition</a> below):</p><pre class="screen"><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> </pre></div><div class="section" title="14.1.2.3. Structure of the <step> Definition"><div class="titlepage"><div><div><h4 class="title"><a name="N18443"></a>14.1.2.3. <a name="docbook-submission.html-stepStructure"></a>Structure of the <step> Definition</h4></div></div><div></div></div><p>The same <step> definition is used by both the DSpace JSP user interface (JSPUI) an the DSpace XML user interface (XMLUI or Manakin). Therefore, you will notice each <step> definition contains information specific to each of these two interfaces.</p><p>The structure of the <step> Definition is as follows:</p><pre class="screen"><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></pre><p>Each <code class="literal">step</code> contains the following elements. The required elements are so marked:</p><div class="variablelist"><dl><dt><span class="term">
|
||
<span class="bold"><strong>heading</strong></span>
|
||
</span></dt><dd><p>Partial I18N key (defined in <code class="literal">Messages.properties</code> for JSPUI or <code class="literal">messages.xml</code> for XMLUI) which corresponds to the text that should be displayed in the submission Progress Bar for this step. This partial I18N key is prefixed within either the Messages.properties or messages.xml file, depending on the interface you are using. Therefore, to find the actual key, you will need to search for the partial key with the following prefix: <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> XMLUI: prefix is <code class="literal">xmlui.Submission.</code> (e.g. "xmlui.Submission.submit.progressbar.describe" for 'Describe' step)</p></li><li class="listitem"><p> JSPUI: prefix is <code class="literal">jsp.</code> (e.g. "jsp.submit.progressbar.describe" for 'Describe' step)</p></li></ul></div>
|
||
<span class="emphasis"><em>The 'heading' need not be defined if the step should not appear in the progress bar (e.g. steps which perform automated processing, i.e. non-interactive, should not appear in the progress bar).</em></span></p></dd><dt><span class="term">
|
||
<span class="bold"><strong>processing-class</strong></span>
|
||
<span class="emphasis"><em>(Required)</em></span>
|
||
</span></dt><dd><p>Full Java path to the Processing Class for this Step. This Processing Class <span class="emphasis"><em>must</em></span> perform the primary processing of any information gathered in this step, <span class="emphasis"><em>for both the XMLUI and JSPUI</em></span>. All valid step processing classes must extend the abstract `<code class="literal">org.dspace.submit.AbstractProcessingStep</code>` class (or alternatively, extend one of the pre-existing step processing classes in <code class="literal">org.dspace.submit.step.*</code>)</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>jspui-binding</strong></span>
|
||
</span></dt><dd><p>Full Java path of the JSPUI "binding" class for this Step. This "binding" class should initialize and call the appropriate JSPs to display the step's user interface. A valid JSPUI "binding" class <span class="emphasis"><em>must</em></span> extend the abstract `<code class="literal">org.dspace.app.webui.submit.JSPStep</code>` class. <span class="emphasis"><em>This property need not be defined if you are using the XMLUI interface, or for steps which only perform automated processing, i.e. non-interactive steps.</em></span></p></dd><dt><span class="term">
|
||
<span class="bold"><strong>xmlui-binding</strong></span>
|
||
</span></dt><dd><p>Full Java path of the XMLUI "binding" class for this Step. This "binding" class should generate the Manakin XML (DRI document) necessary to generate the step's user interface. A valid XMLUI "binding" class <span class="emphasis"><em>must</em></span> extend the abstract `<code class="literal">org.dspace.app.xmlui.submission.AbstractSubmissionStep</code>` class. <span class="emphasis"><em>This property need not be defined if you are using the JSPUI interface, or for steps which only perform automated processing, i.e. non-interactive steps.</em></span></p></dd><dt><span class="term">
|
||
<span class="bold"><strong>workflow-editable</strong></span>
|
||
</span></dt><dd><p>Defines whether or not this step can be edited during the <span class="emphasis"><em>Edit Metadata</em></span> process with the DSpace approval/rejection workflow process. Possible values include <code class="literal">true</code> and <code class="literal">false</code>. If undefined, defaults to <code class="literal">true</code> (which means that workflow reviewers would be allowed to edit information gathered during that step).</p></dd></dl></div></div></div></div><div class="section" title="14.2. Reordering/Removing Submission Steps"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N184D5"></a>14.2. <a name="docbook-submission.html-stepOrdering"></a>Reordering/Removing Submission Steps</h2></div></div><div></div></div><p>The removal of existing steps and reordering of existing steps is a relatively easy process!</p><p>
|
||
<span class="bold"><strong>Reordering steps</strong></span>
|
||
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> Locate the <code class="literal"><submission-process></code> tag which defines the Submission Process that you are using. If you are unsure which Submission Process you are using, it's likely the one with <code class="literal">name="traditional"</code>, since this is the traditional DSpace submission process.</p></li><li class="listitem"><p> Reorder the <code class="literal"><step></code> tags within that <code class="literal"><submission-process></code> tag. Be sure to move the <span class="emphasis"><em>entire</em></span><code class="literal"><step></code> tag (i.e. everything between and including the opening <code class="literal"><step></code> and closing <code class="literal"></step></code> tags). </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Hint #1:</em></span> The <code class="literal"><step></code> defining the <span class="emphasis"><em>Review/Verify</em></span> step only allows the user to review information from steps which appear <span class="bold"><strong>before</strong></span> it. So, it's likely you'd want this to appear as one of your last few steps</p></li><li class="listitem"><p><span class="emphasis"><em>Hint #2:</em></span> If you are using it, the <code class="literal"><step></code> defining the <span class="emphasis"><em>Initial Questions</em></span> step should always appear <span class="bold"><strong>before</strong></span> the <span class="emphasis"><em>Upload</em></span> or <span class="emphasis"><em>Describe</em></span> steps since it asks questions which help to set up those later steps.</p></li></ul></div></li></ol></div><p>
|
||
<span class="bold"><strong>Removing one or more steps</strong></span>
|
||
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> Locate the <code class="literal"><submission-process></code> tag which defines the Submission Process that you are using. If you are unsure which Submission Process you are using, it's likely the one with <code class="literal">name="traditional"</code>, since this is the traditional DSpace submission process.</p></li><li class="listitem"><p> Comment out (i.e. surround with <!-- and -->) the <code class="literal"><step></code> tags which you want to remove from that <code class="literal"><submission-process></code> tag. Be sure to comment out the <span class="emphasis"><em>entire</em></span><code class="literal"><step></code> tag (i.e. everything between and including the opening <code class="literal"><step></code> and closing <code class="literal"></step></code> tags). </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="emphasis"><em>Hint #1:</em></span> You cannot remove the <span class="emphasis"><em>Select a Collection</em></span> step, as an DSpace Item cannot exist without belonging to a Collection.</p></li><li class="listitem"><p><span class="emphasis"><em>Hint #2:</em></span> If you decide to remove the <code class="literal"><step></code> defining the <span class="emphasis"><em>Initial Questions</em></span> step, you should be aware that this may affect your <span class="emphasis"><em>Describe</em></span> and <span class="emphasis"><em>Upload</em></span> steps! The <span class="emphasis"><em>Initial Questions</em></span> step asks questions which help to initialize these later steps. If you decide to remove the <span class="emphasis"><em>Initial Questions</em></span> step you may wish to create a custom, automated step which will provide default answers for the questions asked!</p></li></ul></div></li></ol></div></div><div class="section" title="14.3. Assigning a custom Submission Process to a Collection"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1857F"></a>14.3. <a name="docbook-submission.html-collectionSubmission"></a>Assigning a custom Submission Process to a Collection</h2></div></div><div></div></div><p>Assigning a custom submission process to a Collection in DSpace involves working with the <code class="literal">submission-map</code> section of the <code class="literal">item-submission.xml</code>. For a review of the structure of the <code class="literal">item-submission.xml</code> see the section above on <a class="link" href="ch14.html#docbook-submission.html-configurationFile">Understanding the Submission Configuration File</a>.</p><p>Each <code class="literal">name-map</code> element within <code class="literal">submission-map</code> associates a collection with the name of a submission definition. Its <code class="literal">collection-handle</code> attribute is the Handle of the collection. Its <code class="literal">submission-name</code> attribute is the submission definition name, which must match the <code class="literal">name</code> attribute of a <code class="literal">submission-process</code> element (in the <code class="literal">submission-definitions</code> section of <code class="literal">item-submission.xml</code>.</p><p>For example, the following fragment shows how the collection with handle "12345.6789/42" is assigned the "custom" submission process:</p><pre class="screen"><submission-map>
|
||
<name-map collection-handle="<span class="bold"><strong> 12345.6789/42</strong></span>" submission-name="<span class="bold"><strong>
|
||
custom</strong></span>" />
|
||
...
|
||
</submission-map>
|
||
|
||
<submission-definitions>
|
||
<submission-process name="<span class="bold"><strong>
|
||
custom</strong></span>">
|
||
...
|
||
</submission-definitions>
|
||
</pre><p>It's a good idea to keep the definition of the <code class="literal">default</code> name-map from the example <code class="literal">input-forms.xml</code> so there is always a default for collections which do not have a custom form set.</p><div class="section" title="14.3.1. Getting A Collection's Handle"><div class="titlepage"><div><div><h3 class="title"><a name="N185D4"></a>14.3.1. Getting A Collection's Handle</h3></div></div><div></div></div><p>You will need the <span class="emphasis"><em>handle</em></span> of a collection in order to assign it a custom form set. To discover the handle, go to the "Communities & Collections" page under "<span class="bold"><strong>Browse</strong></span>" in the left-hand menu on your DSpace home page. Then, find the link to your collection. It should look something like:</p><pre class="screen">
|
||
http://myhost.my.edu/dspace/handle/<span class="underline">
|
||
12345.6789/42</span>
|
||
</pre><p>The underlined part of the URL is the handle. It should look familiar to any DSpace administrator. That is what goes in the <code class="literal">collection-handle</code> attribute of your <code class="literal">name-map</code> element.</p></div></div><div class="section" title="14.4. Custom Metadata-entry Pages for Submission"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N185F2"></a>14.4. <a name="docbook-submission.html-metadataEntry"></a>Custom Metadata-entry Pages for Submission</h2></div></div><div></div></div><div class="section" title="14.4.1. Introduction"><div class="titlepage"><div><div><h3 class="title"><a name="N185F8"></a>14.4.1. Introduction</h3></div></div><div></div></div><p>This section explains how to customize the Web forms used by submitters and editors to enter and modify the metadata for a new item. These metadata web forms are controlled by the <span class="emphasis"><em>Describe</em></span> step within the Submission Process. However, they are also configurable via their own XML configuration file (<code class="literal">input-forms.xml</code>).</p><p>You can customize the "default" metadata forms used by all collections, and also create alternate sets of metadata forms and assign them to specific collections. In creating custom metadata forms, you can choose:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> The number of metadata-entry pages.</p></li><li class="listitem"><p> Which fields appear on each page, and their sequence.</p></li><li class="listitem"><p> Labels, prompts, and other text associated with each field.</p></li><li class="listitem"><p> List of available choices for each menu-driven field.</p></li></ul></div><p><span class="bold"><strong>N.B.</strong></span>The cosmetic and ergonomic details of metadata entry fields remain the same as the fixed metadata pages in previous DSpace releases, and can only be altered by modifying the appropriate stylesheet and JSP pages.</p><p>All of the custom metadata-entry forms for a DSpace instance are controlled by a single XML file, <code class="literal">input-forms.xml</code>, in the <code class="literal">config</code> subdirectory under the DSpace home. DSpace comes with a sample configuration that implements the traditional metadata-entry forms, which also serves as a well-documented example. The rest of this section explains how to create your own sets of custom forms.</p></div><div class="section" title="14.4.2. Describing Custom Metadata Forms"><div class="titlepage"><div><div><h3 class="title"><a name="N18623"></a>14.4.2. Describing Custom Metadata Forms</h3></div></div><div></div></div><p>The description of a set of pages through which submitters enter their metadata is called a <span class="emphasis"><em>form</em></span> (although it is actually a set of forms, in the HTML sense of the term). A form is identified by a unique symbolic <span class="emphasis"><em>name</em></span>. In the XML structure, the <span class="emphasis"><em>form</em></span> is broken down into a series of <span class="emphasis"><em>pages</em></span>: each of these represents a separate Web page for collecting metadata elements.</p><p>To set up one of your DSpace collections with customized submission forms, first you make an entry in the <span class="emphasis"><em>form-map</em></span>. This is effectively a table that relates a collection to a form set, by connecting the collection's <span class="emphasis"><em>Handle</em></span> to the form name. Collections are identified by handle because their names are mutable and not necessarily unique, while handles are unique and persistent.</p><p>A special map entry, for the collection handle "default", defines the <span class="emphasis"><em>default</em></span> form set. It applies to all collections which are not explicitly mentioned in the map. In the example XML this form set is named <code class="literal">traditional</code> (for the "traditional" DSpace user interface) but it could be named anything.</p></div><div class="section" title="14.4.3. The Structure of input-forms.xml"><div class="titlepage"><div><div><h3 class="title"><a name="N18646"></a>14.4.3. The Structure of <code class="literal">input-forms.xml</code></h3></div></div><div></div></div><p>The XML configuration file has a single top-level element, <code class="literal">input-forms</code>, which contains three elements in a specific order. The outline is as follows:</p><pre class="screen">
|
||
<input-forms>
|
||
|
||
<-- <span class="emphasis"><em> Map of Collections to Form Sets</em></span> -->
|
||
<form-map>
|
||
<name-map collection-handle="default" form-name="traditional"
|
||
/>
|
||
...
|
||
</form-map>
|
||
|
||
<-- <span class="emphasis"><em> Form Set Definitions</em></span> -->
|
||
<form-definitions>
|
||
<form name="traditional">
|
||
...
|
||
</form-definitions>
|
||
|
||
<-- <span class="emphasis"><em> Name/Value Pairs used within Multiple Choice Widgets</em></span>
|
||
-->
|
||
<form-value-pairs>
|
||
<value-pairs value-pairs-name="common_iso_languages"
|
||
dc-term="language_iso">
|
||
...
|
||
</form-value-pairs>
|
||
</input-forms>
|
||
</pre><div class="section" title="14.4.3.1. Adding a Collection Map"><div class="titlepage"><div><div><h4 class="title"><a name="N1865F"></a>14.4.3.1. Adding a Collection Map</h4></div></div><div></div></div><p>Each <code class="literal">name-map</code> element within <code class="literal">form-map</code> associates a collection with the name of a form set. Its <code class="literal">collection-handle</code> attribute is the Handle of the collection, and its <code class="literal">form-name</code> attribute is the form set name, which must match the <code class="literal">name</code> attribute of a <code class="literal">form</code> element.</p><p>For example, the following fragment shows how the collection with handle "12345.6789/42" is attached to the "TechRpt" form set:</p><pre class="screen">
|
||
<form-map>
|
||
<name-map collection-handle="<span class="bold"><strong> 12345.6789/42</strong></span>" form-name="<span class="bold"><strong> TechRpt</strong></span>"
|
||
/>
|
||
...
|
||
</form-map>
|
||
|
||
<form-definitions>
|
||
<form name="<span class="bold"><strong>
|
||
TechRept</strong></span>">
|
||
...
|
||
</form-definitions>
|
||
</pre><p>It's a good idea to keep the definition of the <code class="literal">default</code> name-map from the example <code class="literal">input-forms.xml</code> so there is always a default for collections which do not have a custom form set.</p><div class="section" title="Getting A Collection's Handle"><div class="titlepage"><div><div><h5 class="title"><a name="N18698"></a>Getting A Collection's Handle</h5></div></div><div></div></div><p>You will need the <span class="emphasis"><em>handle</em></span> of a collection in order to assign it a custom form set. To discover the handle, go to the "Communities & Collections" page under "<span class="bold"><strong>Browse</strong></span>" in the left-hand menu on your DSpace home page. Then, find the link to your collection. It should look something like:</p><pre class="screen">
|
||
http://myhost.my.edu/dspace/handle/<span class="underline">
|
||
12345.6789/42</span>
|
||
</pre><p>The underlined part of the URL is the handle. It should look familiar to any DSpace administrator. That is what goes in the <code class="literal">collection-handle</code> attribute of your <code class="literal">name-map</code> element.</p></div></div><div class="section" title="14.4.3.2. Adding a Form Set"><div class="titlepage"><div><div><h4 class="title"><a name="N186B6"></a>14.4.3.2. Adding a Form Set</h4></div></div><div></div></div><p>You can add a new form set by creating a new <code class="literal">form</code> element within the <code class="literal">form-definitions</code> element. It has one attribute, <code class="literal">name</code>, which as seen above must match the value of the <code class="literal">name-map</code> for the collections it is to be used for.</p><div class="section" title="Forms and Pages"><div class="titlepage"><div><div><h5 class="title"><a name="N186CC"></a>Forms and Pages</h5></div></div><div></div></div><p>The content of the <code class="literal">form</code> is a sequence of <code class="literal">page</code> elements. Each of these corresponds to a Web page of forms for entering metadata elements, presented in sequence between the initial "Describe" page and the final "Verify" page (which presents a summary of all the metadata collected).</p><p>A <code class="literal">form</code> must contain at least one and at most six pages. They are presented in the order they appear in the XML. Each <code class="literal">page</code> element must include a <code class="literal">number</code> attribute, that should be its sequence number, e.g.</p><pre class="screen">
|
||
<page number="1">
|
||
</pre><p>The <code class="literal">page</code> element, in turn, contains a sequence of <code class="literal">field</code> elements. Each field defines an interactive dialog where the submitter enters one of the Dublin Core metadata items.</p></div><div class="section" title="Composition of a Field"><div class="titlepage"><div><div><h5 class="title"><a name="N186F5"></a>Composition of a Field</h5></div></div><div></div></div><p>Each <code class="literal">field</code> contains the following elements, in the order indicated. The required sub-elements are so marked:</p><div class="variablelist"><dl><dt><span class="term">
|
||
<span class="bold"><strong>dc-schema</strong></span>
|
||
<span class="emphasis"><em>(Required)</em></span>
|
||
</span></dt><dd><p>Name of metadata schema employed, e.g. <code class="literal">dc</code> for Dublin Core. This value must match the value of the <code class="literal">schema</code> element defined in <code class="literal">dublin-core-types.xml</code></p></dd><dt><span class="term">
|
||
<span class="bold"><strong>dc-element</strong></span>
|
||
<span class="emphasis"><em>(Required)</em></span>
|
||
</span></dt><dd><p>Name of the Dublin Core element entered in this field, e.g. <code class="literal">contributor</code>.</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>dc-qualifier</strong></span>
|
||
</span></dt><dd><p>Qualifier of the Dublin Core element entered in this field, e.g. when the field is <code class="literal">contributor.advisor</code> the value of this element would be <code class="literal">advisor</code>. Leaving this out means the input is for an unqualified DC element.</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>repeatable</strong></span>
|
||
</span></dt><dd><p>Value is <code class="literal">true</code> when multiple values of this field are allowed, <code class="literal">false</code> otherwise. When you mark a field repeatable, the UI servlet will add a control to let the user ask for more fields to enter additional values. Intended to be used for arbitrarily-repeating fields such as subject keywords, when it is impossible to know in advance how many input boxes to provide.</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>label</strong></span>
|
||
<span class="emphasis"><em>(Required)</em></span>
|
||
</span></dt><dd><p>Text to display as the label of this field, describing what to enter, e.g. "<code class="literal">Your Advisor's Name</code>".</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>input-type</strong></span>
|
||
<span class="emphasis"><em>(Required)</em></span>
|
||
</span></dt><dd><p>Defines the kind of interactive widget to put in the form to collect the Dublin Core value. Content must be one of the following keywords: <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="bold"><strong>onebox</strong></span> -- A single text-entry box.</p></li><li class="listitem"><p><span class="bold"><strong>twobox</strong></span> -- A pair of simple text-entry boxes, used for <span class="emphasis"><em>repeatable</em></span> values such as the DC <code class="literal">subject</code> item. <span class="emphasis"><em>Note:</em></span> The 'twobox' input type is rendered the same as a 'onebox' in the XML-UI, but both allow for ease of adding multiple values.</p></li><li class="listitem"><p><span class="bold"><strong>textarea</strong></span> -- Large block of text that can be entered on multiple lines, e.g. for an abstract.</p></li><li class="listitem"><p><span class="bold"><strong>name</strong></span> -- Personal name, with separate fields for family name and first name. When saved they are appended in the format 'LastName, FirstName'</p></li><li class="listitem"><p><span class="bold"><strong>date</strong></span> -- Calendar date. When required, demands that at least the year be entered.</p></li><li class="listitem"><p><span class="bold"><strong>series</strong></span> -- Series/Report name and number. Separate fields are provided for series name and series number, but they are appended (with a semicolon between) when saved.</p></li><li class="listitem"><p><span class="bold"><strong>dropdown</strong></span> -- Choose value(s) from a "drop-down" menu list. <span class="bold"><strong>Note:</strong></span> You must also include a value for the <code class="literal">value-pairs-name</code> attribute to specify a list of menu entries from which to choose. Use this to make a choice from a restricted set of options, such as for the <code class="literal">language</code> item.</p></li><li class="listitem"><p><span class="bold"><strong>qualdrop_value</strong></span> -- Enter a "qualified value", which includes <span class="emphasis"><em>both</em></span> a qualifier from a drop-down menu and a free-text value. Used to enter items like alternate identifiers and codes for a submitted item, e.g. the DC <code class="literal">identifier</code> field. <span class="bold"><strong>Note:</strong></span> As for the <code class="literal">dropdown</code> type, you must include the <code class="literal">value-pairs-name</code> attribute to specify a menu choice list.</p></li><li class="listitem"><p><span class="bold"><strong>list</strong></span> -- Choose value(s) from a checkbox or radio button list. If the <code class="literal">repeatable</code> attribute is set to <code class="literal">true</code>, a list of checkboxes is displayed. If the <code class="literal">repeatable</code> attribute is set to <code class="literal">false</code>, a list of radio buttons is displayed. <span class="bold"><strong>Note:</strong></span> You must also include a value for the <code class="literal">value-pairs-name</code> attribute to specify a list of values from which to choose.</p></li></ul></div></p></dd><dt><span class="term">
|
||
<span class="bold"><strong>hint</strong></span>
|
||
<span class="emphasis"><em>(Required)</em></span>
|
||
</span></dt><dd><p>Content is the text that will appear as a "hint", or instructions, next to the input fields. Can be left empty, but it must be present.</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>required</strong></span>
|
||
</span></dt><dd><p>When this element is included with any content, it marks the field as a required input. If the user tries to leave the page without entering a value for this field, that text is displayed as a warning message. For example,</p><p><code class="literal"><required>You must enter a title.</required> Note that leaving the</code> required element empty will <span class="emphasis"><em>not</em></span> mark a field as required, e.g.:</p><p>
|
||
<code class="literal"><required></required></code>
|
||
</p></dd><dt><span class="term">
|
||
<span class="bold"><strong>visibility</strong></span>
|
||
</span></dt><dd><p>When this optional element is included with a value, it restricts the visibility of the field to the scope defined by that value. If the element is missing or empty, the field is visible in all scopes. Currently supported scopes are: <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="bold"><strong>workflow</strong></span> : the field will only be visible in the workflow stages of submission. This is good for hiding difficult fields for users, such as subject classifications, thereby easing the use of the submission system.</p></li><li class="listitem"><p><span class="bold"><strong>submit</strong></span> : the field will only be visible in the initial submission, and not in the workflow stages.</p></li></ul></div> In addition, you can decide which type of restriction apply: read-only or full hidden the field (default behaviour) using the <code class="literal">otherwise</code> attribute of the <code class="literal">visibility</code> XML element. For example:</p><p>
|
||
<code class="literal"><visibility otherwise="readonly">workflow</visibility></code>
|
||
</p><p> Note that it is considered a configuration error to limit a field's scope while also requiring it - an exception will be generated when this combination is detected.</p></dd></dl></div><p>Look at the example <code class="literal">input-forms.xml</code> and experiment with a a trial custom form to learn this specification language thoroughly. It is a very simple way to express the layout of data-entry forms, but the only way to learn all its subtleties is to use it.</p><p>For the use of controlled vocabularies see the <a class="link" href="ch05.html#docbook-configure.html-controlled-vocab">Configuring Controlled Vocabularies</a> section.</p></div><div class="section" title="Automatically Elided Fields"><div class="titlepage"><div><div><h5 class="title"><a name="N1883C"></a>Automatically Elided Fields</h5></div></div><div></div></div><p>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 <code class="literal">title.alternative</code> DC element is automatically elided, <span class="emphasis"><em>even on custom submission pages.</em></span></p><p> When a user initiates a submission, DSpace first displays what we'll call the "initial-questions page". By default, it contains three questions with check-boxes: <div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
|
||
<span class="bold"><strong>The item has more than one title, e.g. a translated title</strong></span>
|
||
</p><p> Controls <code class="literal">title.alternative</code> field.</p></li><li class="listitem"><p>
|
||
<span class="bold"><strong>The item has been published or publicly distributed before</strong></span>
|
||
</p><p> Controls DC fields: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
<code class="literal">date.issued</code>
|
||
</p></li><li class="listitem"><p>
|
||
<code class="literal">publisher</code>
|
||
</p></li><li class="listitem"><p>
|
||
<code class="literal">identifier.citation</code>
|
||
</p></li></ul></div></li><li class="listitem"><p>
|
||
<span class="bold"><strong>The item consists of more than one file</strong></span>
|
||
</p><p>
|
||
<span class="emphasis"><em>Does not affect any metadata input fields.</em></span>
|
||
</p></li></ol></div> 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 from the initial page to avoid confusing or misleading the user.</p><p>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.</p></div></div><div class="section" title="14.4.3.3. Adding Value-Pairs"><div class="titlepage"><div><div><h4 class="title"><a name="N18888"></a>14.4.3.3. Adding <code class="literal">Value-Pairs</code></h4></div></div><div></div></div><p> Finally, your custom form description needs to define the "value pairs" for any fields with input types that refer to them. Do this by adding a <code class="literal">value-pairs</code> element to the contents of <code class="literal">form-value-pairs</code>. It has the following required attributes: <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="bold"><strong>value-pairs-name</strong></span> -- Name by which an <code class="literal">input-type</code> refers to this list.</p></li><li class="listitem"><p><span class="bold"><strong>dc-term</strong></span> -- Qualified Dublin Core field for which this choice list is selecting a value.</p></li></ul></div> Each <code class="literal">value-pairs</code> element contains a sequence of <code class="literal">pair</code> sub-elements, each of which in turn contains two elements: <div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><span class="bold"><strong>displayed-value</strong></span> -- Name shown (on the web page) for the menu entry.</p></li><li class="listitem"><p><span class="bold"><strong>stored-value</strong></span> -- Value stored in the DC element when this entry is chosen.</p></li></ul></div> Unlike the HTML <code class="literal">select</code> tag, there is no way to indicate one of the entries should be the default, so the first entry is always the default choice.</p><div class="section" title="Example"><div class="titlepage"><div><div><h5 class="title"><a name="N188C5"></a>Example</h5></div></div><div></div></div><p>Here is a menu of types of common identifiers:</p><pre class="screen">
|
||
<value-pairs value-pairs-name="common_identifiers"
|
||
dc-term="identifier">
|
||
<pair>
|
||
<displayed-value>Gov't Doc
|
||
#</displayed-value>
|
||
<stored-value>govdoc</stored-value>
|
||
</pair>
|
||
<pair>
|
||
<displayed-value>URI</displayed-value>
|
||
<stored-value>uri</stored-value>
|
||
</pair>
|
||
<pair>
|
||
<displayed-value>ISBN</displayed-value>
|
||
<stored-value>isbn</stored-value>
|
||
</pair>
|
||
</value-pairs>
|
||
</pre><p> It generates the following HTML, which results in the menu widget below. (Note that there is no way to indicate a default choice in the custom input XML, so it cannot generate the HTML <code class="literal">SELECTED</code> attribute to mark one of the options as a pre-selected default.) <pre class="screen">
|
||
<select name="identifier_qualifier_0">
|
||
<option VALUE="govdoc">Gov't Doc
|
||
#</option>
|
||
<option VALUE="uri">URI</option>
|
||
<option VALUE="isbn">ISBN</option>
|
||
</select>
|
||
</pre><span class="bold"><strong>Identifiers:</strong></span>Gov't Doc #URIISBN</p></div></div></div><div class="section" title="14.4.4. Deploying Your Custom Forms"><div class="titlepage"><div><div><h3 class="title"><a name="N188DB"></a>14.4.4. Deploying Your Custom Forms</h3></div></div><div></div></div><p> The DSpace web application only reads your custom form definitions when it starts up, so it is important to remember: <div class="blockquote"><blockquote class="blockquote"><p>
|
||
<span class="emphasis"><em><span class="bold"><strong>You must always restart Tomcat</strong></span> (or whatever servlet container you are using) for changes made to the <code class="literal">input-forms.xml</code> file take effect.</em></span>
|
||
</p></blockquote></div> Any mistake in the syntax or semantics of the form definitions, such as poorly formed XML or a reference to a nonexistent field name, will cause a fatal error in the DSpace UI. The exception message (at the top of the stack trace in the <code class="literal">dspace.log</code> file) usually has a concise and helpful explanation of what went wrong. Don't forget to stop and restart the servlet container before testing your fix to a bug.</p></div></div><div class="section" title="14.5. Configuring the File Upload step"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N188F3"></a>14.5. <a name="docbook-submission.html-uploadStep"></a>Configuring the File Upload step</h2></div></div><div></div></div><p>The <span class="emphasis"><em>Upload</em></span> step in the DSpace submission process has two configuration options which can be set with your <code class="literal">[dspace]/config/dspace.cfg</code> configuration file. They are as follows:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p><code class="literal">upload.max</code> - The maximum size of a file (in bytes) that can be uploaded from the JSPUI (not applicable for the XMLUI). It defaults to 536870912 bytes (512MB). You may set this to -1 to disable any file size limitation. </p><div class="itemizedlist"><ul class="itemizedlist" type="circle"><li class="listitem"><p><span class="emphasis"><em>Note:</em></span> Increasing this value or setting to -1 does <span class="bold"><strong>not</strong></span> guarantee that DSpace will be able to successfully upload larger files via the web, as large uploads depend on many other factors including bandwidth, web server settings, internet connection speed, etc.</p></li></ul></div></li><li class="listitem"><p><code class="literal">webui.submit.upload.required</code> - Whether or not all users are <span class="emphasis"><em>required</em></span> to upload a file when they submit an item to DSpace. It defaults to 'true'. When set to 'false' users will see an option to skip the upload step when they submit a new item.</p></li></ul></div></div><div class="section" title="14.6. Creating new Submission Steps"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1891C"></a>14.6. <a name="docbook-submission.html-createStep"></a>Creating new Submission Steps</h2></div></div><div></div></div><p>First, a brief warning: <span class="emphasis"><em>Creating a new Submission Step requires some Java knowledge, and is therefore recommended to be undertaken by a Java programmer whenever possible</em></span></p><p>That being said, at a higher level, creating a new Submission Step requires the following (in this relative order):</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> (<span class="bold"><strong>Required</strong></span>) Create a new Step Processing class </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> This class <span class="bold"><strong>must</strong></span> extend the abstract <code class="literal">org.dspace.submit.AbstractProcessingStep</code> class and implement all methods defined by that abstract class.</p></li><li class="listitem"><p> This class should be built in such a way that it can process the input gathered from <span class="emphasis"><em>either</em></span> the XMLUI or JSPUI interface.</p></li></ul></div></li><li class="listitem"><p> (<span class="emphasis"><em>For steps using JSPUI</em></span>) Create the JSPs to display the user interface. Create a new JSPUI "binding" class to initialize and call these JSPs.</p></li><li class="listitem"><p>
|
||
<div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> Your JSPUI "binding" class must extend the abstract class <code class="literal">org.dspace.app.webui.submit.JSPStep</code> and implement all methods defined there. It's recommended to use one of the classes in <code class="literal">org.dspace.app.webui.submit.step.*</code> as a reference.</p></li><li class="listitem"><p> Any JSPs created should be loaded by calling the showJSP() method of the <code class="literal">org.dspace.app.webui.submit.JSPStepManager</code> class</p></li><li class="listitem"><p> If this step gathers information to be reviewed, you must also create a Review JSP which will display a read-only view of all data gathered during this step. The path to this JSP must be returned by your getReviewJSP() method. You will find examples of Review JSPs (named similar to <code class="literal">review-[step].jsp</code>) in the JSP <code class="literal">submit/</code> directory.</p></li></ul></div>
|
||
</p></li><li class="listitem"><p> (<span class="emphasis"><em>For steps using XMLUI</em></span>) Create an XMLUI "binding" Step Transformer which will generate the DRI XML which Manakin requires. </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> The Step Transformer must extend and implement all necessary methods within the abstract class <code class="literal">org.dspace.app.xmlui.submission.AbstractSubmissionStep</code></p></li><li class="listitem"><p> It is useful to use the existing classes in <code class="literal">org.dspace.app.xmlui.submission.submit.*</code> as references</p></li></ul></div></li><li class="listitem"><p> (<span class="bold"><strong>Required</strong></span>) Add a valid Step Definition to the <code class="literal">item-submission.xml</code> configuration file. </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> This may also require that you add an I18N (Internationalization) key for this step's <code class="literal">heading</code>. See the sections on <a class="link" href="ch05.html#docbook-configure.html-multilingual">Configuring Multilingual Support for JSPUI</a> or <a class="link" href="ch07.html#docbook-xmlui.html-multilingual">Configuring Multilingual Support for XMLUI</a> for more details.</p></li><li class="listitem"><p> For more information on <code class="literal"><step></code> definitions within the <code class="literal">item-submission.xml</code>, see the section above on <a name="docbook-submission.html--stepDefinitions.1"></a>Defining Steps (<code class="literal"><step></code>) within the <code class="literal">item-submission.xml</code>.</p></li></ul></div></li></ol></div><div class="section" title="14.6.1. Creating a Non-Interactive Step"><div class="titlepage"><div><div><h3 class="title"><a name="N189B2"></a>14.6.1. <a name="docbook-submission.html-createStep.1"></a>Creating a Non-Interactive Step</h3></div></div><div></div></div><p>Non-interactive steps are ones that have no user interface and only perform backend processing. You may find a need to create non-interactive steps which perform further processing of previously entered information.</p><p>To create a non-interactive step, do the following:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> Create the required Step Processing class, which extends the abstract <code class="literal">org.dspace.submit.AbstractProcessingStep</code> class. In this class add any processing which this step will perform.</p></li><li class="listitem"><p> Add your non-interactive step to your <code class="literal">item-submission.xml</code> at the place where you wish this step to be called during the submission process. For example, if you want it to be called <span class="emphasis"><em>immediately after</em></span> the existing 'Upload File' step, then place its configuration immediately after the configuration for that 'Upload File' step. The configuration should look similar to the following: </p><pre class="screen">
|
||
|
||
<code class="literal"> <step>
|
||
<processing-class>org.dspace.submit.step.MyNonInteractveStep</processi
|
||
/processing-class> <workflow-editable>false</workflow-editable>
|
||
</step></code>
|
||
|
||
</pre></li></ol></div><p>Note: Non-interactive steps will not appear in the Progress Bar! Therefore, your submitters will not even know they are there. However, because they are not visible to your users, you should make sure that your non-interactive step does not take a large amount of time to finish its processing and return control to the next step (otherwise there will be a visible time delay in the user interface).</p></div></div></div><HR><p class="copyright">Copyright <20> 2002-2010
|
||
<a class="ulink" href="http://www.duraspace.org/" target="_top">DuraSpace</a>
|
||
</p><div class="legalnotice" title="Legal Notice"><a name="N1001D"></a><p>
|
||
<a class="ulink" href="http://creativecommons.org/licenses/by/3.0/us/" target="_top">
|
||
<span class="inlinemediaobject"><img src="http://i.creativecommons.org/l/by/3.0/us/88x31.png"></span>
|
||
</a>
|
||
</p><p>Licensed under a Creative Commons Attribution 3.0 United States License</p></div><div class="navfooter"><hr><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ch13.html">Prev</a> </td><td align="center" width="20%"> </td><td align="right" width="40%"> <a accesskey="n" href="ch15.html">Next</a></td></tr><tr><td valign="top" align="left" width="40%">Chapter 13. DSpace System Documentation: Business Logic Layer </td><td align="center" width="20%"><a accesskey="h" href="index.html">Home</a></td><td valign="top" align="right" width="40%"> Chapter 15. DSpace System Documentation: DRI Schema Reference</td></tr></table></div></body></html> |