You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

To customize the presentation of the data of a CRIS entity other than rearranging the order of the data inside a box and deciding positioning, see “Group Metadata, aka boxes”, the system allow you to define your custom JSPs used instead of the out-of-box layout.

You can use custom JSPs for example to add javascripts both in the visualization mode than in edit mode, show content retrieved from external systems, add static or dynamic content implementing the components or processors extension points (see below).

In this case, even if the configuration is edited via UI, the layout does not change, because it is defined by the JSP fragment.

CRIS Components

The system allows extension through the use of component that can extends the presentation, tools and functionalities available for any entities.

The components are registered in the [installDir]/config/spring/cris/cris-components.xml spring file. For any CRIS entity type has been defined a service where that manage the components, these services need to be named rpComponentsService, pjComponentsService, ouComponentsService and doComponentsService. The first two letters of the service name refer to the short name of the related CRIS Entity: ResearcherPage (rp), Project (pj), OrgUnit (ou), Dynamic Object (do).

The snippet below show the default configuration for the Researcher Page components Service

 

<!-- Components -->
<bean id="rpComponentsService" class="org.dspace.app.cris.integration.CrisComponentsService">
 <property name="components">
  <map>
   <entry key="dspaceitems" value-ref="publicationlist" />
   <entry key="projects" value-ref="projectlist" />
  </map>
 </property>
</bean>


For every components, a box with the same name and a custom JSP file must be defined. Placing such box in one or more Tab will enable the components visualization.

Out-of-box the system include configurable components to explore inverse relationship between a CRIS object and DSpace items and a CRIS object and other CRIS objects. This approach other than be time saving make also the data model more consistent avoiding the creation of wrong unilateral relationship. For example: if a researcher belongs to a department it has to be set up a pointer field via UI (see “Field Definition”). However, the OrgUnit entity not need a pointer to track the relationships between the department and all its researchers. The component executes the appropriate SOLR query to retrieve the referencing objects. The snippet below show the configuration of the publicationList component for the ResearcherPage

 

<!-- Publication component for RP -->
<bean id="publicationlist"
 class="org.dspace.app.webui.cris.components.ItemsConfigurerComponent">
 <property name="relationConfiguration" ref="relationRPVSItemConfiguration" />
 <property name="commonFilter">
 <util:constant static-field="org.dspace.app.webui.cris.util.RelationPreferenceUtil.HIDDEN_FILTER"/>  </property>   
 <property name="target" value="org.dspace.app.cris.model.ResearcherPage" />
 <property name="types">
  <map>
   <entry key="selected" value-ref="selectedComponent" />
   <entry key="journal" value-ref="journalComponent" />
   <entry key="conference" value-ref="conferenceComponent" />
   <entry key="book" value-ref="bookComponent" />
   <entry key="patent" value-ref="patentComponent" />
   <entry key="other" value-ref="otherComponent" />
  </map>
 </property>
</bean>

 

org.dspace.app.webui.cris.components.ItemsConfigurerComponent is the implementation of the abstract class org.dspace.app.webui.cris.components.ASolrConfigurerComponent<T extends DSpaceObject, IBC extends ICrisBeanComponent> able to manage relationship between CRIS objects and DSpace Items. The following class provide similar functionalities for the other kinds of relationship

  • org.dspace.app.webui.cris.components.CRISDOConfigurerComponent able to explore relationship with Dynamic Object

  • org.dspace.app.webui.cris.components.CRISOUConfigurerComponent able to explore relationship with OrgUnit

  • org.dspace.app.webui.cris.components.CRISPJConfigurerComponent able to explore relationship with Project

  • org.dspace.app.webui.cris.components.CRISRPConfigurerComponent able to explore relationship with ResearcherPage

The following attributes define the behavior of such classes

  • relationConfiguration defines a relation between two Entity Class (CRIS Objects or DSpace Item), see the dedicated paragraph for further details

  • commonFilter defines an additional SOLR filter query to apply to the relationship

  • target must match the class canonical name of the target Entity in the relationship, i.e. if the relationship is Item – ResearcherPage (author) the target class is the ResearcherPage

  • types is a map that allow clustering of the relationship under user-defined category (facet query), see the dedicated paragraph for further details

