[EN] 05. Changing the Configuration of the Reader Application

Configuring the Reader Application

In this chapter, there are instructions on the configuration of some mechanisms related to the reader application.

Configuring the CAS Service

The dLibra system makes it possible to use a central login system created with the use of the CAS server and the LDAP service. CAS is available as another identity provider in file dlibra-webapp/WEB-INF/conf/user-providers.xml. The following fragment should be uncommented:

 <pl.psnc.dlibra.web.comp.user.CasUserInformationProvider>
    <loginPage>http://dlibra.psnc.pl/cas/login?service=${prevpage}</loginPage>
    <logoutPage>${homepage}main?action=LogoutAction</logoutPage>
    <loginPagePosition>2</loginPagePosition>
    <methodNameResourceKey>uip.cas.name</methodNameResourceKey>
    <ldapConfiguration>WEB-INF/conf/ldap.properties</ldapConfiguration>
    <userAttributesDefaults>
      <property name="givenName" value="dLibra"/>
      <property name="cn" value=""/>
      <property name="mail" value=""/>
    </userAttributesDefaults>
    <emailAttributeName>mail</emailAttributeName>
  </pl.psnc.dlibra.web.comp.user.CasUserInformationProvider>

Next, the user should:

• change the value of the loginPage tag in such a way that it points to the login page of the used CAS server, and
• in the userAttributesDefaults tag, enter the names of the attributes which are to be used for creating dynamic property groups in the manager application of the dLibra system; the value of the value attribute of every property tag determines the default value for the attribute;
• if every user has an email address specified as the value of an attribute in the used LDAP register, the name of that attribute can be entered in the emailAttributeName tag; then, the dLibra system will be able to use the information about the users’ email addresses;
• the name of an identity provider can be changed, by overwriting, in WEBAPP_xx.xml, the value of the text label located in methodNameResourceKey.

Next, the content of file dlibra-webapp/WEB-INF/conf/ldap.properties should be completed. The file contains parameters which make it possible to use the LDAP service.

Configuring News Import

The reader application makes it possible to publish various types of messages on the home page. Those news can be added with the use of the administration panel of the reader application or by means of the mechanism of RSS news import. A sample import process is discussed below.

In order to import news from an RSS available online, the user should uncomment the “periodic-task” tag containing the configuration of the NewsImportTask in the periodic.xml file

<periodic-task logicClass="pl.psnc.dlibra.web.comp.periodic.NewsImportTask"
	 executeOnStart="yes">
 <description>Checks feed url given in configuration, and imports news from that feed.</description>
 ....
</periodic-task>

The configuration of that task consists of the following parameters:

• feed.url – the address of the RSS/Atom channel containing the imported news;
• add.post.link.to.blog – if the value of that parameter is “true”, then for every news, a link to the page on which it was originally published will be added;
• full – which element of an entry in the RSS channel is to be used as the full text of the news; in the case of RSS channels, it will usually be the “description” element, but Atom channels also have two tags with the content of an entry: “content” and “summary”; the admissible values are feed_description and feed_content;
• short – which element of the channel is to be imported as the summary of a news item; the admissible values are feed_description and feed_content;
• publish.in.all.languages – if the value of that parameter is “true”, the news will be imported in all the interface languages installed in the reader application;
• blog.language – the language in which the imported news is written;
• start.date – only those entries will be imported which have been published after the date (dd.MM.YYYY) entered here;

by default, that task is carried out once a day; whenever the reader application detects that a new news item has appeared in the RSS channel, it will import it within the framework of the nearest performance of that task.

Adding Bookplates

In the reader application of the dLibra system, bookplates are represented as images with a link to the selected page (library, institution, etc.) which appear on the page with the description of a publication (publication, docmetadata). Bookplates are added on the basis of the values of particular attributes in metadata. For example, a bookplate may be displayed depending on the value of the “Permissions” attribute – for the “Library Institution X” value, an image which identifies that institution will be displayed, together with a link to the home page of that institution, “www.instytucjabibliotecznax.com”.

A bookplate is added in the following manner:

1. In the webapp/exlibris directory, the graphics file with the bookplate of the library should be entered.

2. File webapp/WEB-INF/conf/exNbris.xml contains the following entries:

   <exlibrises>
    <attribute rdfname="Rights">
     <attribute-value value="Biblioteka Uniwersytecka w Poznaniu">
      <exlibris>
       <img>bu-poznan.png</img>
       <link>http://lib.amu.edu.pl/</link>
      </exlibris>
     </attribute-value>
    </attribute>
   </exlibrises>
   

