Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added a section describing XMLUI request flow (based on recent question to dspace-tech)

...

  • DRI Schema - Digital Repository Interface (DRI) schema (XML), which is the "abstract representation of a single repository page". The DRI document is contains all of the information (metadata) available for display on a given page within the XMLUI. This information includes:
    • Metadata elements (described in METS, MODS, DSpace Internal Metadata (DIM), Qualified Dublin Core, etc.)
    • Structural elements (described in TEI light)
    • For more specific information about DRI Schema along with examples, see DRI Schema Reference.
  • #Aspects - One or more aspects are enabled at a given time. Generally speaking an aspect implements a set of related features within the XMLUI. More specifically, the enabled aspects are what build the DRI document. So, Aspects are the only things that can change the structure of the DRI document (or add/remove content to/from DRI)
    • Aspects apply to all pages across your entire DSpace site. Each aspect must take a valid DRI document as its input, and also output a valid DRI document.
    • Aspects usually are written in Java (and controlled by a Cocoon "sitemap.xmap"). However, Aspects can also be written in XSLT (provided that the input and output are both valid DRI documents)
  • #Themes - One or more themes are enabled at a given time. Themes are in charge of stylizing content into a particular look & feel. More specifically, a theme is what transforms a DRI document into XHTML (and adds any CSS, javascript, images, etc).

Understanding the Flow of an XMLUI Request

One of the harder things to initially grasp in the XMLUI is how a single user's request (e.g. clicking on a link or button) flows through the entire system of enabled Aspects and Themes. Understanding this flow is also very important as you work to build your own Aspects (or complex Themes), as it may allow you to more easily determine what is going on in the system.

Before getting started, it's worth mentioning that this request flow is controlled via a series of sitemap.xmap (and other *.xmap) files. These sitemap.xmap files are Cocoons way of defining the flow. More information about Cocoon Sitemaps is available at: http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.htmlImage Added

