mirror of
https://github.com/DSpace/DSpace.git
synced 2025-10-18 15:33:09 +00:00
Rename the html and pdf build script to be move obvious. Incorporate
1.5.2 documentation notes from Graham Triggs, Mark Diggory, Larry Stone. Regenerate the html and pdf. git-svn-id: http://scm.dspace.org/svn/repo/branches/dspace-1_5_x@3679 9c30dcfa-912a-0410-8fc2-9e0234be79fd
This commit is contained in:
Brad McLean
@@ -1,4 +1,4 @@
|
|||||||
The reference version of the documentation is now contained in the
|
The definitive/reference version of the documentation is now contained in the
|
||||||
docbook/ subdirectory.
|
docbook/ subdirectory.
|
||||||
|
|
||||||
This version generates the contents of the pdf/ and html/ subdirectories.
|
This version generates the contents of the pdf/ and html/ subdirectories.
|
||||||
@@ -9,7 +9,10 @@ html.legacy/.
|
|||||||
Any additions or edits should be done to the files in docbook/.
|
Any additions or edits should be done to the files in docbook/.
|
||||||
|
|
||||||
The script that can handle conversion is in convert2db.sh, and it
|
The script that can handle conversion is in convert2db.sh, and it
|
||||||
uses the wrapscreen.py script.
|
uses the wrapscreen.py script. Run this script to generate new .html
|
||||||
|
and .pdf documentation. Since these files, in html/ and pdf/ are
|
||||||
|
currently checked in to svn, this generates a fair amount of changes
|
||||||
|
to be committed.
|
||||||
|
|
||||||
In the near future, the legacy html will be removed, as will be the pdf
|
In the near future, the legacy html will be removed, as will be the pdf
|
||||||
and html directories. The conversion scripts will be integrated into
|
and html directories. The conversion scripts will be integrated into
|
||||||
|
|||||||
@@ -913,6 +913,7 @@ dsrun org.dspace.app.itemimport.ItemImport -a -e joe@user.com -c
|
|||||||
<para>The experimental (incomplete) METS export tool writes DSpace items to a filesystem with the metadata held in a more standard format based on METS.</para>
|
<para>The experimental (incomplete) METS export tool writes DSpace items to a filesystem with the metadata held in a more standard format based on METS.</para>
|
||||||
<section remap="h3">
|
<section remap="h3">
|
||||||
<title>The Export Tool</title>
|
<title>The Export Tool</title>
|
||||||
|
<para>This tool is obsolete, and does not export a complete AIP. It's use is strongly deprecated.</para>
|
||||||
<para>The METS export tool is invoked via the command line like this:</para>
|
<para>The METS export tool is invoked via the command line like this:</para>
|
||||||
<screen>
|
<screen>
|
||||||
<emphasis> [dspace]</emphasis>/bin/dsrun org.dspace.app.mets.METSExport
|
<emphasis> [dspace]</emphasis>/bin/dsrun org.dspace.app.mets.METSExport
|
||||||
@@ -937,6 +938,7 @@ dsrun org.dspace.app.itemimport.ItemImport -a -e joe@user.com -c
|
|||||||
</section>
|
</section>
|
||||||
<section remap="h3">
|
<section remap="h3">
|
||||||
<title>The AIP Format</title>
|
<title>The AIP Format</title>
|
||||||
|
<para>Note that this tool is deprecated, and the output format is not a true AIP</para>
|
||||||
<para>Each exported item is written to a separate directory, created under the base directory specified in the command-line arguments, or in the current directory if <literal>--destination</literal> is omitted. The name of each directory is the Handle, URL-encoded so that the directory name is 'legal'.</para>
|
<para>Each exported item is written to a separate directory, created under the base directory specified in the command-line arguments, or in the current directory if <literal>--destination</literal> is omitted. The name of each directory is the Handle, URL-encoded so that the directory name is 'legal'.</para>
|
||||||
<para>Within each item directory is a <literal>mets.xml</literal> file which contains the METS-encoded metadata for the item. Bitstreams in the item are also stored in the directory. Their filenames are their MD5 checksums, firstly for easy integrity checking, and also to avoid any problems with 'special characters' in the filenames that were legal on the original filing system they came from but are illegal in the server filing system. The <literal>mets.xml</literal> file includes XLink pointers to these bitstream files.</para>
|
<para>Within each item directory is a <literal>mets.xml</literal> file which contains the METS-encoded metadata for the item. Bitstreams in the item are also stored in the directory. Their filenames are their MD5 checksums, firstly for easy integrity checking, and also to avoid any problems with 'special characters' in the filenames that were legal on the original filing system they came from but are illegal in the server filing system. The <literal>mets.xml</literal> file includes XLink pointers to these bitstream files.</para>
|
||||||
<para>An example AIP might look like this:</para>
|
<para>An example AIP might look like this:</para>
|
||||||
|
|||||||
@@ -1318,140 +1318,6 @@ SELECT item_id FROM ItemsByTitle ORDER BY sort_title OFFSET 40 LIMIT
|
|||||||
<para>There are two main drawbacks to this: Firstly, <literal>LIMIT</literal> and <literal>OFFSET</literal> are PostgreSQL-specific keywords. Secondly, the database is still actually performing dynamic sorting of the titles, so the browse code as it stands will not scale particularly well. The code does cache <literal>BrowseInfo</literal> objects, so that common browse operations are performed quickly, but this is not an ideal solution.</para>
|
<para>There are two main drawbacks to this: Firstly, <literal>LIMIT</literal> and <literal>OFFSET</literal> are PostgreSQL-specific keywords. Secondly, the database is still actually performing dynamic sorting of the titles, so the browse code as it stands will not scale particularly well. The code does cache <literal>BrowseInfo</literal> objects, so that common browse operations are performed quickly, but this is not an ideal solution.</para>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section remap="h2">
|
|
||||||
<title><anchor id="docbook-business.html-history" xreflabel="History Recorder"/>History Recorder</title>
|
|
||||||
<para>The purpose of the history subsystem is to capture a time-based record of significant changes in DSpace, in a manner suitable for later refactoring or repurposing. Note that the history data is not expected to provide current information about the archive; it simply records what has happened in the past.</para>
|
|
||||||
<para>The <ulink url="http://www.metadata.net/harmony/">Harmony project</ulink> describes a simple and powerful approach for modeling temporal data. The DSpace history framework adopts this model. The Harmony model is used by the serialization mechanism (and ultimately by agents who interpret the serializations); users of the History API need not be aware of it. The content management API handles invocations of the history system. Users of the DSpace public API do not generally need to use the history API.</para>
|
|
||||||
<para>When anything of archival interest occurs in DSpace, the <literal>saveHistory</literal> method of the <literal>HistoryManager</literal> is invoked. The parameters contains a reference to anything of archival interest. Upon reception of the object, it serializes the state of all archive objects referred to by it, and creates Harmony-style objects and associations to describe the relationships between the objects. (A simple example is given below). Note that each archive object must have a unique identifier to allow linkage between discrete events; this is discussed under "Unique IDs" below.</para>
|
|
||||||
<para>The serializations (including the Harmony objects and associations) are persisted as files in the <literal>/dspace/history</literal> (or other configured) directory. The <literal>history</literal> and <literal>historystate</literal> tables contain simple indicies into the serializations in the file system.</para>
|
|
||||||
<section remap="h3">
|
|
||||||
<title>Archival Events</title>
|
|
||||||
<para>The following events are significant enough to warrant history records:</para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> Communities </para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> create/modify/delete</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> add/remove Collection to/from Community</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> Collections </para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> create/modify/delete</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> add/remove Item to/from Collection</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> Items </para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> create/modify/delete</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> assign Handle to Item</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> modify Item contents (Bundles, Bitstreams, metadata fields, etc)</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> EPerson </para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> create/modify/delete</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> Workflow </para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> Workflow completed</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section remap="h3">
|
|
||||||
<title>Serializations</title>
|
|
||||||
<para>The serialization of an archival object consists of:</para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> Its instance fields (ie, non-static, non-transient fields)</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> The serializations of associated objects (or references to these serializations).</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section remap="h3">
|
|
||||||
<title>Unique Ids</title>
|
|
||||||
<para>To be able to trace the history of an object, it is essential that the object have a unique identifier. Since not all objects in the system have Handles, the unique identifiers are only weakly tied to the Handle system. Instead, the identifier consists of:</para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> an identifer for the project</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> a site id (using the handle prefix)</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> an RDBMS-based id for objects</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</section>
|
|
||||||
<section remap="h3">
|
|
||||||
<title>Storage</title>
|
|
||||||
<para>When an archive object is serialized, an object ID and MD5 checksum are recorded. When another object is serialized, the checksum for the serialization is matched against existing checksums for that object. If the checksum already exists, the object is not stored; a reference to the object is used instead. Note that since none of the serializations are deleted, reference counting is unnecessary.</para>
|
|
||||||
<para>The history data is not initially stored in a queryable form. Two simple RDBMS tables give basic indications of what is stored, and where. The <literal>history</literal> table is an index of serializations with checksums and dates. The <literal>history_id</literal> column corresponds to the file in which a serialization is stored. For example, if the history ID is 123456, it will be stored in the file:</para>
|
|
||||||
<screen>
|
|
||||||
/dspace/history/00/12/34/123456
|
|
||||||
</screen>
|
|
||||||
<para>The table also contains the date the serialization was written and the MD5 checksum of the serialization.</para>
|
|
||||||
<para>The <literal>historystate</literal> table is supposed to indicate the most recent serialization of any given object.</para>
|
|
||||||
</section>
|
|
||||||
<section remap="h3">
|
|
||||||
<title>Example</title>
|
|
||||||
<para>An item is submitted to a collection via bulk upload. When (and if) the item is eventually added to the collection, the history method is called, with references to the item, its collection, the e-person who performed the bulk upload, and some indication of the fact that it was submitted via a bulk upload.</para>
|
|
||||||
<para>When called, the HistoryManager does the following: It creates the following new resources (all with unique ids):</para>
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para> An event</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> A state</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para> An action</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
<para>It also generates the following relationships:</para>
|
|
||||||
<screen>
|
|
||||||
event --atTime--> time
|
|
||||||
event --hasOutput--> state
|
|
||||||
Item --inState--> state
|
|
||||||
state --contains--> Item
|
|
||||||
action --creates--> Item
|
|
||||||
event --hasAction--> action
|
|
||||||
action --usesTool--> DSpace Upload
|
|
||||||
action --hasAgent--> User
|
|
||||||
</screen>
|
|
||||||
<para>The history component serializes the state of all archival objects involved (in this case, the item, the e-person, and the collection). It creates entries in the history database tables which associate the archival objects with the generated serializations.</para>
|
|
||||||
</section>
|
|
||||||
<section remap="h3">
|
|
||||||
<title>Caveats</title>
|
|
||||||
<para>This history system is a largely untested experiment. It also needs further documentation. There have been no serious efforts to determine whether the information written by the history system, either to files or the database tables, is accurate. In particular, the <literal>historystate</literal> table does not seem to be correctly written.</para>
|
|
||||||
</section>
|
|
||||||
</section>
|
|
||||||
<section remap="h2">
|
<section remap="h2">
|
||||||
<title><anchor id="docbook-business.html-checker" xreflabel="Checksum checker"/>Checksum checker</title>
|
<title><anchor id="docbook-business.html-checker" xreflabel="Checksum checker"/>Checksum checker</title>
|
||||||
<para>The architecture of the checker is documented in the package javadocs, run <literal>cd [dspace-source]/dspace;mvn javadoc:javadoc</literal>, and look in <literal>[dspace-source]dspace-api/target/site/apidocs/index.html</literal>.</para>
|
<para>The architecture of the checker is documented in the package javadocs, run <literal>cd [dspace-source]/dspace;mvn javadoc:javadoc</literal>, and look in <literal>[dspace-source]dspace-api/target/site/apidocs/index.html</literal>.</para>
|
||||||
|
|||||||
@@ -35,7 +35,7 @@ property.name = property value
|
|||||||
property.name = word1 ${other.property.name} more words
|
property.name = word1 ${other.property.name} more words
|
||||||
property2.name = ${dspace.dir}/rest/of/path
|
property2.name = ${dspace.dir}/rest/of/path
|
||||||
</screen>
|
</screen>
|
||||||
<para> Whenever you edit dspace.cfg in [dspace-source]/dspace/config/, you should then run 'ant init_configs' in the directory [dspace-source]/dspace/target/dspace-1.5.0-build.dir so that any changes you may have made are reflected in the configuration files of other applications, for example Apache. You may then need to restart those applications, depending on what you changed. <table frame="none">
|
<para> Whenever you edit dspace.cfg in [dspace-source]/dspace/config/, you should then run 'ant init_configs' in the directory [dspace-source]/dspace/target/dspace-1.5.2-build.dir so that any changes you may have made are reflected in the configuration files of other applications, for example Apache. You may then need to restart those applications, depending on what you changed. <table frame="none">
|
||||||
<title>dspace.cfg Main Properties (Not Complete)</title>
|
<title>dspace.cfg Main Properties (Not Complete)</title>
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
<colspec colname="c1" colwidth="33*"/>
|
<colspec colname="c1" colwidth="33*"/>
|
||||||
|
|||||||
@@ -340,7 +340,7 @@ Manakin)"/>Contents of XMLUI Web Application (aka Manakin)</title>
|
|||||||
</para>
|
</para>
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
<para>Main DSpace log file. This is where the DSpace code writes a simple log of events and errors that occur within the DSpace code. You can control the verbosity of this by editing the <literal>[dspace-source]/config/templates/log4j.properties</literal> file and then running "ant init_configs". [dspace]/bin/install-configs in [dspace-sorce]/dspace/target/dspace-1.5.0-build/.</para>
|
<para>Main DSpace log file. This is where the DSpace code writes a simple log of events and errors that occur within the DSpace code. You can control the verbosity of this by editing the <literal>[dspace-source]/config/templates/log4j.properties</literal> file and then running "ant init_configs". [dspace]/bin/install-configs in [dspace-source]/dspace/target/dspace-1.5.2-build/.</para>
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
|
|||||||
@@ -251,7 +251,7 @@ DSpace in one of two ways:"/>Items can be removed from DSpace in one of two ways
|
|||||||
</section>
|
</section>
|
||||||
<section remap="h2">
|
<section remap="h2">
|
||||||
<title><anchor id="docbook-functional.html-auth" xreflabel="Authorization"/>Authorization</title>
|
<title><anchor id="docbook-functional.html-auth" xreflabel="Authorization"/>Authorization</title>
|
||||||
<para>DSpace's authorization system is based on associating actions with objects and the lists of EPeople who can perform them. The associations are called Resource Policies, and the lists of EPeople are called Groups. There are two special groups: 'administrators', who can do anything in a site, and 'anonymous', which is a list that contains all users. Assigning a policy for an action on an object to anonymous means giving everyone permission to do that action. (For example, most objects in DSpace sites have a policy of 'anonymous' READ.) Permissions must be explicit - lack of an explicit permission results in the default policy of 'deny'. Permissions also do not 'commute'; for example, if an e-person has READ permission on an item, they might not necessarily have READ permission on the bundles and bitstreams in that item. Currently Collections, Communities and Items are discoverable in the browse and search systems regardless of READ authorization.</para>
|
<para>DSpace's authorization system is based on associating actions with objects and the lists of EPeople who can perform them. The associations are called Resource Policies, and the lists of EPeople are called Groups. There are two special groups: 'Administrators', who can do anything in a site, and 'Anonymous', which is a list that contains all users. Assigning a policy for an action on an object to anonymous means giving everyone permission to do that action. (For example, most objects in DSpace sites have a policy of 'anonymous' READ.) Permissions must be explicit - lack of an explicit permission results in the default policy of 'deny'. Permissions also do not 'commute'; for example, if an e-person has READ permission on an item, they might not necessarily have READ permission on the bundles and bitstreams in that item. Currently Collections, Communities and Items are discoverable in the browse and search systems regardless of READ authorization.</para>
|
||||||
<para>The following actions are possible:</para>
|
<para>The following actions are possible:</para>
|
||||||
<para>
|
<para>
|
||||||
<emphasis role="bold">Community</emphasis>
|
<emphasis role="bold">Community</emphasis>
|
||||||
@@ -301,7 +301,8 @@ DSpace in one of two ways:"/>Items can be removed from DSpace in one of two ways
|
|||||||
<para>DEFAULT_BITSTREAM_READ</para>
|
<para>DEFAULT_BITSTREAM_READ</para>
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
<para>inherited as READ by bitstreams of all submitted items</para>
|
<para>inherited as READ by Bitstreams of all submitted items. Note: only affects
|
||||||
|
Bitstreams of an item at the time it is initially submitted. If a Bitstream is added later, it does _not_ get the same default read policy.</para>
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
@@ -413,7 +414,7 @@ Workflow"/>Ingest Process and Workflow</title>
|
|||||||
<para>DSpace Ingest Process</para>
|
<para>DSpace Ingest Process</para>
|
||||||
<para>The batch item importer is an application, which turns an external SIP (an XML metadata document with some content files) into an "in progress submission" object. The Web submission UI is similarly used by an end-user to assemble an "in progress submission" object.</para>
|
<para>The batch item importer is an application, which turns an external SIP (an XML metadata document with some content files) into an "in progress submission" object. The Web submission UI is similarly used by an end-user to assemble an "in progress submission" object.</para>
|
||||||
<para>Depending on the policy of the collection to which the submission in targeted, a workflow process may be started. This typically allows one or more human reviewers or 'gatekeepers' to check over the submission and ensure it is suitable for inclusion in the collection.</para>
|
<para>Depending on the policy of the collection to which the submission in targeted, a workflow process may be started. This typically allows one or more human reviewers or 'gatekeepers' to check over the submission and ensure it is suitable for inclusion in the collection.</para>
|
||||||
<para>When the Batch Ingester or Web Submit UI completes the InProgressSubmission object, and invokes the next stage of ingest (be that workflow or item installation), a provenance message is added to the Dublin Core which includes the filenames and checksums of the content of the submission. Likewise, each time a workflow changes state (e.g. a reviewer accepts the submission), a similar provenance statement is added. This allows us to track how the item has changed since a user submitted it. (The <link linkend="docbook-functional.html-history">History system</link> is also invoked, but provenance is easier for us to access at the moment.)</para>
|
<para>When the Batch Ingester or Web Submit UI completes the InProgressSubmission object, and invokes the next stage of ingest (be that workflow or item installation), a provenance message is added to the Dublin Core which includes the filenames and checksums of the content of the submission. Likewise, each time a workflow changes state (e.g. a reviewer accepts the submission), a similar provenance statement is added. This allows us to track how the item has changed since a user submitted it. </para>
|
||||||
<para>Once any workflow process is successfully and positively completed, the InProgressSubmission object is consumed by an "item installer", that converts the InProgressSubmission into a fully blown archived item in DSpace. The item installer:</para>
|
<para>Once any workflow process is successfully and positively completed, the InProgressSubmission object is consumed by an "item installer", that converts the InProgressSubmission into a fully blown archived item in DSpace. The item installer:</para>
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
@@ -638,11 +639,6 @@ Support"/>Creative Commons Support</title>
|
|||||||
<title><anchor id="docbook-functional.html-subscriptions" xreflabel="Subscriptions"/>Subscriptions</title>
|
<title><anchor id="docbook-functional.html-subscriptions" xreflabel="Subscriptions"/>Subscriptions</title>
|
||||||
<para>As <link linkend="docbook-functional.html-epeople">noted above</link>, end-users (e-people) may 'subscribe' to collections in order to be alerted when new items appear in those collections. Each day, end-users who are subscribed to one or more collections will receive an e-mail giving brief details of all new items that appeared in any of those collections the previous day. If no new items appeared in any of the subscribed collections, no e-mail is sent. Users can unsubscribe themselves at any time. RSS feeds of new items are also available for collections and communities.</para>
|
<para>As <link linkend="docbook-functional.html-epeople">noted above</link>, end-users (e-people) may 'subscribe' to collections in order to be alerted when new items appear in those collections. Each day, end-users who are subscribed to one or more collections will receive an e-mail giving brief details of all new items that appeared in any of those collections the previous day. If no new items appeared in any of the subscribed collections, no e-mail is sent. Users can unsubscribe themselves at any time. RSS feeds of new items are also available for collections and communities.</para>
|
||||||
</section>
|
</section>
|
||||||
<section remap="h2">
|
|
||||||
<title><anchor id="docbook-functional.html-history" xreflabel="History"/>History</title>
|
|
||||||
<para>While provenance information in the form of prose is very useful, it is not easily programmatically manipulated. The History system captures a time-based record of significant changes in DSpace, in a manner suitable for later 'refactoring' or repurposing.</para>
|
|
||||||
<para>Currently, the History subsystem is explicitly invoked when significant events occur (e.g., DSpace accepts an item into the archive). The History subsystem then creates RDF data describing the current state of the object. The RDF data is modeled using <ulink url="http://www.metadata.net/harmony/">Harmony/ABC</ulink>, an ontology for describing temporal-based data, and stored in the file system. Some simple indices for unwinding the data are available.</para>
|
|
||||||
</section>
|
|
||||||
<section remap="h2">
|
<section remap="h2">
|
||||||
<title><anchor id="docbook-functional.html-importexport" xreflabel="Import and
|
<title><anchor id="docbook-functional.html-importexport" xreflabel="Import and
|
||||||
Export"/>Import and Export</title>
|
Export"/>Import and Export</title>
|
||||||
|
|||||||
@@ -7,7 +7,8 @@
|
|||||||
<title>General Improvements</title>
|
<title>General Improvements</title>
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para> TBD</para>
|
<para>The History System has been removed since DSpace 1.5. The <literal>[dspace]/history</literal> directory and it's contents can be completely removed if you so choose as it is non functional.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|||||||
@@ -2,6 +2,483 @@
|
|||||||
<chapter remap="h1">
|
<chapter remap="h1">
|
||||||
<title><anchor id="docbook-update.html"/>DSpace System Documentation: Updating a DSpace Installation</title>
|
<title><anchor id="docbook-update.html"/>DSpace System Documentation: Updating a DSpace Installation</title>
|
||||||
<para>This section describes how to update a DSpace installation from one version to the next. Details of the differences between the functionality of each version are given in the <link linkend="docbook-history.html">Version History</link> section.</para>
|
<para>This section describes how to update a DSpace installation from one version to the next. Details of the differences between the functionality of each version are given in the <link linkend="docbook-history.html">Version History</link> section.</para>
|
||||||
|
<section remap="h2">
|
||||||
|
<title><anchor id="docbook-update.html-15_152" xreflabel="Updating From 1.5 or 1.5.1 to 1.5.2"/>Updating From 1.5 or 1.5.1 to 1.5.2</title>
|
||||||
|
<para>This section needs review</para>
|
||||||
|
<para>The changes in DSpace 1.5.2 do not include any database schema upgrades, and the upgrade should be straightforward. </para>
|
||||||
|
<para>In the notes below <literal>[dspace]</literal> refers to the install directory for your existing DSpace installation, and <literal>[dspace-source]</literal> to the source directory for DSpace 1.5. Whenever you see these path references, be sure to replace them with the actual path names on your local system.</para>
|
||||||
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Backup your DSpace</emphasis> First and foremost, make a complete backup of your system, including:</para>
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para> A snapshot of the database</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para> The asset store (<literal>[dspace]/assetstore</literal> by default)</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para> Your configuration files and customizations to DSpace</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para> Your statistics scripts (<literal>[dspace]/bin/stat*</literal>) which contain customizable dates</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Download DSpace 1.5.2</emphasis> Get the new DSpace 1.5.2 source code either as a download from <ulink url="#">SourceForge</ulink> or check it out directly from the <ulink url="#">SVN code repository</ulink>. If you downloaded DSpace do not unpack it on top of your existing installation.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Build DSpace</emphasis> Run the following commands to compile DSpace.</para>
|
||||||
|
<screen>
|
||||||
|
cd [dspace-source]/dspace/
|
||||||
|
mvn package
|
||||||
|
</screen>
|
||||||
|
<para>You will find the result in <literal>[dspace-source]/dspace/target/dspace-1.5.2-build.dir/</literal>; inside this directory is the compiled binary distribution of DSpace.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Stop Tomcat</emphasis> Take down your servlet container, for Tomcat use the <literal>bin/shutdown.sh</literal> script.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Apply any customizations</emphasis> If you have made any local customizations to your DSpace installation they will need to be migrated over to the new DSpace. Commonly these modifications are made to "JSP" pages located inside the <literal>[dspace 1.4.2]/jsp/local</literal> directory. These should be moved <literal>[dspace-source]/dspace/modules/jspui/src/main/webapp/</literal> in the new build structure. See <link linkend="docbook-configure.html-jspui-jsp">Customizing the JSP Pages</link> for more information.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Update DSpace</emphasis> Update the DSpace installed directory with new code and libraries. Inside the <literal>[dspace-source]/dspace/target/dspace-1.5-build.dir/</literal> directory run:</para>
|
||||||
|
<screen>
|
||||||
|
cd [dspace-source]/dspace/target/dspace-1.5-build.dir/
|
||||||
|
ant -Dconfig=[dspace]/config/dspace.cfg update
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Update configuration files</emphasis> This ant target preserves existing files in <literal>[dspace]/config </literal> and will copy any new configuration files in place. If an existing file prevents copying the new file in place, the new file will have the suffix <literal>.new</literal>, for example <literal>[dspace]/local/dspace.cfg.new</literal>. Note: there is also a configuration option <literal>-Doverwrite=true</literal> which will instead copy the conflicting target files to *.old suffixes and overwrite target file then with the new file (essentially the opposite) this is beneficial for developers and those who use the <literal>[dspace-source]/dspace/config</literal> to maintain their changes.</para>
|
||||||
|
<screen>
|
||||||
|
cd [dspace-source]/dspace/target/dspace-1.5-build.dir/
|
||||||
|
ant -Dconfig=[dspace]/config/dspace.cfg update_configs
|
||||||
|
</screen>
|
||||||
|
<para>You must then verify that you've merged and differenced in the <literal>[dspace]/config/**/*.new</literal> files into your configuration.</para>
|
||||||
|
<para>Some of the new parameters you should look out for in dspace.cfg include: </para>
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>New option to restrict the expose of private items. The following needs to be added to dspace.cfg:</para>
|
||||||
|
<screen>
|
||||||
|
#### Restricted item visibility settings ###
|
||||||
|
# By default RSS feeds, OAI-PMH and subscription emails will include ALL items
|
||||||
|
# regardless of permissions set on them.
|
||||||
|
#
|
||||||
|
# If you wish to only expose items through these channels where the ANONYMOUS
|
||||||
|
# user is granted READ permission, then set the following options to false
|
||||||
|
#harvest.includerestricted.rss = true
|
||||||
|
#harvest.includerestricted.oai = true
|
||||||
|
#harvest.includerestricted.subscription = true
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para> Special groups for LDAP and password authentication. </para>
|
||||||
|
<screen>
|
||||||
|
##### Password users group #####
|
||||||
|
|
||||||
|
# If required, a group name can be given here, and all users who log in
|
||||||
|
# using the DSpace password system will automatically become members of
|
||||||
|
# this group. This is useful if you want a group made up of all internal
|
||||||
|
# authenticated users.
|
||||||
|
#password.login.specialgroup = group-name
|
||||||
|
|
||||||
|
##### LDAP users group #####
|
||||||
|
|
||||||
|
# If required, a group name can be given here, and all users who log in
|
||||||
|
# to LDAP will automatically become members of this group. This is useful
|
||||||
|
# if you want a group made up of all internal authenticated users.
|
||||||
|
#ldap.login.specialgroup = group-name
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>new option for case insensitivity in browse tables. </para>
|
||||||
|
<screen>
|
||||||
|
# By default, the display of metadata in the browse indexes is case sensitive
|
||||||
|
# So, you will get separate entries for the terms
|
||||||
|
#
|
||||||
|
# Olive oil
|
||||||
|
# olive oil
|
||||||
|
#
|
||||||
|
# However, clicking through from either of these will result in the same set of items
|
||||||
|
# (ie. any item that contains either representation in the correct field).
|
||||||
|
#
|
||||||
|
# Uncommenting the option below will make the metadata items case-insensitive. This will
|
||||||
|
# result in a single entry in the example above. However the value displayed may be either 'Olive oil'
|
||||||
|
# or 'olive oil' - depending on what representation was present in the first item indexed.
|
||||||
|
#
|
||||||
|
# If you care about the display of the metadata in the browse index - well, you'll have to go and
|
||||||
|
# fix the metadata in your items.
|
||||||
|
#
|
||||||
|
# webui.browse.metadata.case-insensitive = true
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>New usage event handler for collecting statistics:</para>
|
||||||
|
<screen>
|
||||||
|
### Usage event settings ###
|
||||||
|
# The usage event handler to call. The default is the "passive" handler, which ignores events.
|
||||||
|
# plugin.single.org.dspace.app.statistics.AbstractUsageEvent = \
|
||||||
|
# org.dspace.app.statistics.PassiveUsageEvent
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>The location where sitemaps are stored is now configurable.</para>
|
||||||
|
<screen>
|
||||||
|
#### Sitemap settings #####
|
||||||
|
# the directory where the generated sitemaps are stored
|
||||||
|
sitemap.dir = ${dspace.dir}/sitemaps
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>MARC 21 ordering should now be used as default. Unless you have it set already, or you have it set to a different value, the following should be set:</para>
|
||||||
|
<screen>
|
||||||
|
plugin.named.org.dspace.sort.OrderFormatDelegate = org.dspace.sort.OrderFormatTitleMarc21=title
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Hierarchical LDAP support.</para>
|
||||||
|
<screen>
|
||||||
|
##### Hierarchical LDAP Settings #####
|
||||||
|
# If your users are spread out across a hierarchical tree on your
|
||||||
|
# LDAP server, you will need to use the following stackable authentication
|
||||||
|
# class:
|
||||||
|
# plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
|
||||||
|
# org.dspace.authenticate.LDAPHierarchicalAuthentication
|
||||||
|
#
|
||||||
|
# You can optionally specify the search scope. If anonymous access is not
|
||||||
|
# enabled on your LDAP server, you will need to specify the full DN and
|
||||||
|
# password of a user that is allowed to bind in order to search for the
|
||||||
|
# users.
|
||||||
|
|
||||||
|
# This is the search scope value for the LDAP search during
|
||||||
|
# autoregistering. This will depend on your LDAP server setup.
|
||||||
|
# This value must be one of the following integers corresponding
|
||||||
|
# to the following values:
|
||||||
|
# object scope : 0
|
||||||
|
# one level scope : 1
|
||||||
|
# subtree scope : 2
|
||||||
|
#ldap.search_scope = 2
|
||||||
|
|
||||||
|
# The full DN and password of a user allowed to connect to the LDAP server
|
||||||
|
# and search for the DN of the user trying to log in. If these are not specified,
|
||||||
|
# the initial bind will be performed anonymously.
|
||||||
|
#ldap.search.user = cn=admin,ou=people,o=myu.edu
|
||||||
|
#ldap.search.password = password
|
||||||
|
|
||||||
|
# If your LDAP server does not hold an email address for a user, you can use
|
||||||
|
# the following field to specify your email domain. This value is appended
|
||||||
|
# to the netid in order to make an email address. E.g. a netid of 'user' and
|
||||||
|
# ldap.netid_email_domain as '@example.com' would set the email of the user
|
||||||
|
# to be 'user@example.com
|
||||||
|
#ldap.netid_email_domain = @example.com
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Shibboleth authentication support.</para>
|
||||||
|
<screen>
|
||||||
|
#### Shibboleth Authentication Configuration Settings ####
|
||||||
|
# Check https://mams.melcoe.mq.edu.au/zope/mams/pubs/Installation/dspace15/view
|
||||||
|
# for installation detail.
|
||||||
|
#
|
||||||
|
# org.dspace.authenticate.ShibAuthentication
|
||||||
|
#
|
||||||
|
# DSpace requires email as user's credential. There are 2 ways of providing
|
||||||
|
# email to DSpace:
|
||||||
|
# 1) by explicitly specifying to the user which attribute (header)
|
||||||
|
# carries the email address.
|
||||||
|
# 2) by turning on the user-email-using-tomcat=true which means
|
||||||
|
# the software will try to acquire the user's email from Tomcat
|
||||||
|
# The first option takes PRECEDENCE when specified. Both options can
|
||||||
|
# be enabled to allow fallback.
|
||||||
|
|
||||||
|
# this option below specifies that the email comes from the mentioned header.
|
||||||
|
# The value is CASE-Sensitive.
|
||||||
|
authentication.shib.email-header = MAIL
|
||||||
|
|
||||||
|
# optional. Specify the header that carries user's first name
|
||||||
|
# this is going to be used for creation of new-user
|
||||||
|
authentication.shib.firstname-header = SHIB-EP-GIVENNAME
|
||||||
|
|
||||||
|
# optional. Specify the header that carries user's last name
|
||||||
|
# this is used for creation of new user
|
||||||
|
authentication.shib.lastname-header = SHIB-EP-SURNAME
|
||||||
|
|
||||||
|
# this option below forces the software to acquire the email from Tomcat.
|
||||||
|
authentication.shib.email-use-tomcat-remote-user = true
|
||||||
|
|
||||||
|
# should we allow new users to be registered automtically
|
||||||
|
# if the IdP provides sufficient info (and user not exists in DSpace)
|
||||||
|
authentication.shib.autoregister = true
|
||||||
|
|
||||||
|
# this header here specifies which attribute that is responsible
|
||||||
|
# for providing user's roles to DSpace. When not specified, it is
|
||||||
|
# defaulted to 'Shib-EP-UnscopedAffiliation'. The value is specified
|
||||||
|
# in AAP.xml (Shib 1.3.x) or attribute-filter.xml (Shib 2.x).
|
||||||
|
# The value is CASE-Sensitive. The values provided in this
|
||||||
|
# header are separated by semi-colon or comma.
|
||||||
|
# authentication.shib.role-header = Shib-EP-UnscopedAffiliation
|
||||||
|
|
||||||
|
# when user is fully authN on IdP but would not like to release
|
||||||
|
# his/her roles to DSpace (for privacy reason?), what should be
|
||||||
|
# the default roles be given to such users?
|
||||||
|
# The values are separated by semi-colon or comma
|
||||||
|
# authentication.shib.default-roles = Staff, Walk-ins
|
||||||
|
|
||||||
|
# The following mappings specify role mapping between IdP and Dspace.
|
||||||
|
# the left side of the entry is IdP's role (prefixed with
|
||||||
|
# "authentication.shib.role.") which will be mapped to
|
||||||
|
# the right entry from DSpace. DSpace's group as indicated on the
|
||||||
|
# right entry has to EXIST in DSpace, otherwise user will be identified
|
||||||
|
# as 'anonymous'. Multiple values on the right entry should be separated
|
||||||
|
# by comma. The values are CASE-Sensitive. Heuristic one-to-one mapping
|
||||||
|
# will be done when the IdP groups entry are not listed below (i.e.
|
||||||
|
# if "X" group in IdP is not specified here, then it will be mapped
|
||||||
|
# to "X" group in DSpace if it exists, otherwise it will be mapped
|
||||||
|
# to simply 'anonymous')
|
||||||
|
#
|
||||||
|
# Given sufficient demand, future release could support regex for the mapping
|
||||||
|
# special characters need to be escaped by \
|
||||||
|
authentication.shib.role.Senior\ Researcher = Researcher, Staff
|
||||||
|
authentication.shib.role.Librarian = Administrator
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>DOI and handle identifiers can now be rendered in the JSPUI.</para>
|
||||||
|
<screen>
|
||||||
|
# When using "resolver" in webui.itemdisplay to render identifiers as resolvable
|
||||||
|
# links, the base URL is taken from <code>webui.resolver.<n>.baseurl</code>
|
||||||
|
# where <code>webui.resolver.<n>.baseurl</code> matches the urn specified in the metadata value.
|
||||||
|
# The value is appended to the "baseurl" as is, so the baseurl need to end with slash almost in any case.
|
||||||
|
# If no urn is specified in the value it will be displayed as simple text.
|
||||||
|
#
|
||||||
|
#webui.resolver.1.urn = doi
|
||||||
|
#webui.resolver.1.baseurl = http://dx.doi.org/
|
||||||
|
#webui.resolver.2.urn = hdl
|
||||||
|
#webui.resolver.2.baseurl = http://hdl.handle.net/
|
||||||
|
#
|
||||||
|
# For the doi and hdl urn defaults values are provided, respectively http://dx.doi.org and
|
||||||
|
# http://hdl.handle.net are used.
|
||||||
|
#
|
||||||
|
# If a metadata value with style: "doi", "handle" or "resolver" matches a URL
|
||||||
|
# already, it is simply rendered as a link with no other manipulation.
|
||||||
|
</screen><para>
|
||||||
|
In configuration sections such as webui.itemdisplay.default, values can
|
||||||
|
be changed from (e.g.) metadata.dc.identifier.doi to
|
||||||
|
metadata.doi.dc.identifer.doi
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>The whole of the SWORD configuration has changed. The SWORD section must be removed and replaced with</para>
|
||||||
|
<screen>
|
||||||
|
#---------------------------------------------------------------#
|
||||||
|
#--------------SWORD SPECIFIC CONFIGURATIONS--------------------#
|
||||||
|
#---------------------------------------------------------------#
|
||||||
|
# These configs are only used by the SWORD interface #
|
||||||
|
#---------------------------------------------------------------#
|
||||||
|
|
||||||
|
# tell the SWORD METS implementation which package ingester to use
|
||||||
|
# to install deposited content. This should refer to one of the
|
||||||
|
# classes configured for:
|
||||||
|
#
|
||||||
|
# plugin.named.org.dspace.content.packager.PackageIngester
|
||||||
|
#
|
||||||
|
# The value of sword.mets-ingester.package-ingester tells the
|
||||||
|
# system which named plugin for this interface should be used
|
||||||
|
# to ingest SWORD METS packages
|
||||||
|
#
|
||||||
|
# The default is METS
|
||||||
|
#
|
||||||
|
# sword.mets-ingester.package-ingester = METS
|
||||||
|
|
||||||
|
# Define the metadata type EPDCX (EPrints DC XML)
|
||||||
|
# to be handled by the SWORD crosswalk configuration
|
||||||
|
#
|
||||||
|
mets.submission.crosswalk.EPDCX = SWORD
|
||||||
|
|
||||||
|
# define the stylesheet which will be used by the self-named
|
||||||
|
# XSLTIngestionCrosswalk class when asked to load the SWORD
|
||||||
|
# configuration (as specified above). This will use the
|
||||||
|
# specified stylesheet to crosswalk the incoming SWAP metadata
|
||||||
|
# to the DIM format for ingestion
|
||||||
|
#
|
||||||
|
crosswalk.submission.SWORD.stylesheet = crosswalks/sword-swap-ingest.xsl
|
||||||
|
|
||||||
|
# The base URL of the SWORD deposit. This is the URL from
|
||||||
|
# which DSpace will construct the deposit location urls for
|
||||||
|
# collections.
|
||||||
|
#
|
||||||
|
# The default is {dspace.url}/sword/deposit
|
||||||
|
#
|
||||||
|
# In the event that you are not deploying DSpace as the ROOT
|
||||||
|
# application in the servlet container, this will generate
|
||||||
|
# incorrect URLs, and you should override the functionality
|
||||||
|
# by specifying in full as below:
|
||||||
|
#
|
||||||
|
# sword.deposit.url = http://www.myu.ac.uk/sword/deposit
|
||||||
|
|
||||||
|
# The base URL of the SWORD service document. This is the
|
||||||
|
# URL from which DSpace will construct the service document
|
||||||
|
# location urls for the site, and for individual collections
|
||||||
|
#
|
||||||
|
# The default is {dspace.url}/sword/servicedocument
|
||||||
|
#
|
||||||
|
# In the event that you are not deploying DSpace as the ROOT
|
||||||
|
# application in the servlet container, this will generate
|
||||||
|
# incorrect URLs, and you should override the functionality
|
||||||
|
# by specifying in full as below:
|
||||||
|
#
|
||||||
|
# sword.servicedocument.url = http://www.myu.ac.uk/sword/servicedocument
|
||||||
|
|
||||||
|
# The base URL of the SWORD media links. This is the URL
|
||||||
|
# which DSpace will use to construct the media link urls
|
||||||
|
# for items which are deposited via sword
|
||||||
|
#
|
||||||
|
# The default is {dspace.url}/sword/media-link
|
||||||
|
#
|
||||||
|
# In the event that you are not deploying DSpace as the ROOT
|
||||||
|
# application in the servlet container, this will generate
|
||||||
|
# incorrect URLs, and you should override the functionality
|
||||||
|
# by specifying in full as below:
|
||||||
|
#
|
||||||
|
# sword.media-link.url = http://www.myu.ac.uk/sword/media-link
|
||||||
|
|
||||||
|
# The URL which identifies the sword software which provides
|
||||||
|
# the sword interface. This is the URL which DSpace will use
|
||||||
|
# to fill out the atom:generator element of its atom documents.
|
||||||
|
#
|
||||||
|
# The default is:
|
||||||
|
#
|
||||||
|
# http://www.dspace.org/ns/sword/1.3.1
|
||||||
|
#
|
||||||
|
# If you have modified your sword software, you should change
|
||||||
|
# this URI to identify your own version. If you are using the
|
||||||
|
# standard dspace-sword module you will not, in general, need
|
||||||
|
# to change this setting
|
||||||
|
#
|
||||||
|
# sword.generator.url = http://www.dspace.org/ns/sword/1.3.1
|
||||||
|
|
||||||
|
# The metadata field in which to store the updated date for
|
||||||
|
# items deposited via SWORD.
|
||||||
|
#
|
||||||
|
sword.updated.field = dc.date.updated
|
||||||
|
|
||||||
|
# The metadata field in which to store the value of the slug
|
||||||
|
# header if it is supplied
|
||||||
|
#
|
||||||
|
sword.slug.field = dc.identifier.slug
|
||||||
|
|
||||||
|
# the accept packaging properties, along with their associated
|
||||||
|
# quality values where appropriate.
|
||||||
|
#
|
||||||
|
# Global settings; these will be used on all DSpace collections
|
||||||
|
#
|
||||||
|
sword.accept-packaging.METSDSpaceSIP.identifier =
|
||||||
|
http://purl.org/net/sword-types/METSDSpaceSIP
|
||||||
|
sword.accept-packaging.METSDSpaceSIP.q = 1.0
|
||||||
|
|
||||||
|
# Collection Specific settings: these will be used on the collections
|
||||||
|
# with the given handles
|
||||||
|
#
|
||||||
|
# sword.accept-packaging.[handle].METSDSpaceSIP.identifier =
|
||||||
|
http://purl.org/net/sword-types/METSDSpaceSIP
|
||||||
|
# sword.accept-packaging.[handle].METSDSpaceSIP.q = 1.0
|
||||||
|
|
||||||
|
# Should the server offer up items in collections as sword deposit
|
||||||
|
# targets. This will be effected by placing a URI in the collection
|
||||||
|
# description which will list all the allowed items for the depositing
|
||||||
|
# user in that collection on request
|
||||||
|
#
|
||||||
|
# NOTE: this will require an implementation of deposit onto items, which
|
||||||
|
# will not be forthcoming for a short while
|
||||||
|
#
|
||||||
|
sword.expose-items = false
|
||||||
|
|
||||||
|
# Should the server offer as the default the list of all Communities
|
||||||
|
# to a Service Document request. If false, the server will offer
|
||||||
|
# the list of all collections, which is the default and recommended
|
||||||
|
# behaviour at this stage.
|
||||||
|
#
|
||||||
|
# NOTE: a service document for Communities will not offer any viable
|
||||||
|
# deposit targets, and the client will need to request the list of
|
||||||
|
# Collections in the target before deposit can continue
|
||||||
|
#
|
||||||
|
sword.expose-communities = false
|
||||||
|
|
||||||
|
# The maximum upload size of a package through the sword interface,
|
||||||
|
# in bytes
|
||||||
|
#
|
||||||
|
# This will be the combined size of all the files, the metadata and
|
||||||
|
# any manifest data. It is NOT the same as the maximum size set
|
||||||
|
# for an individual file upload through the user interface. If not
|
||||||
|
# set, or set to 0, the sword service will default to no limit.
|
||||||
|
#
|
||||||
|
sword.max-upload-size = 0
|
||||||
|
|
||||||
|
# Should DSpace store a copy of the original sword deposit package?
|
||||||
|
#
|
||||||
|
# NOTE: this will cause the deposit process to run slightly slower,
|
||||||
|
# and will accelerate the rate at which the repository consumes disk
|
||||||
|
# space. BUT, it will also mean that the deposited packages are
|
||||||
|
# recoverable in their original form. It is strongly recommended,
|
||||||
|
# therefore, to leave this option turned on
|
||||||
|
#
|
||||||
|
# When set to "true", this requires that the configuration option
|
||||||
|
# "upload.temp.dir" above is set to a valid location
|
||||||
|
#
|
||||||
|
sword.keep-original-package = true
|
||||||
|
|
||||||
|
# The bundle name that SWORD should store incoming packages under if
|
||||||
|
# sword.keep-original-package is set to true. The default is "SWORD"
|
||||||
|
# if not value is set
|
||||||
|
#
|
||||||
|
# sword.bundle.name = SWORD
|
||||||
|
|
||||||
|
# Should the server identify the sword version in deposit response?
|
||||||
|
#
|
||||||
|
# It is recommended to leave this enabled.
|
||||||
|
#
|
||||||
|
sword.identify-version = true
|
||||||
|
|
||||||
|
# Should we support mediated deposit via sword? Enabled, this will
|
||||||
|
# allow users to deposit content packages on behalf of other users.
|
||||||
|
#
|
||||||
|
# See the SWORD specification for a detailed explanation of deposit
|
||||||
|
# On-Behalf-Of another user
|
||||||
|
#
|
||||||
|
sword.on-behalf-of.enable = true
|
||||||
|
|
||||||
|
# Configure the plugins to process incoming packages. The form of this
|
||||||
|
# configuration is as per the Plugin Manager's Named Plugin documentation:
|
||||||
|
#
|
||||||
|
# plugin.named.[interface] = [implementation] = [package format identifier] \
|
||||||
|
#
|
||||||
|
# Package ingesters should implement the SWORDIngester interface, and
|
||||||
|
# will be loaded when a package of the format specified above in:
|
||||||
|
#
|
||||||
|
# sword.accept-packaging.[package format].identifier = [package format identifier]
|
||||||
|
#
|
||||||
|
# is received.
|
||||||
|
#
|
||||||
|
# In the event that this is a simple file deposit, with no package
|
||||||
|
# format, then the class named by "SimpleFileIngester" will be loaded
|
||||||
|
# and executed where appropriate. This case will only occur when a single
|
||||||
|
# file is being deposited into an existing DSpace Item
|
||||||
|
#
|
||||||
|
plugin.named.org.dspace.sword.SWORDIngester = \
|
||||||
|
org.dspace.sword.SWORDMETSIngester =
|
||||||
|
http://purl.org/net/sword-types/METSDSpaceSIP \
|
||||||
|
org.dspace.sword.SimpleFileIngester = SimpleFileIngester
|
||||||
|
</screen>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para><emphasis role="bold">Restart Tomcat</emphasis> Restart your servlet container, for Tomcat use the <literal>bin/startup.sh</literal> script.</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
</section>
|
||||||
|
|
||||||
<section remap="h2">
|
<section remap="h2">
|
||||||
<title><anchor id="docbook-update.html-142_15" xreflabel="Updating From 1.4.2 to 1.5"/>Updating From 1.4.2 to 1.5</title>
|
<title><anchor id="docbook-update.html-142_15" xreflabel="Updating From 1.4.2 to 1.5"/>Updating From 1.4.2 to 1.5</title>
|
||||||
<para>The changes in DSpace 1.5 are significant and wide spread involving database schema upgrades, code restructuring, completely new user and programatic interfaces, and new build system.</para>
|
<para>The changes in DSpace 1.5 are significant and wide spread involving database schema upgrades, code restructuring, completely new user and programatic interfaces, and new build system.</para>
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,6 +1,6 @@
|
|||||||
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 8. DSpace System Documentation: Architecture</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch07.html" title="Chapter 7. DSpace System Documentation: Directories and Files"><link rel="next" href="ch09.html" title="Chapter 9. DSpace System Documentation: Application Layer"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 8. DSpace System Documentation: Architecture</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch07.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch09.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N12E6E"></a>Chapter 8. <a name="docbook-architecture.html"></a>DSpace System Documentation: Architecture</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch08.html#N12E74">8.1. Overview</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12E74"></a>8.1. <a name="docbook-architecture.html-overview"></a>Overview</h2></div></div></div><p>The DSpace system is organized into three layers, each of which consists of a number of components.</p><p>
|
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 8. DSpace System Documentation: Architecture</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch07.html" title="Chapter 7. DSpace System Documentation: Directories and Files"><link rel="next" href="ch09.html" title="Chapter 9. DSpace System Documentation: Application Layer"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 8. DSpace System Documentation: Architecture</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch07.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch09.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N12F42"></a>Chapter 8. <a name="docbook-architecture.html"></a>DSpace System Documentation: Architecture</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch08.html#N12F48">8.1. Overview</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N12F48"></a>8.1. <a name="docbook-architecture.html-overview"></a>Overview</h2></div></div></div><p>The DSpace system is organized into three layers, each of which consists of a number of components.</p><p>
|
||||||
<span class="inlinemediaobject"><img src="image/architecture-600x450.gif" width="585"></span>
|
<span class="inlinemediaobject"><img src="image/architecture-600x450.gif" width="585"></span>
|
||||||
</p><p>DSpace System Architecture</p><p>The storage layer is responsible for physical storage of metadata and content. The business logic layer deals with managing the content of the archive, users of the archive (e-people), authorization, and workflow. The application layer contains components that communicate with the world outside of the individual DSpace installation, for example the Web user interface and the <a class="ulink" href="http://www.openarchives.org/" target="_top">Open Archives Initiative</a> protocol for metadata harvesting service.</p><p>Each layer only invokes the layer below it; the application layer may not used the storage layer directly, for example. Each component in the storage and business logic layers has a defined public API. The union of the APIs of those components are referred to as the Storage API (in the case of the storage layer) and the DSpace Public API (in the case of the business logic layer). These APIs are in-process Java classes, objects and methods.</p><p>It is important to note that each layer is <span class="emphasis"><em>trusted</em></span>. Although the logic for <span class="emphasis"><em>authorising actions</em></span> is in the business logic layer, the system relies on individual applications in the application layer to correctly and securely <span class="emphasis"><em>authenticate</em></span> e-people. If a 'hostile' or insecure application were allowed to invoke the Public API directly, it could very easily perform actions as any e-person in the system.</p><p>The reason for this design choice is that authentication methods will vary widely between different applications, so it makes sense to leave the logic and responsibility for that in these applications.</p><p>The source code is organized to cohere very strictly to this three-layer architecture. Also, only methods in a component's public API are given the <code class="literal">public</code> access level. This means that the Java compiler helps ensure that the source code conforms to the architecture.</p><div class="table"><a name="N12EA4"></a><p class="title"><b>Table 8.1. Source Code Packages</b></p><div class="table-contents"><table summary="Source Code Packages" border="0"><colgroup><col><col></colgroup><tbody><tr><td>
|
</p><p>DSpace System Architecture</p><p>The storage layer is responsible for physical storage of metadata and content. The business logic layer deals with managing the content of the archive, users of the archive (e-people), authorization, and workflow. The application layer contains components that communicate with the world outside of the individual DSpace installation, for example the Web user interface and the <a class="ulink" href="http://www.openarchives.org/" target="_top">Open Archives Initiative</a> protocol for metadata harvesting service.</p><p>Each layer only invokes the layer below it; the application layer may not used the storage layer directly, for example. Each component in the storage and business logic layers has a defined public API. The union of the APIs of those components are referred to as the Storage API (in the case of the storage layer) and the DSpace Public API (in the case of the business logic layer). These APIs are in-process Java classes, objects and methods.</p><p>It is important to note that each layer is <span class="emphasis"><em>trusted</em></span>. Although the logic for <span class="emphasis"><em>authorising actions</em></span> is in the business logic layer, the system relies on individual applications in the application layer to correctly and securely <span class="emphasis"><em>authenticate</em></span> e-people. If a 'hostile' or insecure application were allowed to invoke the Public API directly, it could very easily perform actions as any e-person in the system.</p><p>The reason for this design choice is that authentication methods will vary widely between different applications, so it makes sense to leave the logic and responsibility for that in these applications.</p><p>The source code is organized to cohere very strictly to this three-layer architecture. Also, only methods in a component's public API are given the <code class="literal">public</code> access level. This means that the Java compiler helps ensure that the source code conforms to the architecture.</p><div class="table"><a name="N12F78"></a><p class="title"><b>Table 8.1. Source Code Packages</b></p><div class="table-contents"><table summary="Source Code Packages" border="0"><colgroup><col><col></colgroup><tbody><tr><td>
|
||||||
<p>
|
<p>
|
||||||
<span class="bold"><strong>Packages within</strong></span>
|
<span class="bold"><strong>Packages within</strong></span>
|
||||||
</p>
|
</p>
|
||||||
@@ -56,7 +56,7 @@ mvn javadoc:javadoc
|
|||||||
</p></li><li><p>
|
</p></li><li><p>
|
||||||
<a class="link" href="ch10.html#docbook-business.html-browse">Browse API</a>
|
<a class="link" href="ch10.html#docbook-business.html-browse">Browse API</a>
|
||||||
</p></li><li><p>
|
</p></li><li><p>
|
||||||
<a class="link" href="ch10.html#docbook-business.html-history">History Recorder</a>
|
<a class="link" href="">History Recorder</a>
|
||||||
</p></li><li><p>
|
</p></li><li><p>
|
||||||
<a class="link" href="ch10.html#docbook-business.html-checker">Checksum Checker</a>
|
<a class="link" href="ch10.html#docbook-business.html-checker">Checksum Checker</a>
|
||||||
</p></li></ul></div>
|
</p></li></ul></div>
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,6 +1,6 @@
|
|||||||
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 11. Customizing and Configuring Submission User Interface</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch10.html" title="Chapter 10. DSpace System Documentation: Business Logic Layer"><link rel="next" href="ch12.html" title="Chapter 12. docbook/DRISchemaReference.html"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 11. Customizing and Configuring Submission User Interface</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch10.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch12.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N1467E"></a>Chapter 11. <a name="docbook-submission.html"></a>Customizing and Configuring Submission User Interface</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch11.html#N1468B">11.1. Understanding the Submission Configuration File</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N14698">11.1.1. The Structure of item-submission.xml</a></span></dt><dt><span class="section"><a href="ch11.html#N146C7">11.1.2. Defining Steps (<step>) within the item-submission.xml</a></span></dt></dl></dd><dt><span class="section"><a href="ch11.html#N147FB">11.2. Reordering/Removing Submission Steps</a></span></dt><dt><span class="section"><a href="ch11.html#N148A8">11.3. Assigning a custom Submission Process to a Collection</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N148FB">11.3.1. Getting A Collection's Handle</a></span></dt></dl></dd><dt><span class="section"><a href="ch11.html#N1491E">11.4. Custom Metadata-entry Pages for Submission</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N14922">11.4.1. Introduction</a></span></dt><dt><span class="section"><a href="ch11.html#N1494D">11.4.2. Describing Custom Metadata Forms</a></span></dt><dt><span class="section"><a href="ch11.html#N14970">11.4.3. The Structure of input-forms.xml</a></span></dt><dt><span class="section"><a href="ch11.html#N14BFE">11.4.4. Deploying Your Custom Forms</a></span></dt></dl></dd><dt><span class="section"><a href="ch11.html#N14C1B">11.5. Configuring the File Upload step</a></span></dt><dt><span class="section"><a href="ch11.html#N14C47">11.6. Creating new Submission Steps</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N14CE0">11.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><p>
|
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 11. Customizing and Configuring Submission User Interface</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch10.html" title="Chapter 10. DSpace System Documentation: Business Logic Layer"><link rel="next" href="ch12.html" title="Chapter 12. docbook/DRISchemaReference.html"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 11. Customizing and Configuring Submission User Interface</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch10.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch12.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N1469E"></a>Chapter 11. <a name="docbook-submission.html"></a>Customizing and Configuring Submission User Interface</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch11.html#N146AB">11.1. Understanding the Submission Configuration File</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N146B8">11.1.1. The Structure of item-submission.xml</a></span></dt><dt><span class="section"><a href="ch11.html#N146E7">11.1.2. Defining Steps (<step>) within the item-submission.xml</a></span></dt></dl></dd><dt><span class="section"><a href="ch11.html#N1481B">11.2. Reordering/Removing Submission Steps</a></span></dt><dt><span class="section"><a href="ch11.html#N148C8">11.3. Assigning a custom Submission Process to a Collection</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N1491B">11.3.1. Getting A Collection's Handle</a></span></dt></dl></dd><dt><span class="section"><a href="ch11.html#N1493E">11.4. Custom Metadata-entry Pages for Submission</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N14942">11.4.1. Introduction</a></span></dt><dt><span class="section"><a href="ch11.html#N1496D">11.4.2. Describing Custom Metadata Forms</a></span></dt><dt><span class="section"><a href="ch11.html#N14990">11.4.3. The Structure of input-forms.xml</a></span></dt><dt><span class="section"><a href="ch11.html#N14C1E">11.4.4. Deploying Your Custom Forms</a></span></dt></dl></dd><dt><span class="section"><a href="ch11.html#N14C3B">11.5. Configuring the File Upload step</a></span></dt><dt><span class="section"><a href="ch11.html#N14C67">11.6. Creating new Submission Steps</a></span></dt><dd><dl><dt><span class="section"><a href="ch11.html#N14D00">11.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><p>
|
||||||
<a name="docbook-submission.html-configurationFile"></a>
|
<a name="docbook-submission.html-configurationFile"></a>
|
||||||
</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1468B"></a>11.1. Understanding the Submission Configuration File</h2></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14698"></a>11.1.1. The Structure of <code class="literal">item-submission.xml</code></h3></div></div></div><pre class="screen">
|
</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N146AB"></a>11.1. Understanding the Submission Configuration File</h2></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N146B8"></a>11.1.1. The Structure of <code class="literal">item-submission.xml</code></h3></div></div></div><pre class="screen">
|
||||||
|
|
||||||
<code class="literal"> <item-submission> <!-- Where submission processes are
|
<code class="literal"> <item-submission> <!-- Where submission processes are
|
||||||
mapped to specific Collections --> <submission-map> <name-map
|
mapped to specific Collections --> <submission-map> <name-map
|
||||||
@@ -22,7 +22,7 @@
|
|||||||
<code class="literal">Select Collection -> Initial Questions -> Describe -> Upload -> Verify -> License -> Complete</code>
|
<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><p>
|
</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><p>
|
||||||
<a name="docbook-submission.html--stepDefinitions"></a>
|
<a name="docbook-submission.html--stepDefinitions"></a>
|
||||||
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N146C7"></a>11.1.2. Defining Steps (<code class="literal"><step></code>) within the <code class="literal">item-submission.xml</code></h3></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N146D8"></a>Where to place your <code class="literal"><step></code> definitions</h4></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 type="1"><li><p> Within the <code class="literal"><step-definitions></code> section </p><div class="itemizedlist"><ul type="disc"><li><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><p> For example: </p><pre class="screen">
|
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N146E7"></a>11.1.2. Defining Steps (<code class="literal"><step></code>) within the <code class="literal">item-submission.xml</code></h3></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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N146F8"></a>Where to place your <code class="literal"><step></code> definitions</h4></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 type="1"><li><p> Within the <code class="literal"><step-definitions></code> section </p><div class="itemizedlist"><ul type="disc"><li><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><p> For example: </p><pre class="screen">
|
||||||
|
|
||||||
<code class="literal"> <step-definitions> <step id="custom-step"> ...
|
<code class="literal"> <step-definitions> <step id="custom-step"> ...
|
||||||
</step> ... </step-definitions> </code>
|
</step> ... </step-definitions> </code>
|
||||||
@@ -32,7 +32,7 @@
|
|||||||
<code class="literal"> <submission-process> <step> ... </step>
|
<code class="literal"> <submission-process> <step> ... </step>
|
||||||
</submission-process></code>
|
</submission-process></code>
|
||||||
|
|
||||||
</pre></li></ul></div></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14734"></a>The ordering of <code class="literal"><step></code> definitions <span class="bold"><strong>matters</strong></span>!</h4></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="ch11.html#docbook-submission.html-stepStructure">Structure of the <step> Definition</a> below):</p><pre class="screen">
|
</pre></li></ul></div></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14754"></a>The ordering of <code class="literal"><step></code> definitions <span class="bold"><strong>matters</strong></span>!</h4></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="ch11.html#docbook-submission.html-stepStructure">Structure of the <step> Definition</a> below):</p><pre class="screen">
|
||||||
|
|
||||||
<code class="literal"> <submission-process> <!--Step 1 will be to Sign off on
|
<code class="literal"> <submission-process> <!--Step 1 will be to Sign off on
|
||||||
the License--> <step> <heading>submit.progressbar.license</heading>
|
the License--> <step> <heading>submit.progressbar.license</heading>
|
||||||
@@ -55,7 +55,7 @@ tialQuestionsStep</xmlui-binding>
|
|||||||
|
|
||||||
</pre><p>
|
</pre><p>
|
||||||
<a name="docbook-submission.html-stepStructure"></a>
|
<a name="docbook-submission.html-stepStructure"></a>
|
||||||
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14762"></a>Structure of the <step> Definition</h4></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">
|
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14782"></a>Structure of the <step> Definition</h4></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">
|
||||||
|
|
||||||
<code class="literal"> <step> <heading>submit.progressbar.describe</heading>
|
<code class="literal"> <step> <heading>submit.progressbar.describe</heading>
|
||||||
<processing-class>org.dspace.submit.step.DescribeStep</processing-clas
|
<processing-class>org.dspace.submit.step.DescribeStep</processing-clas
|
||||||
@@ -80,13 +80,13 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
<span class="bold"><strong>workflow-editable</strong></span>
|
<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><p>
|
</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><p>
|
||||||
<a name="docbook-submission.html-stepOrdering"></a>
|
<a name="docbook-submission.html-stepOrdering"></a>
|
||||||
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N147FB"></a>11.2. Reordering/Removing Submission Steps</h2></div></div></div><p>The removal of existing steps and reordering of existing steps is a relatively easy process!</p><p>
|
</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1481B"></a>11.2. Reordering/Removing Submission Steps</h2></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>
|
<span class="bold"><strong>Reordering steps</strong></span>
|
||||||
</p><div class="orderedlist"><ol type="1"><li><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><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 type="disc"><li><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><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>
|
</p><div class="orderedlist"><ol type="1"><li><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><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 type="disc"><li><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><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>
|
<span class="bold"><strong>Removing one or more steps</strong></span>
|
||||||
</p><div class="orderedlist"><ol type="1"><li><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><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 type="disc"><li><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><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><p>
|
</p><div class="orderedlist"><ol type="1"><li><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><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 type="disc"><li><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><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><p>
|
||||||
<a name="docbook-submission.html-collectionSubmission"></a>
|
<a name="docbook-submission.html-collectionSubmission"></a>
|
||||||
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N148A8"></a>11.3. Assigning a custom Submission Process to a Collection</h2></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="ch11.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">
|
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N148C8"></a>11.3. Assigning a custom Submission Process to a Collection</h2></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="ch11.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>
|
<submission-map>
|
||||||
<name-map collection-handle="<span class="bold"><strong> 12345.6789/42</strong></span>" submission-name="<span class="bold"><strong>
|
<name-map collection-handle="<span class="bold"><strong> 12345.6789/42</strong></span>" submission-name="<span class="bold"><strong>
|
||||||
custom</strong></span>" />
|
custom</strong></span>" />
|
||||||
@@ -98,12 +98,12 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
custom</strong></span>">
|
custom</strong></span>">
|
||||||
...
|
...
|
||||||
</submission-definitions>
|
</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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N148FB"></a>11.3.1. Getting A Collection's Handle</h3></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">
|
</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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1491B"></a>11.3.1. Getting A Collection's Handle</h3></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">
|
http://myhost.my.edu/dspace/handle/<span class="underline">
|
||||||
12345.6789/42</span>
|
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><p>
|
</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><p>
|
||||||
<a name="docbook-submission.html-metadataEntry"></a>
|
<a name="docbook-submission.html-metadataEntry"></a>
|
||||||
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1491E"></a>11.4. Custom Metadata-entry Pages for Submission</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14922"></a>11.4.1. Introduction</h3></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 type="disc"><li><p> The number of metadata-entry pages.</p></li><li><p> Which fields appear on each page, and their sequence.</p></li><li><p> Labels, prompts, and other text associated with each field.</p></li><li><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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1494D"></a>11.4.2. Describing Custom Metadata Forms</h3></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14970"></a>11.4.3. The Structure of <code class="literal">input-forms.xml</code></h3></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">
|
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N1493E"></a>11.4. Custom Metadata-entry Pages for Submission</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14942"></a>11.4.1. Introduction</h3></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 type="disc"><li><p> The number of metadata-entry pages.</p></li><li><p> Which fields appear on each page, and their sequence.</p></li><li><p> Labels, prompts, and other text associated with each field.</p></li><li><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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N1496D"></a>11.4.2. Describing Custom Metadata Forms</h3></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" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14990"></a>11.4.3. The Structure of <code class="literal">input-forms.xml</code></h3></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>
|
<input-forms>
|
||||||
|
|
||||||
<-- <span class="emphasis"><em> Map of Collections to Form Sets</em></span> -->
|
<-- <span class="emphasis"><em> Map of Collections to Form Sets</em></span> -->
|
||||||
@@ -127,7 +127,7 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
...
|
...
|
||||||
</form-value-pairs>
|
</form-value-pairs>
|
||||||
</input-forms>
|
</input-forms>
|
||||||
</pre><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14989"></a>Adding a Collection Map</h4></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">
|
</pre><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N149A9"></a>Adding a Collection Map</h4></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>
|
<form-map>
|
||||||
<name-map collection-handle="<span class="bold"><strong> 12345.6789/42</strong></span>" form-name="<span class="bold"><strong> TechRpt</strong></span>"
|
<name-map collection-handle="<span class="bold"><strong> 12345.6789/42</strong></span>" form-name="<span class="bold"><strong> TechRpt</strong></span>"
|
||||||
/>
|
/>
|
||||||
@@ -139,12 +139,12 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
TechRept</strong></span>">
|
TechRept</strong></span>">
|
||||||
...
|
...
|
||||||
</form-definitions>
|
</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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N149C2"></a>Getting A Collection's Handle</h5></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">
|
</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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N149E2"></a>Getting A Collection's Handle</h5></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">
|
http://myhost.my.edu/dspace/handle/<span class="underline">
|
||||||
12345.6789/42</span>
|
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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N149E0"></a>Adding a Form Set</h4></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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N149F6"></a>Forms and Pages</h5></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">
|
</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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14A00"></a>Adding a Form Set</h4></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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14A16"></a>Forms and Pages</h5></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">
|
<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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14A1F"></a>Composition of a Field</h5></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">
|
</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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14A3F"></a>Composition of a Field</h5></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="bold"><strong>dc-schema</strong></span>
|
||||||
<span class="emphasis"><em>(Required)</em></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></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">
|
||||||
@@ -173,7 +173,7 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
</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 type="disc"><li><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><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>
|
</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 type="disc"><li><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><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>
|
||||||
For example:</p><p>
|
For example:</p><p>
|
||||||
<code class="literal"><visibility>workflow</visibility></code>
|
<code class="literal"><visibility>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="">Configuring Controlled Vocabularies</a> section.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14B5F"></a>Automatically Elided Fields</h5></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 type="1"><li><p>
|
</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="">Configuring Controlled Vocabularies</a> section.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14B7F"></a>Automatically Elided Fields</h5></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 type="1"><li><p>
|
||||||
<span class="bold"><strong>The item has more than one title, e.g. a translated title</strong></span>
|
<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><p>
|
</p><p> Controls <code class="literal">title.alternative</code> field.</p></li><li><p>
|
||||||
<span class="bold"><strong>The item has been published or publicly distributed before</strong></span>
|
<span class="bold"><strong>The item has been published or publicly distributed before</strong></span>
|
||||||
@@ -188,9 +188,9 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
</p><p>
|
</p><p>
|
||||||
<span class="emphasis"><em>Does not affect any metadata input fields.</em></span>
|
<span class="emphasis"><em>Does not affect any metadata input fields.</em></span>
|
||||||
</p></li></ol></div>
|
</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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14BAB"></a>Adding <code class="literal">Value-Pairs</code></h4></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 type="disc"><li><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><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>
|
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" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="N14BCB"></a>Adding <code class="literal">Value-Pairs</code></h4></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 type="disc"><li><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><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 type="disc"><li><p><span class="bold"><strong>displayed-value</strong></span> -- Name shown (on the web page) for the menu entry.</p></li><li><p><span class="bold"><strong>stored-value</strong></span> -- Value stored in the DC element when this entry is chosen.</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 type="disc"><li><p><span class="bold"><strong>displayed-value</strong></span> -- Name shown (on the web page) for the menu entry.</p></li><li><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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14BE8"></a>Example</h5></div></div></div><p>Here is a menu of types of common identifiers:</p><pre class="screen">
|
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" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="N14C08"></a>Example</h5></div></div></div><p>Here is a menu of types of common identifiers:</p><pre class="screen">
|
||||||
<value-pairs value-pairs-name="common_identifiers"
|
<value-pairs value-pairs-name="common_identifiers"
|
||||||
dc-term="identifier">
|
dc-term="identifier">
|
||||||
<pair>
|
<pair>
|
||||||
@@ -218,18 +218,18 @@ cribeStep</xmlui-binding> <workflow-editable>true</workflow-edita
|
|||||||
<option VALUE="uri">URI</option>
|
<option VALUE="uri">URI</option>
|
||||||
<option VALUE="isbn">ISBN</option>
|
<option VALUE="isbn">ISBN</option>
|
||||||
</select>
|
</select>
|
||||||
</pre><span class="bold"><strong>Identifiers:</strong></span>Gov't Doc #URIISBN</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14BFE"></a>11.4.4. Deploying Your Custom Forms</h3></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>
|
</pre><span class="bold"><strong>Identifiers:</strong></span>Gov't Doc #URIISBN</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14C1E"></a>11.4.4. Deploying Your Custom Forms</h3></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>
|
<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>
|
</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><p>
|
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><p>
|
||||||
<a name="docbook-submission.html-uploadStep"></a>
|
<a name="docbook-submission.html-uploadStep"></a>
|
||||||
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N14C1B"></a>11.5. Configuring the File Upload step</h2></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 type="disc"><li><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 type="circle"><li><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><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><p>
|
</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N14C3B"></a>11.5. Configuring the File Upload step</h2></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 type="disc"><li><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 type="circle"><li><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><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><p>
|
||||||
<a name="docbook-submission.html-createStep"></a>
|
<a name="docbook-submission.html-createStep"></a>
|
||||||
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N14C47"></a>11.6. Creating new Submission Steps</h2></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 type="1"><li><p> (<span class="bold"><strong>Required</strong></span>) Create a new Step Processing class </p><div class="itemizedlist"><ul type="disc"><li><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><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><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><p>
|
</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N14C67"></a>11.6. Creating new Submission Steps</h2></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 type="1"><li><p> (<span class="bold"><strong>Required</strong></span>) Create a new Step Processing class </p><div class="itemizedlist"><ul type="disc"><li><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><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><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><p>
|
||||||
<div class="itemizedlist"><ul type="disc"><li><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><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><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>
|
<div class="itemizedlist"><ul type="disc"><li><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><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><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><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 type="disc"><li><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><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><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 type="disc"><li><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-jspui-multilingual">Configuring Multilingual Support for JSPUI</a> or <a class="link" href="">Configuring Multilingual Support for XMLUI</a> for more details.</p></li><li><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><p>
|
</p></li><li><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 type="disc"><li><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><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><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 type="disc"><li><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-jspui-multilingual">Configuring Multilingual Support for JSPUI</a> or <a class="link" href="">Configuring Multilingual Support for XMLUI</a> for more details.</p></li><li><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><p>
|
||||||
<a name="docbook-submission.html-createStep.1"></a>
|
<a name="docbook-submission.html-createStep.1"></a>
|
||||||
</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14CE0"></a>11.6.1. Creating a Non-Interactive Step</h3></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 type="1"><li><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><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">
|
</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="N14D00"></a>11.6.1. Creating a Non-Interactive Step</h3></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 type="1"><li><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><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>
|
<code class="literal"> <step>
|
||||||
<processing-class>org.dspace.submit.step.MyNonInteractveStep</processi
|
<processing-class>org.dspace.submit.step.MyNonInteractveStep</processi
|
||||||
|
|||||||
@@ -1,4 +1,4 @@
|
|||||||
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 12. docbook/DRISchemaReference.html</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch11.html" title="Chapter 11. Customizing and Configuring Submission User Interface"><link rel="next" href="ch13.html" title="Chapter 13. DRI Schema Reference"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 12. docbook/DRISchemaReference.html</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch11.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch13.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N14D05"></a>Chapter 12. docbook/DRISchemaReference.html</h2></div></div></div><p> /* Code style */ div.element-example pre { border: 1px dashed black; overflow-x: hidden; background: rgb(240,240,240); margin: 0px; padding: 10px;} </p></div><HR><p class="copyright">Copyright © 2002-2009
|
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 12. docbook/DRISchemaReference.html</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch11.html" title="Chapter 11. Customizing and Configuring Submission User Interface"><link rel="next" href="ch13.html" title="Chapter 13. DRI Schema Reference"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 12. docbook/DRISchemaReference.html</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch11.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch13.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N14D25"></a>Chapter 12. docbook/DRISchemaReference.html</h2></div></div></div><p> /* Code style */ div.element-example pre { border: 1px dashed black; overflow-x: hidden; background: rgb(240,240,240); margin: 0px; padding: 10px;} </p></div><HR><p class="copyright">Copyright © 2002-2009
|
||||||
<a class="ulink" href="http://www.dspace.org/" target="_top">The DSpace Foundation</a>
|
<a class="ulink" href="http://www.dspace.org/" target="_top">The DSpace Foundation</a>
|
||||||
</p><div class="legalnotice"><a name="N10017"></a><p>
|
</p><div class="legalnotice"><a name="N10017"></a><p>
|
||||||
<a class="ulink" href="http://creativecommons.org/licenses/by/3.0/us/" target="_top">
|
<a class="ulink" href="http://creativecommons.org/licenses/by/3.0/us/" target="_top">
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,4 +1,4 @@
|
|||||||
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 15. DSpace System Documentation: Appendices</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch14.html" title="Chapter 14. DSpace System Documentation: Version History"><link rel="next" href="ix01.html" title="Index"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 15. DSpace System Documentation: Appendices</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch14.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ix01.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N168DE"></a>Chapter 15. <a name="docbook-appendix.html"></a>DSpace System Documentation: Appendices</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch15.html#N168E4">15.1. Default Dublin Core Metadata Registry</a></span></dt><dt><span class="section"><a href="ch15.html#N16E3D">15.2. Default Bitstream Format Registry</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N168E4"></a>15.1. <a name="docbook-appendix.html-dublincoreregistry"></a>Default Dublin Core Metadata Registry</h2></div></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td>
|
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 15. DSpace System Documentation: Appendices</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch14.html" title="Chapter 14. DSpace System Documentation: Version History"><link rel="next" href="ix01.html" title="Index"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapter 15. DSpace System Documentation: Appendices</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch14.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ix01.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="N16902"></a>Chapter 15. <a name="docbook-appendix.html"></a>DSpace System Documentation: Appendices</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch15.html#N16908">15.1. Default Dublin Core Metadata Registry</a></span></dt><dt><span class="section"><a href="ch15.html#N16E61">15.2. Default Bitstream Format Registry</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N16908"></a>15.1. <a name="docbook-appendix.html-dublincoreregistry"></a>Default Dublin Core Metadata Registry</h2></div></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td>
|
||||||
<p>
|
<p>
|
||||||
<span class="bold"><strong>Element</strong></span>
|
<span class="bold"><strong>Element</strong></span>
|
||||||
</p>
|
</p>
|
||||||
@@ -506,7 +506,7 @@
|
|||||||
<p></p>
|
<p></p>
|
||||||
</td></tr></tbody></table></div><p>
|
</td></tr></tbody></table></div><p>
|
||||||
<a name="docbook-appendix.html-note1"></a>
|
<a name="docbook-appendix.html-note1"></a>
|
||||||
</p><p>¹Used by system: do not remove</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N16E3D"></a>15.2. <a name="docbook-appendix.html-bitstreamformatregistry"></a>Default Bitstream Format Registry</h2></div></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col><col><col></colgroup><tbody><tr><td>
|
</p><p>¹Used by system: do not remove</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="N16E61"></a>15.2. <a name="docbook-appendix.html-bitstreamformatregistry"></a>Default Bitstream Format Registry</h2></div></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col><col><col></colgroup><tbody><tr><td>
|
||||||
<p>
|
<p>
|
||||||
<span class="bold"><strong>Mimetype</strong></span>
|
<span class="bold"><strong>Mimetype</strong></span>
|
||||||
</p>
|
</p>
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
@@ -1,4 +1,4 @@
|
|||||||
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Index</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch15.html" title="Chapter 15. DSpace System Documentation: Appendices"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Index</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch15.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> </td></tr></table><hr></div><div class="index"><div class="titlepage"><div><div><h2 class="title"><a name="N172F9"></a>Index</h2></div></div></div><div class="index"></div></div><HR><p class="copyright">Copyright © 2002-2009
|
<html><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Index</title><meta content="DocBook XSL Stylesheets V1.74.3" name="generator"><link rel="home" href="index.html" title="DSpace 1.5.2 Manual"><link rel="up" href="index.html" title="DSpace 1.5.2 Manual"><link rel="prev" href="ch15.html" title="Chapter 15. DSpace System Documentation: Appendices"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Index</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch15.html">Prev</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> </td></tr></table><hr></div><div class="index"><div class="titlepage"><div><div><h2 class="title"><a name="N1731D"></a>Index</h2></div></div></div><div class="index"></div></div><HR><p class="copyright">Copyright © 2002-2009
|
||||||
<a class="ulink" href="http://www.dspace.org/" target="_top">The DSpace Foundation</a>
|
<a class="ulink" href="http://www.dspace.org/" target="_top">The DSpace Foundation</a>
|
||||||
</p><div class="legalnotice"><a name="N10017"></a><p>
|
</p><div class="legalnotice"><a name="N10017"></a><p>
|
||||||
<a class="ulink" href="http://creativecommons.org/licenses/by/3.0/us/" target="_top">
|
<a class="ulink" href="http://creativecommons.org/licenses/by/3.0/us/" target="_top">
|
||||||
|
|||||||
Binary file not shown.
Reference in New Issue
Block a user