• The XML “attribute” element and value “rdfname” (the RDF name) indicate the publication metadata attribute the value of which will represent the bookplate; there can be many “attribute” elements.
• Next, within the framework of the “attribute” element, the “attribute-value” elements should be defined; they represent the values of the publication metadata attribute which identify bookplates. Those values are entered in the XML “value” field of the “attribute-value” element. In the example of the default configuration given above, the attribute value is “Biblioteka Uniwersytecka w Poznaniu” Recognizing that value in the publication metadata will cause an appropriate bookplate to be displayed on the publication metadata description page in the reader application (the “docmetadata” or “publication” page).  Every “attribute-value” element is responsible for one attribute value, so if we want the bookplate to be recognized by means of various name variants, a separate “attribute-value” element should be created for every name.

• In the end, the “exlibris” elements are determined in the “attribute-value” element. An “exlibris” element has to subordinate elements, “img” and “link”; the first one is the name of a graphics file (added in the first step to the /exlibris folder), and the second one indicates the link to the page to which the user will be redirected when the bookplate image has been clicked.

The “attribute, “attribute-value”, and “exlibris” elements can be defined many times, so many bookplates can be added for every determined value of a metadata attribute,

For example:

<exlibrises>
 <attribute rdfname="Rights">
  <attribute-value value="Biblioteka Uniwersytecka w Poznaniu">
   <exlibris>
    <img>bu-poznan.png</img>
    <link>http://lib.amu.edu.pl/</link>
   </exlibris>
  </attribute-value>
  <attribute-value value="BUP">
   <exlibris>
    <img>bu-poznan.png</img>
    <link>http://lib.amu.edu.pl/</link>
   </exlibris>
  </attribute-value>
  <attribute-value value="Uniwersytet im. A.Mickiewicza i Politechnika Poznańska">
   <exlibris>
    <img>uam.png</img>
    <link>http://uam.edu.pl/</link>
   </exlibris>
   <exlibris>
    <img>put.png</img>
    <link>http://www.put.poznan.pl/</link>
   </exlibris>
  </attribute-value>
 </attribute>
</exlibrises>

In that configuration, the “Biblioteka Uniwersytecka w Poznaniu” bookplate will appear for the “Permissions” attribute both when it has the “Biblioteka Uniwersytecka w Poznaniu” value and when it has the “BUP” value. Moreover, if the same “Permissions” attribute has the “Uniwersytet A. Mickiewicza i Politechnika Poznanska” value, two bookplates (images with links) will be displayed, for the Adam Mickiewicz University and for the Poznan University of Technology.

The exlibris.xml configuration will only begin to apply after the servlet environment of the reader application (Apache Tomcat) has been restarted. Incorrect settings may cause exceptions and system log errors to appear.

Configuring the JCR Backup System

In order to change the default JCR backup creation settings in the system, the user should edit the periodic.xml file in the /WEB-INF directory of the reader application. The entry concerning the appropriate periodic task is looks as follows:

<periodic-task logicClass="pl.psnc.dlibra.web.comp.periodic.JCRBackupTask" executeOnStart="yes">
		<expression>0 0 23 * * ?</expression>
		<properties>
			<property>
				<name>jcr.backup.dir</name>
				<value>[backup directory path]</value>
				<description>Path to JCR backup destination directory. Path should end with '/'.</description>
			</property>
			<property>
				<name>copies.amount</name>
				<value>[amount of copies]</value>
				<description>Specifies how many different copies of backup can be stored at once</description>
			</property>
		</properties>
		<description>Task is responsible for backup of JCR stored data</description>
</periodic-task>

Two parameters can be changed in the task: jcr.backup.dir and copies.amount. By means of the first parameter, the administrator indicates the directory in which backups are to be placed. Every single backup copy is an XML file named jcr-backup_[the date of the creation of the copy].xml, for example, jcr-backup_2010.12.25.08.00.00.xml.

The second parameter determines the maximum number of backup copies. The periodic task is carried out periodically – by default, every 24 hours. Thus, when the maximum number of copy files has been created, each subsequent file overwrites the oldest file from the jcr.backup.dir directory.

The copies.amount can have the following values:

• for parameter > 0, the task creates a specific number of backup copy files;
• for parameter = 0, the task does not create any backup copy files; and
• for parameter < 0, the task creates an unlimited number of backup copy files.

A change of parameters in periodic tasks requires a restart of the container (for example, Apache Tomcat), of the reader application.

Restoring Data from JCR Backup Copies

In order to recover data from a backup copy XML file, it should be placed in an appropriate directory. That directory is configured in the /WEB-INF/conf/jcr.properties file of the reader application, at parameter jcr.restore.dir.

A backup copy is automatically restored at a restart of the container (for example, Apache Tomcat) of the reader application.

Caution! When the data from a backup copy file have been recovered, the file is automatically removed.

Configuring Thumbnails

The “context-param” parameter from the /WEB-INF/web.xml file of the reader application is responsible for configuring the thumbnails displayed in the reader application. The file looks as follows:

<context-param>
		<description>
			...
		</description>
		<param-name>thumbnails.settings</param-name>
		<param-value>{
			"recommended": {206;232;1.0;false;image/png},
			"coll_home_recommended": {206;232;1.0;false;image/png},
			"collection_description": {390;400;1.0;false;image/png},
			"edition": {242;132;1.0;false;image/png},
			"docmetadata": {225;335;1.0;false;image/png},
			"result_item": {206;232;1.0;false;image/png},
			"example": {200;200;1.0;false;image/png}
		}</param-value>
</context-param>

The parameter values are entered between the  <param-value></param-value> tags. The parameter consists of id_miniatury:zestaw_parametrów_miniatury pairs The parameter set consists of four parts which are separated with the semicolon (;) character, so various thumbnail profiles can be defined, for example: “recomended”, “col_home_recommended”, or “collection_description”, and we can choose a suitable size of the image. The URL below illustrates the schema of the access to a thumbnail:

https://{domena}/image/{typ_obiektu}/thumbnail:{id_miniatury}/{id}

where:

• {domena} is the Internet domain of our library, for example, demo.dl.psnc.pl;
• {typ_obiektu} is the object type for which the thumbnail will be generated (for example, edition, publication, or collection);
• {id_miniatury} is the ID of the thumbnail defined in thumbnails.settings; and
• {id} is the ID of the object (edition, publication, or collection).

In the example presented above, the parameter set for the example thumbnail is: 200, 200,1.0, false, and image/png. The subsequent parts mean:

• the width of the output graphics file (in the example, it is 200 pixels);
• the height of the output graphics file (in the example, it is 200 pixels);
• the degree of the compression of the output graphics file (in the example, it is 1.0);
• whether the input graphics file is to be cropped in proportion to its dimensions (in the example, the value is “false”); and
• the format of the output graphics file (in the example, the value is “image/png”).

The first two values determine the dimensions of the output graphics file of the thumbnail for the reader application regardless of the dimensions of the input graphics file entered in the Editor Application. Thus, if the graphics file in the Editor Application has been entered in dimensions: width = 500 pixels, height = 200 pixels, then the image will be appropriately scaled in the reader application, to the dimensions configured in the “thumbnails.settings” parameter.

That can be useful when the thumbnail files entered by editors are very detailed, and that degree of detail is not necessary when they are displayed in the reader application; moreover,when the dimensions are decreased, the memory volume needed for sending them is lowered, which may accelerate the speed of the data transfer.

The next parameter is related to the last one, and it is only taken into account when the thumbnail has the “image/jpeg” format of the output graphics file. It makes it possible to further decrease the sent file, thanks to the lossy compression of the JPEG format. The optimal compression is set with the use of a floating-point number, in the (0,1) range, for example,  0.1, 0.25, or 0.3.

The next parameter determines the way in which the input image is to be adjusted to the dimensions of the thumbnail entered in the “thumbnails.settings” parameter. When the flag is set to “true”, the original graphics file will be decreased proportionally and cropped to the area defined by the first two parameters. When the flag is set to “false”, the original graphics file will be adjusted to fit in the area defined by the “thumbnails.settings” thumbnail parameters.

The last parameter determines the type of the output graphics file format of the thumbnail. The two most popular formats, JPEG and PNG, are supported. When the JPEG format is chosen, the parameter of the degree of compression (described above) is also significant. The formats are identified by MIME types. For PNG, it is “imagne/png” and for JPEG – “image/jpeg”.

A change of thumbnail display parameters requires a restart of the container (for example, Apache Tomcat), of the reader application.

Configuring the “Recommended” Component

The basic configuration of the “Recommended” component is in the /WEB-INF/components.xml file of the reader application.

Here is a sample configuration entry of the component:

<component name="pl.psnc.dlibra.web.comp.pages.components.RecommendedComponent">
	<properties>
		<property>
			<name>RecommendedId</name>
			<value>&recommendedId;</value>
		</property>
		<property>
			<name>RecommendedCount</name>
			<value>20</value>
		</property>
		<property>
			<name>reverseOrder</name>
			<value>true</value>
		</property>
	</properties>
</component>

The configuration has two basic parameters:

• RecommendedId – indicates the ID of the collection which contains recommended publications;
• RecommendedCount –  indicates how many publications are to be randomly selected for display in the component; and
• reverseOrder – reverses the default order of display

Pierwszy parametr w swoich domyślnych wartościach wstrzykuje wartość encji recommendedId, która jest deklarowana
na początku dokumentu w linii:

<!ENTITY recommendedId "3">

Domyślnie wartością encji jest '3', która wskazuje na ID automatycznie utworzonej, przy instalacji, kolekcji.
Ze wskazanej tak kolekcji losowane są publikacje, które mają być wyświetlone w komponencie, przy czym wyświetlane są wyłącznie te, które posiadają przypisaną miniaturę. W przypadku braku w kolekcji jakichkolwiek publikacji spełniających to założenie, komponent się nie wyświetli.