The following explanation provides a high level overview of how a request is processed, how a DRI document is generated (via Aspects), and then how it is transformed into XHTML (via Themes). As this is a high level overview, some details are likely left out, but the overarching flow is what is most important.

  1. A user visits an XMLUI page (by clicking a link or button, etc)
  2. Wiki Markup
    That request begins in the root Cocoon {{sitemap.xmap}} (located at {{\[xmlui\]/sitemap.xmap}}). This is the main entry point for *all requests*
    • Within that sitemap, various URL path matching takes place. If the request is to download a document, that document is returned immediately.
    • Wiki Markup
      However, in many cases, the request is for a page within the XMLUI. In this scenario, the root sitemap.xmap will load the {{\[xmlui\]/themes/themes.xmap}} file, which controls all the Themes.
      • Wiki Markup
        The {{themes.xmap}} file will then load all "matching" themes which are configured in your {{\[dspace\]/config/xmlui.xconf}} file (see [#Themes] below).
      • If more than one theme matches the current URL path, then the first match wins
      • Once a matching theme is located, that theme's sitemap.xmap file (located in its theme directory) is loaded and processed.
        • The theme's sitemap.xmap is in charge of actually loading the theme's XSLT, CSS, etc. However, before it does that, you'll notice it makes a call to generate the DRI document for the current page as follows:
          Code Block
          <map:generate type="file" src="cocoon://DRI/{1}"/>
          #*** This DRI call generates a brand new, internal Cocoon request. This request is then processed back in the *root* {{sitemap.xmap}} (remember how we said that this sitemap is the main entry point for all requests).
          # Back in the root sitemap, the "DRI/**" call is matched.  This causes the {{\[xmlui\]/aspects/aspects.xmap}} file to be loaded. As the name suggests, this file obviously controls all the Aspects.
          #* The {{aspects.xmap}} file will then load all enabled Aspects which are configured in your {{\[dspace\]/config/xmlui.xconf}} file (see [#Aspects] below). 
          #* Each aspect is loaded in the *order that it appears*.  However, *multiple* aspects may be loaded for the same URL path. _Remember, aspects can build upon each other (we call this an "aspect chain") as they work together to generate the final DRI document._
          #* When an Aspect is loaded, it's {{sitemap.xmap}} is loaded & processed
          #** NOTE: An aspect's sitemap.xmap is actually compiled into the {{dspace-xmlui-api.jar}} file. However, if you have a copy of DSpace source handy, it can be found in: {{\[dspace-src]/dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/\[name-of-aspect\]/}})
          #* Each aspect is processed one-by-one (again in the order they are listed in {{xmlui.xconf}}). Each aspect may add, remove or change content within the DRI document. After the final aspect is finished processing, the DRI document is complete.
          #** HINT: In the XMLUI you can always view the final DRI document by adding "?XML" or "&XML" on to the end of the current URL in your web browser.
          # Once the final DRI document is complete (all aspects are done processing), the flow will return back to your Theme's {{sitemap.xmap}} (remember, this is the same location that triggered the loading of the Aspects in the first place).
          # At this point, your Theme's {{sitemap.xmap}} will continue its processing.  Generally speaking, most themes will then perform one or more XSLT transformations (to transform the final DRI document into XHTML). They also may load up one or more CSS files, to help stylize the final XHTML.
          # Finally, one the Theme has completed its processing (remember, only one theme is ever processed), the final generated XHTML document is displayed to the user.
          
          Again, the above flow is a slightly simplified version of what is going on underneath the XMLUI.  As you can see, [Cocoon Sitemaps|http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html] are what control most of the XMLUI processing (and the loading of the Aspects and Theme).
          
          h2. Manakin Configuration Property Keys

...

        • 
          
          In an effort to save the programmer/administrator some time, the configuration table below is taken from 5.3.43. _XMLUI Specific Configuration_.

...

        • 
          | Property:

...

        •  | _xmlui.supportedLocales

...

        • _ |
          | Example Value:

...

        •  | _xmlui.supportedLocales = en,

...

Informational Note:

...

        •  de_ |
          | Informational Note: | A list of supported locales for Manakin. Manakin will look at a user's browser configuration for the first language that appears in this list to make available to in the interface. This parameter is a comma separated list of Locales. All types of Locales country, country_language, country_language_variant. Note that if the appropriate files are not present (i.e. Messages_XX_XX.xml) then Manakin will fall back through to a more general language.

...

        •  |
          | Property:

...

        •  | _xmlui.force.ssl

...

        • _ |
          | Example Value:

...

        •  | _xmlui.force.ssl =

...

Informational Note:

...

Force all authenticated connections to use SSL, only non-authenticated connections are allowed over plain http. If set to true, then you need to ensure that the 'dspace.hostname' parameter is set to the correctly.

...

Property:

...

xmlui.user.registration

...

Example Value:

...

xmlui.user.registration = true

...

Informational Note:

...

Determine if new users should be allowed to register. This parameter is useful in conjunction with Shibboleth where you want to disallow registration because Shibboleth will automatically register the user. Default value is true.

...

Property:

...

xmlui.user.editmetadata

...

Example Value:

...

xmlui.user.editmetadata = true

...

Informational Note:

...

Determines if users should be able to edit their own metadata. This parameter is useful in conjunction with Shibboleth where you want to disable the user's ability to edit their metadata because it came from Shibboleth. Default value is true.

...

Property:

...

xmlui.user.assumelogon

...

Example Value:

...

xmlui.user.assumelogon = true

...

Informational Note:

...

Determine if super administrators (those whom are in the Administrators group) can login as another user from the "edit eperson" page. This is useful for debugging problems in a running dspace instance, especially in the workflow process. The default value is false, i.e., no one may assume the login of another user.

...

Property:

...

xmlui.user.loginredirect

...

Example Value:

...

xmlui.user.loginredirect = /profile

...

Informational Note:

...

After a user has logged into the system, which url should they be directed? Leave this parameter blank or undefined to direct users to the homepage, or /profile for the user's profile, or another reasonable choice is /submissions to see if the user has any tasks awaiting their attention. The default is the repository home page.

...

Property:

...

xmlui.theme.allowoverrides

...

Example Value:

...

xmlui.theme.allowoverrides = false

...

Informational Note:

...

Allow the user to override which theme is used to display a particular page. When submitting a request add the HTTP parameter "themepath" which corresponds to a particular theme, that specified theme will be used instead of the any other configured theme. Note that this is a potential security hole allowing execution of unintended code on the server, this option is only for development and debugging it should be turned off for any production repository. The default value unless otherwise specified is "false".

...

Property:

...

xmlui.bundle.upload

...

Example Value:

...

xmlui.bundle.upload = ORIGINAL, METADATA, THUMBNAIL, LICENSE, CC_LICENSE

...

Informational Note:

...

Determine which bundles administrators and collection administrators may upload into an existing item through the administrative interface. If the user does not have the appropriate privileges (add and write) on the bundle then that bundle will not be shown to the user as an option.

...

Property:

        •  true_ |
          | Informational Note: | Force all authenticated connections to use SSL, only non-authenticated connections are allowed over plain http. If set to true, then you need to ensure that the '_dspace.hostname_' parameter is set to the correctly. |
          | Property: | _xmlui.user.registration_ |
          | Example Value: | _xmlui.user.registration = true_ |
          | Informational Note: | Determine if new users should be allowed to register. This parameter is useful in conjunction with Shibboleth where you want to disallow registration because Shibboleth will automatically register the user. Default value is true. |
          | Property: | _xmlui.user.editmetadata_ |
          | Example Value: | _xmlui.user.editmetadata = true_ |
          | Informational Note: | Determines if users should be able to edit their own metadata. This parameter is useful in conjunction with Shibboleth where you want to disable the user's ability to edit their metadata because it came from Shibboleth. Default value is true. |
          | Property: | _xmlui.user.assumelogon_ |
          | Example Value: | _xmlui.user.assumelogon = true_ |
          | Informational Note: | Determine if super administrators (those whom are in the Administrators group) can login as another user from the "edit eperson" page. This is useful for debugging problems in a running dspace instance, especially in the workflow process. The default value is false, i.e., no one may assume the login of another user. |
          | Property: | _xmlui.user.loginredirect_ |
          | Example Value: | _xmlui.user.loginredirect = /profile_ |
          | Informational Note: | After a user has logged into the system, which url should they be directed? Leave this parameter blank or undefined to direct users to the homepage, or _/profile_ for the user's profile, or another reasonable choice is _/submissions_ to see if the user has any tasks awaiting their attention. The default is the repository home page. |
          | Property: | _xmlui.theme.allowoverrides_ |
          | Example Value: | _xmlui.theme.allowoverrides = false_ |
          | Informational Note: | Allow the user to override which theme is used to display a particular page. When submitting a request add the HTTP parameter "themepath" which corresponds to a particular theme, that specified theme will be used instead of the any other configured theme. Note that this is a potential security hole allowing execution of unintended code on the server, this option is only for development and debugging it should be turned off for any production repository. The default value unless otherwise specified is "false". |
          | Property: | _xmlui.bundle.upload_ |
          | Example Value: | _xmlui.bundle.upload = ORIGINAL, METADATA, THUMBNAIL, LICENSE, CC_LICENSE_ |
          | Informational Note: | Determine which bundles administrators and collection administrators may upload into an existing item through the administrative interface. If the user does not have the appropriate privileges (add and write) on the bundle then that bundle will not be shown to the user as an option. |
          | Property: | _xmlui.community-list.render.full

...

        • _ |
          | Example Value:

...

        •  | _xmlui.community-list.render.full =

...

Informational Note:

...

        •  true_ |
          | Informational Note: | On the community-list page should all the metadata about a community/collection be available to the theme. This parameter defaults to true, but if you are experiencing performance problems on the community-list page you should experiment with turning this option off.

...

        •  |
          | Property:

...

        •  | _xmlui.community-list.cache

...

        • _ |
          | Example Value:

...

        •  | _xmlui.community-list.cache = 12

...

Informational Note:

...

Normally, Manakin will fully verify any cache pages before using a cache copy. This means that when the community-list page is viewed the database is queried for each community/collection to see if their metadata has been modified. This can be expensive for repositories with a large community tree. To help solve this problem you can set the cache to be assumed valued for a specific set of time. The downside of this is that new or editing communities/collections may not show up the website for a period of time.

...

Property:

...

xmlui.bistream.mods

...

Example Value:

...

xmlui.bistream.mods = true

...

Informational Note:

...

Optionally, you may configure Manakin to take advantage of metadata stored as a bitstream. The MODS metadata file must be inside the "METADATA" bundle and named MODS.xml. If this option is set to 'true' and the bitstream is present then it is made available to the theme for display.

...

Property:

...

xmlui.bitstream.mets

...

Example Value:

...

xmlui.bitstream.mets = true

...

Informational Note:

...

Optionally, you may configure Manakin to take advantage of metadata stored as a bitstream. The METS metadata file must be inside the "METADATA" bundle and named METS.xml. If this option is set to "true" and the bitstream is present then it is made available to the theme for display.

...

Property:

...

xmlui.google.analytics.key

...

Example Value:

...

xmlui.google.analytics.key = UA-XXXXXX-X

...

Informational Note:

...

        •  hours_ |
          | Informational Note: | Normally, Manakin will fully verify any cache pages before using a cache copy. This means that when the community-list page is viewed the database is queried for each community/collection to see if their metadata has been modified. This can be expensive for repositories with a large community tree. To help solve this problem you can set the cache to be assumed valued for a specific set of time. The downside of this is that new or editing communities/collections may not show up the website for a period of time. |
          | Property: | _xmlui.bistream.mods_ |
          | Example Value: | _xmlui.bistream.mods = true_ |
          | Informational Note: | Optionally, you may configure Manakin to take advantage of metadata stored as a bitstream. The MODS metadata file must be inside the "METADATA" bundle and named MODS.xml. If this option is set to 'true' and the bitstream is present then it is made available to the theme for display. |
          | Property: | _xmlui.bitstream.mets_ |
          | Example Value: | _xmlui.bitstream.mets = true_ |
          | Informational Note: | Optionally, you may configure Manakin to take advantage of metadata stored as a bitstream. The METS metadata file must be inside the "METADATA" bundle and named METS.xml. If this option is set to "true" and the bitstream is present then it is made available to the theme for display. |
          | Property: | _xmlui.google.analytics.key_ |
          | Example Value: | _xmlui.google.analytics.key = UA-XXXXXX-X_ |
          | Informational Note: | If you would like to use google analytics to track general website statistics then use the following parameter to provide your analytics key. First sign up for an account at [http://analytics.google.com|http://analytics.google.com|http://analytics.google.com], then create an entry for your repositories website. Google Analytics will give you a snipit of javascript code to place on your site, inside that snip it is your Google Analytics key usually found in the line: \_uacct = "UA-XXXXXXX-X" Take this key (just the UA-XXXXXX-X part) and place it here in this parameter.

...

        •  |
          | Property:

...

        •  | _xmlui.controlpanel.activity.max

...

        • _ |
          | Example Value:

...

        •  | _xmlui.controlpanel.activity.max =

...

Informational Note:

...

Assign how many page views will be recorded and displayed in the control panel's activity viewer. The activity tab allows an administrator to debug problems in a running DSpace by understanding who and how their DSpace is currently being used. The default value is 250.

...

Property:

        •  250_ |
          | Informational Note: | Assign how many page views will be recorded and displayed in the control panel's activity viewer. The activity tab allows an administrator to debug problems in a running DSpace by understanding who and how their DSpace is currently being used. The default value is 250. |
          | Property: | _xmlui.controlpanel.activity.ipheader

...

        • _ |
          | Example Value:

...

        •  | _xmlui.controlpanel.activity.ipheader = X-Forward-For

...

        • _ |
          | Informational Note:

...

        •  | Determine where the control panel's activity viewer receives an events IP address from. If your DSpace is in a load balanced environment or otherwise behind a context-switch then you will need to set the parameter to the HTTP parameter that records the original IP address.

...

Configuring Themes and Aspects

...

        •  |
          
          
          h2. Configuring Themes and Aspects
          
          The Manakin user interface is composed of two distinct components: _aspects_ and _themes_. Manakin aspects are like extensions or plugins for Manakin; they are interactive components that modify existing features or provide new features for the digital repository. Manakin themes stylize the look-and-feel of the repository, community, or collection.

...

        • 
          
          The repository administrator is able to define which aspects and themes are installed for the particular repository by editing the _\[dspace\]/config/xmlui.xconf_ configuration file. The _xmlui.xconf_ file consists of two major sections: Aspects and Themes.

...

Aspects

...

        • 
          
          h3. Aspects
          
          The _<aspects>_ section defines the "Aspect Chain", or the linear set of aspects that are installed in the repository. For each aspect that is installed in the repository, the aspect makes available new features to the interface. For example, if the "submission" aspect were to be commented out or removed from the _xmlui.xconf_, then users would not be able to submit new items into the repository (even the links and language prompting users to submit items are removed). Each _<aspect>_ element has two attributes, _name_ and _path_. The name is used to identify the Aspect, while the path determines the directory where the aspect's code is located. Here is the default aspect configuration:
          

...

        • <aspects>
          <aspect name="Artifact

...

        • Browser"

...

        • path="resource://aspects/ArtifactBrowser/"

...

        • />

...


        • <aspect name="Administration"

...

        • path="resource://aspects/Administrative/"

...

        • />

...


        • <aspect name="E-Person"

...

        • path="resource://aspects/EPerson/"

...

        • />

...


        • <aspect name="Submission

...

        • and

...

        • Workflow"

...

        • path="resource://aspects/Submission/"

...

        • />

...


        • </aspects>
          Code Block
          
          A standard distribution of Manakin/DSpace includes four "core"

...

  • Artifact Browser The Artifact Browser Aspect is responsible for browsing communities, collections, items and bitstreams, viewing an individual item and searching the repository.
  • E-Person The E-Person Aspect is responsible for logging in, logging out, registering new users, dealing with forgotten passwords, editing profiles and changing passwords.
  • Submission The Submission Aspect is responsible for submitting new items to DSpace, determining the workflow process and ingesting the new items into the DSpace repository.
  • Administrative The Administrative Aspect is responsible for administrating DSpace, such as creating, modifying and removing all communities, collections, e-persons, groups, registries and authorizations.

Themes

The <themes> section defines a set of "rules" that determine where themes are installed in the repository. Each rule is processed in the order that it appears, and the first rule that matches determines the theme that is applied (so order is important). Each rule consists of a <theme> element with several possible attributes:

  • name (always required)The name attribute is used to document the theme's name.
  • path (always required)The path attribute determines where the theme is located relative to the themes/ directory and must either contain a trailing slash or point directly to the theme's sitemap.xmap file.
  • regex (either regex and/or handle is required)The regex attribute determines which URLs the theme should apply to.
  • handle (either regex and/or handle is required)The handle attribute determines which community, collection, or item the theme should apply to.
    If you use the "handle" attribute, the effect is cascading, meaning if a rule is established for a community then all collections and items within that community will also have this theme apply to them as well. Here is an example configuration:
    Code Block
    
        <themes>
            <theme name="Theme 1" handle="123456789/23" path="theme1/"/>
            <theme name="Theme 2" regex="community-list"	path="theme2/"/>
            <theme name="Reference Theme" regex=".*" path="Reference/"/>
        </themes>
    In the example above three themes are configured: "Theme 1", "Theme 2", and the "Reference Theme". The first rule specifies that "Theme 1" will apply to all communities, collections, or items that are contained under the parent community "123456789/23". The next rule specifies any URL containing the string "community-list" will get "Theme 2". The final rule, using the regular expression ".", will match *anything, so all pages which have not matched one of the preceding rules will be matched to the Reference Theme.

Multilingual Support

The XMLUI user interface supports multiple languages through the use of internationalization catalogues as defined by the Cocoon Internationalization Transformer. Each catalog contains the translation of all user-displayed strings into a particular language or variant. Each catalog is a single xml file whose name is based upon the language it is designated for, thus:

messages_language_country_variant.xml

messages_language_country.xml

messages_language.xml

messages.xml

The interface will automatically determine which file to select based upon the user's browser and system configuration. For example, if the user's browser is set to Australian English then first the system will check if messages_en_au.xml is available. If this translation is not available it will fall back to messages_en.xml, and finally if that is not available, messages.xml.

...

        •  aspects:
          * *Artifact Browser* The Artifact Browser Aspect is responsible for browsing communities, collections, items and bitstreams, viewing an individual item and searching the repository.
          * *E-Person* The E-Person Aspect is responsible for logging in, logging out, registering new users, dealing with forgotten passwords, editing profiles and changing passwords.
          * *Submission* The Submission Aspect is responsible for submitting new items to DSpace, determining the workflow process and ingesting the new items into the DSpace repository.
          * *Administrative* The Administrative Aspect is responsible for administrating DSpace, such as creating, modifying and removing all communities, collections, e-persons, groups, registries and authorizations.
          
          
          h3. Themes
          
          The _<themes>_ section defines a set of "rules" that determine where themes are installed in the repository. Each rule is processed in the order that it appears, and the first rule that matches determines the theme that is applied (so order is important). Each rule consists of a _<theme>_ element with several possible attributes:
          
          * *name* (_always required_)The name attribute is used to document the theme's name.
          * *path* (_always required_)The path attribute determines where the theme is located relative to the _themes/_ directory and must either contain a trailing slash or point directly to the theme's _sitemap.xmap_ file.
          * *regex* (_either regex and/or handle is required_)The regex attribute determines which URLs the theme should apply to.
          * *handle* (_either regex and/or handle is required_)The handle attribute determines which community, collection, or item the theme should apply to.
          If you use the "handle" attribute, the effect is cascading, meaning if a rule is established for a community then all collections and items within that community will also have this theme apply to them as well. Here is an example configuration:
          
          <themes>
          <theme name="Theme 1" handle="123456789/23" path="theme1/"/>
          <theme name="Theme 2" regex="community-list" path="theme2/"/>
          <theme name="Reference Theme" regex=".*" path="Reference/"/>
          </themes>
          Code Block
          
          In the example above three themes are configured: "Theme 1", "Theme 2", and the "Reference Theme". The first rule specifies that "Theme 1" will apply to all communities, collections, or items that are contained under the parent community "123456789/23". The next rule specifies any URL containing the string "community-list" will get "Theme 2". The final rule, using the regular expression ".*", will match \*anything*, so all pages which have not matched one of the preceding rules will be matched to the Reference Theme.
          
          
          
          h2. Multilingual Support
          
          The XMLUI user interface supports multiple languages through the use of internationalization catalogues as defined by the [Cocoon Internationalization Transformer|http://cocoon.apache.org/2.1/userdocs/i18nTransformer.html|Cocoon Internationalization Transformer]. Each catalog contains the translation of all user-displayed strings into a particular language or variant. Each catalog is a single xml file whose name is based upon the language it is designated for, thus:
          
          messages\__language___country___variant_.xml
          
          messages\__language___country_.xml
          
          messages\__language_.xml
          
          messages.xml
          
          The interface will automatically determine which file to select based upon the user's browser and system configuration. For example, if the user's browser is set to Australian English then first the system will check if _messages_en_au.xml_ is available. If this translation is not available it will fall back to _messages_en.xml_, and finally if that is not available, _messages.xml_.
          
          Manakin supplies an English only translation of the interface. In order to add other translations to the system, locate the _\[dspace-source\]/dspace/modules/xmlui/src/main/webapp/i18n/_ directory. By default this directory will be empty; to add additional translations add alternative versions of the _messages.xml_ file in specific language and country variants as needed for your installation.

...

        • 
          
          To set a language other than English as the default language for the repository's interface, simply name the translation catalogue for the new default language "_messages.xml

...

Creating a New Theme

...

        • _"
          
          
          h2. Creating a New Theme
          
          Manakin themes stylize the look-and-feel of the repository, community, or collection and are distributed as self-contained packages. A Manakin/DSpace installation may have multiple themes installed and available to be used in different parts of the repository. The central component of a theme is the sitemap.xmap, which defines what resources are available to the theme such as XSL stylesheets, CSS stylesheets, images, or multimedia files.
          *1) Create theme skeleton*
          Most theme developers do not create a new theme from scratch; instead they start from the standard theme template, which defines a skeleton structure for a theme. The template is located at: _\[dspace-source\]/dspace-xmlui/dspace-xmlui-webbapp/src/main/webbapp/themes/template_. To start your new theme simply copy the theme template into your locally defined modules directory, _\[dspace-source\]/dspace/modules/xmlui/src/main/webbapp/themes/\[your theme's directory\]/_.
          *2) Modify theme variables*
          The next step is to modify the theme's parameters so that the theme knows where it is located. Open the _\[your theme's directory\]/sitemap.xmap_ and look for _<global-variables>_

...

        • 
          
          <global-variables>
          <theme-path>

...

...

...

...

        • </theme-path>

...


        • <theme-name>

...

...

...

...

        • </theme-name>

...


        • </global-variables>
          Code Block
          
          Update both the theme's path to the directory name you created in step one. The theme's name is used only for documentation.

...

        • 
          *3) Add your CSS stylesheets

...

        • *
          The base theme template will produce a repository interface without any style - just plain XHTML with no color or formatting. To make your theme useful you will need to supply a CSS Stylesheet that creates your desired look-and-feel. Add your new CSS stylesheets:

...

        • 
          
          _\[your theme's directory\]/lib/style.css_ (The base style sheet used for all browsers)

...

        • 
          
          _\[your theme's directory\]/lib/style-ie.css_ (Specific stylesheet used for internet explorer)
          *4) Install theme and rebuild DSpace*
          Next rebuild and deploy DSpace (replace <version> with the your current release):

...

  1. Wiki Markup
        • 
          
          # Rebuild the DSpace installation package by running the following command from your _\[dspace-source\]/dspace/_ directory:
    Code Block
        • mvn
        • package
          Wiki Markup
          Code Block
          
          # Update all DSpace webapps to _\[dspace\]/webapps_ by running the following command from your _\[dspace-source\]/dspace/target/dspace-\[version\]-build.dir_ directory:
    code
        • ant
        • -Dconfig=
    []
        • /config/dspace.cfg
        • update
          Code Block
          
          # 
        • Deploy the the new webapps:
    code
        •  
          cp
        • -R
        • /
    []
        • /webapps/*
        • /
    []
        • /webapps
          Code Block
          
          # Restart Tomcat

        • 
          This will ensure the theme has been installed as described in the previous section "Configuring Themes and Aspects".
          
          
          h2.
        •  Customizing the News Document

...

        • 
          
          The XMLUI "news" document is only shown on the root page of your repository.  It was intended to provide the title and introductory message, but you may use it for anything.

...

        • 
          
          The news document is located at _\[dspace\]/dspace/config/news-xmlui.xml_.  There is only one version; it is localized by inserting "i18n" callouts into the text areas.  It must be a complete and valid XML DRI document (see Chapter 15).

...

        • 
          
          Its (the News document) exact rendering in the XHTML UI depends, of course, on the theme.  The default content is designed to operate with the reference themes, so when you modify it, be sure to preserve the tag structure and e.g. the exact attributes of the first DIV tag.  Also note that the text is DRI, not HTML, so you must use only DRI tags, such as the XREF tag to construct a link.

...

        • 
          
          Example 1: a single language:
          

...

        • <document>
          <body>
          <div id="file.news.div.news"

...

        • n="news"

...

        • rend=

...

        • "primary">
          <head> TITLE OF YOUR REPOSITORY HERE </head>
          <p>
          INTRO MESSAGE HERE
          Welcome to my wonderful repository etc etc ...
          A service of <xref target="http://myuni.edu/">My

...

        • University</xref>

...


        • </p>

...


        • </div>

...


        • </body>

...


        • <options/>

...


        • <meta>
          <userMeta/>

...


        • <pageMeta/>

...


        • <repositoryMeta/>

...


        • </meta>

...


        • </document>

          Example 2: all text replaced by references to localizable message keys:

          Code Block

...

        • 
          Example 2: all text replaced by 

...

        • references to localizable 

...

        • message keys:
          
          <document>
          <body>
          <div id="file.news.div.news"

...

        • n="news"

...

        • rend="primary">

...


        • <head><i18n:text>myuni.repo.title</i18n:text></head>

...


        • <p>
          <i18n:text>myuni.repo.intro</i18n:text>

...


        • <i18n:text>myuni.repo.a.service.of<

...

        • /i18n:text>
          <xref target="http://myuni.edu/"><i18n:text>myuni.name</i18n:text></xref>

...


        • </p>

...


        • </div>

...


        • </body>

...


        • <options/>

...


        • <meta>
          <userMeta/>

...


        • <pageMeta/>

...


        • <repositoryMeta/>
          </meta>

...


        • </document>

...

        • Code Block
          
          
          h2. Adding Static Content
          
          The XMLUI user interface supports the addition of globally static content (as well as static content within individual themes).
          
          

Adding Static Content

The XMLUI user interface supports the addition of globally static content (as well as static content within individual themes).

...

        • Globally static content can be placed in the _\[dspace-source\]/dspace/modules/xmlui/src/main/webapp/static/_ directory. By default this directory only contains the default _robots.txt_ file, which provides helpful site information to web spiders/crawlers. However, you may also add static HTML (_\*.html_) content to this directory, as needed for your installation.

...

        • 
          
          Any static HTML content you add to this directory may also reference static content (e.g. CSS, Javascript, Images, etc.) from the same _\[dspace-source\]/dspace/modules/xmlui/src/main/webapp/static/_ directory. You may reference other static content from your static HTML files similar to the following:

...

        • 
          

...

        • <link

...

        • href="./static/mystyle.css"

...

        • rel="stylesheet"

...

        • type="text/css"/>

...


        • <img

...

        • src="./static/images/static-image.gif"

...

        • alt="Static

...

        • image

...

        • in

...

        • /static/images/

...

        • directory"/>

...


        • <img

...

        • src="./static/static-image.jpg"

...

        • alt="Static

...

        • image

...

        • in

...

        • /static/

...

        • directory"/>

...

        • Code Block

Harvesting Items from XMLUI via OAI-ORE or OAI-PMH

...