Relationship definition

The relationships are defined in the [installDir]/config/spring/cris/cris-relationpreference.xml 

A relationConfiguration is shown in the snippet below

 

<bean id="relationRPVSItemConfiguration" class="org.dspace.app.cris.configuration.RelationConfiguration">
 <property name="relationName" value="crisrp.publications" />  
 <property name="relationClass" value="org.dspace.content.Item" />  
 <property name="query">
  <value>author_authority:{0}</value>
 </property>
</bean>

 

It is defined by

  • relationName, an unique name that characterize the relationship

  • relationClass, the class canonical name of the Entity Class that holds the main direction of the relationship

  • query, the solr query that can be used to retrieve the objects linked to the “current” object. {0} will be replaced with the authority key of the current object

Relation Preference Management

The relationConfiguration are used other than by the components by the RelationPreferenceService that can be enabled over one or more relationship so to allow the user to hide some relationship of make a selected list. The RelationPreferenceService is configured through the definition of a spring bean for the class org.dspace.app.cris.configuration.RelationPreferenceServiceConfiguration the default configuration is shown below

 

<bean class="org.dspace.app.cris.configuration.RelationPreferenceServiceConfiguration">
   <property name="list">
       <list>
 <bean class="org.dspace.app.cris.configuration.RelationPreferenceConfiguration">
  <property name="relationConfiguration"  ref="relationRPVSItemConfiguration"/>
  <property name="selectActionAuthLevel">
   <util:constant static-field="org.dspace.app.cris.configuration.RelationPreferenceConfiguration.ENABLED" />
  </property>
  <property name="hideActionAuthLevel">
   <util:constant static-field="org.dspace.app.cris.configuration.RelationPreferenceConfiguration.ENABLED" />
  </property>
  <property name="unlinkActionAuthLevel">
   <util:constant static-field="org.dspace.app.cris.configuration.RelationPreferenceConfiguration.ONLY_SYSTEM_ADMIN" />
  </property>
  <property name="extraAction">
   <bean class="org.dspace.app.cris.configuration.ItemExtraAction" />
  </property>
  <property name="columnsVisualizationConfiguration">
   <list>
   <bean class="org.dspace.app.cris.configuration.ColumnVisualizationConfiguration">
    <property name="name" value="title" />
    <property name="metadata">
     <list>
      <value>dc.title</value>
     </list>
    </property> 
   </bean>
   <bean class="org.dspace.app.cris.configuration.ColumnVisualizationConfiguration">
    …
   </bean>
   </list>
  </property>
 </bean>
      </list>
   </property>
</bean>

 

The RelationPreferenceServiceConfiguration keeps a list of RelationPreferenceConfiguration that defines for a specific relationConfiguration which actions (select, hide, unhide, unlink) are available and to whom (researcher and/or system administrators). Finally, the columnsVisualizationConfiguration allows to define which columns show in the relation management functionality (see ) and the extraAction allows to inject the business logic needed to manage the preference changes (from a standard relationship to a selected one, from an hide relationship to a standard one and so on).

Relation Clustering

The configuration of the clustering categories are done using spring beans. The snippet below show the default configuration for a “journal article” category applied to the publication list

 

<bean id="journalComponent" class="org.dspace.app.webui.cris.components.BeanFacetComponent">
 <property name="componentIdentifier" value="journal" />
 <property name="facetQuery">
  <value>dc.type:Article -relationpreferences.crisrp.publications.selected:{1}</value>
 </property>
 <property name="order"><value>asc</value></property>
 <property name="rpp"><value>20</value></property>
 <property name="sortby"><value>1</value></property> 
</bean>

 

The facetQuery property is evaluated replacing {0} with the authority key of current object and {1} with the uuid.

The default configuration exclude the selected publications from their native category (article, book, etc.) so to have not overlapping categories but it can easily be changed modified the facet query definition removing the

-relationpreferences.crisrp.publications.selected:{1}

CRIS Processors

 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.