Zarówno wartość przypisana encji jak i wartości parametrów mogą zostać zmienione, tak aby wskazywać na kolekcje wybrane przez administratora.

Kolejny parametr RecommendedCount odpowiada za liczbę publikacji, które mają być wylosowane i prezentowane w komponencie. Jeśli komponent nie odnajdzie we wskazanej kolekcji odpowiedniej liczby publikacji z miniaturami, wyświetli te, które udało mu się odnaleźć.

Dodanie komponentu na stronę

Kolejnym krokiem konfiguracji komponentu jest dodanie go na wybraną stronę. Strony definiuje się w pliku konfiguracyjnym /WEB-INF/pages.xml Aplikacji Czytelnika. Aby dodać komponent na stronę główną, należy w dokumencie pages.xml znaleźć deklarację strony (znacznik <page>) o nazwie main.
W deklaracji tej, między znacznikami <components></components> należy umieścić wpis (domyślnie powinien on już być obecny w komentarzu w pliku):

<component name="pl.psnc.dlibra.web.comp.pages.components.RecommendedComponent">
	<place>main</place>
	<position>4</position>
</component>

Wprowadzanie zmian i konfiguracja zarówno w obszarze pliku components.xml jak i pages.xml nie wymaga zrestartowania kontenera Aplikacji Czytelnika.

Konfiguracja funkcjonalności Self-Archiving (tylko dla dedykowanych wdrożeń z włączoną funkcją Self-Archiving)

Niniejsza sekcja przedstawia konfigurację mechanizmu Self-Archiving w Aplikacji Czytelnika.

pubcreator.properties

Pierwszym plikiem konfiguracyjnym jest /WEB-INF/conf/pubcreator.properties, w którym zawarte są następujące parametry:

• class.name
• max.file.size
• upload.temp.dir
• main.files.suggesters.use
• main.files.suggesters
• default.main.files.lookup.filter.regexp(x)

Parametry class.name oraz main.files.suggesters nie podlegają zmianom.

Parametr max.file.size umożliwia administratorom wprowadzenie limitów na wielkość pliku treści tworzonych publikacji. Wielkość pliku podaje się w bajtach. Wartość 0 w tym wypadku oznacza brak limitu na wielkość.

Istotnym parametrem jest upload.temp.dir, w którym administrator ustala ścieżkę do katalogu plików tymczasowych. W katalogu tym przechowywane są pliki z treścią publikacji do momentu przesłania ich do serwera. Po zakończeniu procesu tworzenia publikacji, pliki te są automatycznie usuwane z katalogu. Jeśli użytkownik w ramach swojej sesji nie dokończy procesu tworzenia publikacji, wówczas pliki tymczasowe, przesłane przez niego do Aplikacji Czytelnika, usunie zadanie okresowe. Ustawienie tego parametru jest istotne do prawidłowego działania mechanizmu Self-Archiving.

Reszta parametrów, tj. main.files.suggesters.use, main.files.suggesters oraz default.main.files.lookup.filter.regexp(x) służy do konfiguracji opcji podpowiadania pliku głównego treści. W obecnej wersji dLibry opracowany został mechanizm podpowiadania działający w oparciu o nazwę plików. Parametry default.main.files.lookup.filter.regexp(x), gdzie x stanowią kolejne liczby ze zbioru N={0,1,...n}, określają wyrażenia regularne rozpoznające potencjalne pliki główne treści publikacji.

Konfiguracja formularza atrybutów - pubc-metadata.xml

Plik /WEB-INF/conf/pubc-metadata.xml służy do konfiguracji formularza atrybutów, który pojawia się w 2-gim kroku kreatora publikacji. W pliku tym określa się m.in. liczbę, rodzaj oraz kolejność wyświetlania atrybutów metadanych.

W podstawowej formie plik przedstawia się następująco:

<pubc-metadata>
	<attribute name="title" required="true" pname="true">
		<position>1</position>
		<rdf-name>Title</rdf-name>
	</attribute>
	<attribute name="author" required="true">
		<position>2</position>
		<rdf-name>Creator</rdf-name>
	</attribute>
	<attribute name="abstract">
		<position>3</position>
		<rdf-name>Abstract</rdf-name>
	</attribute>
	<attribute name="subject">
		<position>4</position>
		<rdf-name>Subject</rdf-name>
	</attribute>
	<attribute name="date" required="true">
		<position>5</position>
		<rdf-name>Date</rdf-name>
		<input-type name="DATE">
		</input-type>
	</attribute>
	<attribute name="licence" alias="true">
		<position>6</position>
		<rdf-name>Rights</rdf-name>
	</attribute>
	<attribute name="comments" alias="true">
		<position>7</position>
		<rdf-name>Description</rdf-name>
		<multiple>false</multiple>
		<input-type name="TEXTAREA"/>
	</attribute>
</pubc-metadata>

Głównym elementem struktury XML jest pubc-metadata, który zawiera elementy attribute reprezentujące pola w formularzu.

