A box is a group of metadata that are shown/edit together. In this section is possible to see all the boxes configured in the system, edit the current configuration for any box or add a new one.

For each one, the system other than the usual edit and remove icons can show two special “JSP icon”:

• A yellow “JSP icon” appears near the box name, it means that a JSP fragment does exist in order to set up the box for the public display;
• A red “JSP icon” is present when the fragment is valid for “edit view.

Custom JSPs are normally used when you want to override the out-of-box layout produced by the system, see “Custom JSPs” for further information.

By clicking on the “edit” option of a box with JSP icon, the system shows the following mask:

The external rendering field contains the name of the custom JSP page, if any, to use for the box rendering. In the example a rpcerif.jsp file needs to be placed in the dspace-cris/jdyna/custom folder of the webapp.

If show collapsed is flagged, the box will be shown collapsed in the public view and the user will need to click the box title to see the content. 

The unnecessary flag exclude the box from the evaluation of the Tab content, if a Tab has not content the tab is hidden.

In the fields available container are shown all the already defined fields. Ticked fields are included in the box. By default, only the fields in the box are shown, to see the other available fields you need to click on the Show/Hide other fields link.

Data Model configuration: Field Definition

From the edit/create box form is possible to create new fields.

The following image shows the “edit” option of a box configuration. The field definition menu is placed at the bottom of the page (look at the red circle in the figure).

The available data type are: DATE, TEXT, COMPLEX, LINK and FILE other than reference to other CRIS objects.

The basic set of metadata that define any type of field is enclosed into the upper red frame and this set includes: Shortname, Label, Field access level, Mandatory, Repeatable, Priority, New Line, Label min size and Field min size for row and column. 

A field is determined by the following metadata:

• a “Shortname” and a “Label” to identify the field
• a “Field access level” to define the access level for the field in the edit screens (NB: Administrators can always edit/hide any field)
• a “Mandatory” flag to make field required (no effect on property definition created by nesting)
• a “Repeatable” flag to give the possibility to add more objects of the same type
• a “Priority” index to increase or decrease the priority of the field, thus moving it up or down in the screen
• a “New Line” flag to require new line after the field
• a “Label min size” to define the minimum size of the label
• a “Row” and “Column” “Field min size” to define the minimum size of row and column where the field is positioned

DATE

Two extra elements are specific for the Date field:

• an “Year Min” and “Year Max” to set the calendar minimum and maximum year.

TEXT

Three extra elements are specific for the Text field:

• the “Size” metadata sets the textbox size
• the “Regex” metadata is available to validate a regular expression
• the "Custom rendering" metadata allows to set a custom rendering for the text as for instance the creation of automatic links. The {0} special placeholder will be automatically replaced with the actual text value . For instance the orcid field configuration is <a target="_blank" href="http://sandbox.orcid.org/{0}">{0}> that allow the ORCID ID to be shown as a link to the ORCID website (by default the sandbox but it is easy to change the configuration accordly)

COMPLEX

It is a nested object made up of one or more data types. As the next figure shows, the user has the possibility to add every kind of element to be nested (a text, a date, a link, a file, a researcher profile pointer, a project pointer, an organization unit pointer, a DO pointer), each one with its specific form explained in this documentation.

The basic set of metadata in the upper red square of the complex type are the same of the previously mentioned fields, except for the last one named “Inline or tabulized”: when it is checked it means that data are not shown inside a table, otherwise when unchecked data are shown in table format.

LINK

data type allows to create an hypertext field. There are two specific elements:

• head label, which is a header label that may be shown while editing the link
• head label URL, which is a header label that may be shown while editing the URL.

FILE

data type allows to upload a file, with the set of metadata shown in the next figure.

Basic metadata are the same as above, whereas specific metadata for the file data type are the following:

• Show preview: this element must be checked in order to show a preview of the file in the detailed page
• File description: the user has the possibility to write here a short description to use for upload
• Label hypertext: this is a hypertext link
• Keep track of downloads into statistics index: the user may decide to keep track of the number of downloads of the file to build up statistics on it.

Reference fields

It is also possible to create four other types of field:

• Add a Researcher Profile reference field
• Add a Project reference field
• Add an Organization Unit reference field
• Add generic research entities reference field

These functionalities allow to set up a relation between a researcher (assuming that we are managing researcher page fields) and another entity, via the form reported in the following figure:

Other than the basic list of metadata there are the following specific elements:

• Value to display (EL): it has to be expressed using the Expression Language (EL) syntax, e.g "${displayObject.fullName}" or "${displayObject.anagrafica4view['fullName'][0].value}".
• Filter query: any SOLR query that returns the appropriate data set must be typed here, in order to filter the lookup set.
• Index name: Name of the SOLR index to query on
• URL Path for resource: the relative URL to use to access the details of the linked object assuming as base URL the webapp application context path. The expression in the url path will be evaluated.

For example: cris/uuid/${displayObject.uuid}