Każdy element attribute posiada własny zestaw elementów oraz atrybutów.

Atrybuty elementu attribute :

• name - nazwa pola w formularzu, musi być unikalna;
• required - czy pole jest wymagane;
• pname - czy pole spełnia funkcję nazwy publikacji;
• alias - czy pole jest aliasem dla atrybutu.

Elementy podrzędne elementu attribute:

• rdf-name - nazwa RDF atrybutu, na którego wartości mapowane są wartości pola;
• position - pozycja pola na wyświetlanej liście;
• multiple - czy pole może mieć przypisanych wiele wartości (domyślnie 'true');
• input-type - typ pola w formularzu.

Atrybut nazwy name elementu attribute musi być unikalny dla każdego zdefiniowanego pola. Administrator może go wykorzystać w korelacji z atrybutem alias ustawionym na 'true', domyślnie bowiem nazwa dla pola jest pobierana bezpośrednio od nazwy atrybutu metadanych dLibra, wskazanego elementem rdf-name (patrz wyżej), w tym wypadku można jednakże ustawić własną nazwę dla pola w plikach etykiet komponentu PublicationUploadComponent. Etykieta taka rozpoczyna się od prefiksu "PublicationUploadComponent" a kończy nazwą określoną w atrybucie name, np. "PublicationUploadComponent.title".
Więcej na temat etykiet można przeczytać tutaj.

Atrybut required określa czy wypełnienie pola jest wymagane do zaakceptowania tworzonej publikacji.
W sytuacji, gdy użytkownik nie wprowadzi w to pole żadnej wartości wyświetlony zostanie w kreatorze odpowiedni komunikat.
Atrybut pname określa czy dane brane z pola będą spełniały rolę nazwy dla publikacji; pole tak oznaczone tym atrybutem powinno być jednocześnie polem wymaganym. Jeśli nie istnieje żadne pole z atrybutem pname ustawionym na 'true', wówczas w trakcie tworzenia publikacji jego nazwa zostanie wzięta z pierwszego w kolejności pola wymaganego.

Pierwszym istotnym elementem podrzędnym elementu attribute jest rdf-name, który łączy wskazane pole formularza z atrybutem w schemacie metadanych biblioteki cyfrowej. Wszystkie wpisywane w pole wartości są kojarzone z konkretnym atrybutem metadanych poprzez nazwę RDF atrybutu. Przykładowymi nazwami RDF są: Title, Cretor, Abstract itp.

Element podrzędny position określa pozycję pola na liście pól formularza. Dwa dodatkowe podrzędne elementy, tj. multiple oraz input-type nie są wymagane. Pierwszy określa czy do danego pola można dodać wiele wartości (domyślnie 'true'), drugi określa jakiego typu jest pole formularza. Można wybrać spośród trzech typów: TEXT (standardowe pole tekstowe), TEXTAREA (duże pole tekstowe) oraz DATE (pole wyboru daty), które wpisuje się w atrybucie name elementu. Domyślnie dla każdego pola wybierany jest element typu TEXT.

Przykładowo:

<input-type name="DATE">
</input-type>

Jeśli zdefiniowane pole jest typu DATE wówczas można między znacznikami <input-type ...></input-type> umieścić podrzędne elementy:

• startYear - najwcześniejszy możliwy rok do wyboru (domyślnie 1945);
• endYear - najpóźniejszy możliwy rok do wyboru (domyślnie rok aktualny);
• separator - separator, który pojawia się po między poszczególnymi częściami daty (dniem, miesiącem, rokiem) w wartości atrybutu metadanych stworzonej publikacji.

Przykład konfiguracji pola daty:

<input-type name="DATE">
  <startYear>1990</startYear>
  <endYear>2010</endYear>
  <separator>:</separator>
</input-type>

Ostatnią kwestią wartą zaznaczenia jest obsługa kontrolowanych atrybutów metadanych. Pola, które w nazwie RDF odwołują się do atrybutów kontrolowanych prezentują się jako listy rozwijalne, w których użytkownik może wybrać jedną z proponowanych pozycji. Atrybuty ustawia się jako kontrolowane w Aplikacji Administratora. Więcej na ten temat można znaleźć tutaj.

Konfiguracja regulaminu

Przed przystąpieniem do dodawania publikacji każdy użytkownik jest zobowiązany do zaakceptowania regulaminu, którego treść można zmienić na potrzeby własnej biblioteki cyfrowej. Treść regulaminu znajduje się na stronie pomocy regulations i może ona zostać zmieniona w panelu administracyjnym Aplikacji Czytelnika.
Istnieje również możliwość całkowitego wyłączenia regulaminu z kreatora publikacji, wystarczy w tym celu do pliku components.xml dodać wpis dotyczący komponentu PublicationUploadComponent:

<component name="pl.psnc.dlibra.web.comp.pages.components.PublicationUploadComponent">
		<properties>
			<property>
				<name>regulationsAcceptRequired</name>
				<value>false</value>
			</property>
		</properties>
</component>

Wprowadzenie zmiany w pliku components.xml nie powinno wymagać restartu kontenera Aplikacji Czytelnika.

Inne etapy konfiguracji

Do prawidłowego działania funkcjonalności Self-Archiving potrzebne są jeszcze ustawienia w serwerze dLibra.
Konfigurację Self-Archiving w serwerze dLibra można sprawdzić tutaj.

Konfiguracja mechanizmu dodawania tagów publicznych (tylko dla dedykowanych wdrożeń z włączoną funkcją tagów publicznych)

Istnieje możliwość konfigurowania podstawowych parametrów akcji dodawania tagów publicznych. Aby to zrobić należy otworzyć plik /WEB-INF/actions.xml konfiguracji akcji. W pliku tym można odnaleźć wpis:

       <action name="pl.psnc.dlibra.web.comp.pages.actions.AddBookmarkTagAction">
		<properties>
			<property>
				<name>accept.all.tags</name>
				<value>false</value>
			</property>
			<property>
				<name>max.tag.length</name>
				<value>100</value>
			</property>
			<property>
				<name>min.tag.length</name>
				<value>3</value>
			</property>
		</properties>
	</action>

W procesie moderacji tagów publicznych są one przetrzymywane pewien okres czasu, w którym moderator może ustawić ich stan na "zaakceptowany" bądź "niezaakceptowany". Tylko zaakceptowane tagi publiczne są dodawane do atrybutu "Tagi" wybranej publikacji. Parametr accept.all.tags ustala czy przesyłana propozycja tagu publicznego ma być automatycznie ustawiana na stan "zaakceptowany", który może zostać ewentualnie zmieniony przed moderatora. Standardowo parametr accept.all.tags ustawiony jest na false co oznacza, iż dodawane tagi publiczne są domyślnie w stanie "niezaakceptowane".

Dwa kolejne parametry określają minimalną (min.tag.length) oraz maksymalną (max.tag.length) liczbę znaków przeznaczonych na tag publiczny. W przypadku, gdy tag nie spełnia wyznaczonego limitu, nie zostanie on dodany do propozycji słów kluczowych. Ustawienie któregokolwiek z tych parametrów na wartość 0 spowoduje, iż nie będzie on brany pod uwagę przy sprawdzaniu liczby znaków tagu.

Konfiguracja wyświetlania zabezpieczonych plików PDF

Omawiana konfiguracja umożliwia precyzyjniejsze określenie zabezpieczenia w wyświetlanym przez Aplikację Czytelnika dokumencie PDF.
Aby rozpocząć modyfikację parametrów zabezpieczania plików PDF należy wyświetlić do edycji plik settings.xml z katalogu /WEB-INF/formats/pdf.
Plik ten powinien zawierać wpisy:

<properties>
<!--
 In case of any problems with securing PDF files you may try to use alternative format writer based on iText.
-->
<!--
 <entry key="secured.format.writer.class">pl.psnc.dlibra.web.comp.formats.writers.ItextSecuredPdfFormatWriter</entry>
-->
<entry key="secured.format.writer.class">pl.psnc.dlibra.web.comp.formats.writers.SecuredPdfFormatWriter</entry>
<entry key="handler.id">pdf:secured</entry>
<entry key="handled.mime.types">application/pdf</entry>
<entry key="handles.secured">true</entry>
<entry key="handles.normal">false</entry>
<entry key="owner.pass"></entry>
<entry key="user.pass"></entry>
<entry key="print.degraded">true</entry>
<entry key="print">false</entry>
<entry key="modify.annotations">false</entry>
<entry key="fill.in.form">false</entry>
<entry key="extract.for.accessibility">false</entry>
<entry key="assemble.document">false</entry>
<entry key="extract.content">false</entry>
</properties>

Podstawowymi parametrami są owner.pass oraz user.pass, które określają kolejno: hasło właściciela dokumentu PDF oraz hasło użytkownika dokumentu PDF, które będzie zobowiązany wprowadzić, jeśli dokument można w jakiś sposób modyfikować.
Z pozostałych parametrów można wymienić (pomijając ogólne parametry konfiguracji mechanizmu wyświetlania):

• assemble.document - parametr określa czy użytkownik może w zabezpieczonym pliku modyfikować strony, tj. obracać, usuwać i dodawać nowe
• print.degraded - określa czy użytkownik może drukować dokument w zubożonej jakości
• print - określa czy użytkownik może drukować dokument
• modify.annotations - określa czy użytkownik może modyfikować adnotacje w tekście lub wypełniać danymi interaktywne formularze
• fill.in.form - określa czy użytkownik może wypełniać danymi interaktywne formularze.
• extract.for.accessibility - określa czy można pobierać treść w dokumencie na potrzeby dostępności dla osób niewidomych
• extract.content - określa czy użytkownik może zaznaczać i kopiować treść dokumentu
• modify - określa czy użytkownik może modyfikować pobrany dokument

Wszystkie wymienione w liście parametry przyjmują wartości typu boolean (true|false).

Zmiana parametrów wymaga restartu kontenera Aplikacji Czytelnika (tj. Apache Tomcat).

Konfiguracja kolekcji głównej dla Aplikacji Czytelnika

Od wersji 5.0 administratorzy mają możliwość wskazania dowolnej kolekcji, spośród istniejących w bibliotece cyfrowej, która będzie spełniała rolę kolekcji głównej. Opcja ta idzie w parze z możliwością podłączenia wielu Aplikacji Czytelnika pod pojedynczy Serwer dLibra. Aby skonfigurować dla danej Aplikacji Czytelnika jej kolekcję główną wystarczy otworzyć do edycji plik /WEB-INF/web.xml, w którym znajduje się następujący wpis (domyślnie w komentarzu XML):

<context-param>
	<description>
		Configurable main dLibra collection id
	</description>
	<param-name>main.collection.id</param-name>
	<param-value>[id of collection]</param-value>
</context-param>

Wpis należy "odkomentować" zaś w miejsce [id of collection] należy wrzucić numeryczne ID kolekcji (unikalne ID ustawiane w bazie danych kolekcji). Po wszystkim należy zrestartować środowisko serwletów (np. Tomcat).

Zmiany w formularzu "Kontakt"

Aby zmienić domyślne wartości kontaktowe w formularzu należy otworzyć do edycji pliki WEBAPP_en.xml (dla języka angielskiego) oraz WEBAPP_pl.xml (dla języka polskiego), z katalogu /WEB-INF/components/resources. W plikach tych można znaleźć wpisy w postaci:

<entry key="ContactComponent.Name">Instytucja partnerska BC</entry>
<entry key="ContactComponent.Address">ul. Nieznana 16, 61-895 Poznań, POLSKA</entry>
<entry key="ContactComponent.URL">http://institution.com/</entry>
<entry key="ContactComponent.Mail">mail@institution.com</entry>
<entry key="ContactComponent.Phone">telefon: (+48) 61-333-33-32, faks: (+48) 61-333-33-33</entry>

Łatwo zauważyć, iż poszczególne wartości dla elementów XML odpowiadają wartościom z formularza. Zmiany w tych plikach nie wymagają ponownego uruchomienia kontenera serwletów.

Inną rzeczą, o której warto pamiętać w kontekście formularza kontaktu, jest adres mail, na który wysyłane są wpisane przez użytkownika wiadomości. Adres ten można skonfigurować w pliku /WEB-INF/actions.xml, zmieniając wartość dla deklarowanej akcji SendMailAction:

<action name="pl.psnc.dlibra.web.comp.pages.actions.SendMailAction">
	<properties>
		<property>
			<name>to.web.mail</name>
		   	<value>[adresy mail, na ktory maja byc wysylane zgloszenia]</value>
		</property>
		    ...
	</properties>
</action>

Między znacznikami value można umieścić dowolną liczbę adresów mail oddzielonych średnikami lub przecinkami.

Ustawienia obsługi znaków wodnych (tylko dla dedykowanych wdrożeń z włączoną funkcją tagów publicznych)

Znaki wodne wyświetlane są dla zabezpieczonych prezentacji JPG (specjalny typ publikacji w dLibrze, który tworzy się poprzez wskazanie jako plik główny katalogu zawierającego pliki JPG). Odbywa się to za pomocą specjalnego appletu Java.

Znak wodny to obrazek, który jest nakładany na wyświetlaną treść prezentacji z efektem przezroczystości. Zalecamy wykorzystać grafikę w formacie PNG, który pozwala zapisać obraz z przezroczystym tłem. Obrazek ten jest zawsze powiększany tak, aby zajmował maksymalną powierzchnię. Nie jest jednak rozciągany do proporcji głównego obrazu, tylko wyśrodkowany. Można jednak uzyskać efekt znaku wodnego mniejszego niż główny obraz, poprzez dodanie przezroczystego obramowania o wybranej szerokości w grafice znaku wodnego.

Oprócz obrazka, w znaku wodnym może być automatycznie wstawiona nazwa zalogowanego użytkownika. Konfiguracja znaków wodnych znajduje się w pliku WEB-INF/web.xml, w sekcji poświęconej servletowi watermarkServlet. Można tam zdefiniować następujące parametry:

• image.path - sadaścieżka do obrazka, który ma być wyświetlany jako znak wodny
• opacity - siła efektu przezroczystości, musi być liczbą z przedziału (0, 1). 0 - znak niewidoczny, zupełnie przezroczysty, 1 - znak zupełnie przesłania treść
• text.userName.position - pozycja wskazuje lewy górny róg prostokąta, w którym będzie wpisana nazwa użytkownika. Pozycja jest podawana jako współrzędne w ramach obrazka znaku wodnego, przy czym punkt 0,0 to lewy górny róg obrazka.
• text.userName.size - wielkość prostokąta, w który będzie wpisana nazwa użytkownika, również w stosunku do rozmiaru znaku wodnego. Jeśli wielkość czcionki nie jest zdefiniowana, zostanie automatycznie ustawiona maksymalna wielkość, która pozwoli zmieścić nazwę w tym prostokącie.
• text.userName.align - położenie nazwy użytkownika w ramach zdefiniowanego prostokąta. Możliwe wartości: left (na lewo), center (na środku), right (na prawo).
• text.userName.wordwrap - wartość true/false, pozwala włączyć zawijanie tekstu w przypadku długich nazw użytkownika.
• text.userName.font - czcionka nazwy użytkownika. Dostępne czcionki są zależne od czcionek zainstalowanych na komputerze użytkownika, ale zwykle można wykorzystać czcionki Arial, Courier New, Monospaced, Verdana, Tahoma.
• text.userName.font.style - pozwala włączyć pogrubienie i pochylenie w nazwie użytkownika.
• text.userName.font.color - kolor nazwy użytkownika, w formacie szesnastkowym.
• text.userName.font.size - wielość czcionki. Jeśli nie jest zdefiniowana, zostanie wybrana maksymalna wielkość, przy której zmieści się cała nazwa.

Udostępnianie Mapy Strony robotom indeksującym

Mapa Strony(Sitemap) jest protokołem umożliwiającym robotom indeksującym łatwiejsze zgromadzenie informacji o najważniejszych stronach w Aplikacji Czytelnika. Aplikacja Czytelnika w ramach zadania okresowego SitemapGeneratingTask generuje bezwzględne adresy url do nich i zapisuje je według poniższych założeń:

• /sitemap/ - Katalog, w którym zapisywane są wszystkie pliki zawierające adresy do najważniejszych stron Aplikacji Czytelnika. Pliki dzielone są w taki sposób, by nie przekroczyć 50 000 adresów.
• sitemapindex.xml - Plik, w którym agregowane są ścieżki do wszystkich plików znajdujących się w katalogu /sitemap/.
• robots.txt - Plik, który zawiera niezbędne informacje dla robotów indeksujących. Zadanie okresowe SitemapGeneratingTask dodaje do niego linię z bezwzględnym adresem url do pliku sitemapindex.xml. Np. Sitemap: {domena}/sitemapindex.xml.

Aby zmienić domyślne ustawienia generowania mapy strony należy wyedytować plik periodic.xml znajdujący się w katalogu /WEB-INF Aplikacji Czytelnika. Wpis dotyczący odpowiedniego zadania okresowego przedstawia się następująco:

	<periodic-task logicClass="pl.psnc.dlibra.web.comp.periodic.SitemapGeneratingTask"
		 executeOnStart="yes" >
		<description>Generates sitemap.</description>
		<expression>0 0 0 1/10 * ?</expression>
		<properties>
			<property>
				<name>urlParams</name>
				<value>Title;Creator</value>
			</property>
			<property>
				<name>overwriteRobotsFile</name>
				<value>true</value>
			</property>
		</properties>
	</periodic-task>

W zadaniu można ustawić wartości następujących parametrów:

• urlParams - Nazwy RDF atrybutów metadanych, których wartości, w przypadku publikacji i wydań, zostaną dodane do adresu url. Dla przykładowej wartości parametru urlParams: Title;Creator możemy spodziewać się następującego wyniku w przypadku pozycji "Pan Tadeusz": {domena}/publication/100/pan-tadeusz-adam-mickiewicz
• overwriteRobotsFile - Informacja o tym czy zadanie okresowe SitemapGeneratingTask ma nadpisywać linię "Sitemap" w pliku robots.xml. Możliwe wartości to true lub false. W przypadku wartości ustawionej na false, należy pamietać aby dodać w pliku robots.txt wartość "Sitemap" ręcznie.

Obsługa publikacji linkujących

Publikacje linkujące pozwalają na umieszczenie w bibliotece cyfrowej informacji o obiekcie, który jest udostępniany przez jakiś inny serwis internetowy. W domyślnej konfiguracji, gdy użytkownik chce zobaczyć treść takiej publikacji, najpierw zobaczy planszę z informacją o zewnętrznej treści oraz docelowym linkiem, który musi wywołać. Jeśli nie chcemy, aby ta plansza była wyświetlana, tylko żeby użytkownik od razu został przekierowany na docelowy adres, należy dodać poniższą konfigurację w WEB-INF/components.xml:

    <component name="pl.psnc.dlibra.web.comp.pages.components.ContentBrowserComponent">
        <properties>
            <property>
                <name>linkedPublication</name>
                <value>redirect</value>
            </property>
        </properties>
    </component>