[Kobv-opus-tester] zusätzliches Suchfeld
Sascha Szott
szott at zib.de
Don Sep 27 17:29:18 MEST 2012
On 27.09.2012 16:52, Annegret Baade-Kelishani wrote:
> Ich glaube, Sie meinen die Datei solr.xslt.
Ja genau, die meine ich.
>> Wenn ich die Email hier eintrage,
>> <xsl:for-each select="/Opus/Opus_Document/PersonAuthor">
>> <xsl:element name="field">
>> <xsl:attribute name="name">author</xsl:attribute>
>> <xsl:value-of select="@FirstName" />
>> <xsl:text> </xsl:text>
>> <xsl:value-of select="@LastName" />
>> <xsl:text> </xsl:text>
>> <xsl:value-of select="@Email" />
>> <xsl:if test="position()!=last()">
>> <xsl:text> ; </xsl:text>
>> </xsl:if>
>> </xsl:element>
>> </xsl:for-each>
>
> wird sie auch gefunden, das klappt gut. Nachteil ist allerdings, dass
> sie dann in der Listenanzeige in der Frontdoor auch angezeigt wird
das liegt daran, dass das Indexfeld 'author' sowohl für die Suche als
auch die Anzeige verwendet wird. Sie könnten aber folgendes Vorgehen
wählen: statt die E-Mail-Adresse mit in das XML-Element <field
name="author"> zu schreiben, erzeugen Sie ein neues XML-Element <field
name="text">. In dieses Feld (kann auch mehrfach vorkommen) können Sie
nun alle Inhalte schreiben, die in der einfachen Suche durchsucht werden
sollen. Die Feldinhalte werden aber an keiner Stelle innerhalb der
Webapplikation ausgegeben.
Beispiel:
<xsl:for-each select="/Opus/Opus_Document/PersonAuthor">
<xsl:element name="field">
<xsl:attribute name="name">text</xsl:attribute>
<xsl:value-of select="@Email" />
</xsl:element>
</xsl:for-each>
Nach dieser Anpassung *müssen Sie eine Reindexierung durchführen*. Dazu
rufen Sie im Verzeichnis $BASEDIR/opus4/scripts das PHP-Skript
SolrIndexBuilder.php auf. Je nach Dokument- und Volltextanzahl kann das
eine Weile dauern…
Noch die Warnung: Sie müssen in Zukunft bei jedem OPUS4-Update die Datei
solr.xslt händisch pflegen, da das Updateskript nicht annimmt, dass Sie
die Datei angepasst haben.
>> Wer ruft denn in ihrem Szenario den
>> Export auf? Der Client (Browser des Benutzers) per AJAX oder das CMS,
>> das die Publikationslisten im Hintergrund bereits erzeugt und dann
>> serverseitig nur noch in die Seite "einhängt"? Im zweiten Fall könnte
>> man durchaus die Suche nach E-Mail-Adressen als privilegierte Funktion
>> betrachten, die nur ausgewählte Benutzer durchführen dürfen. Dann würde
>> man dem CMS-Prozess mit den erforderlichen Rechten für diese Operation
>> ausstatten.
> Zur Zeit das CMS. Von daher wäre es für mich natürlich auf jeden Fall
> schon mal ein Fortschritt, wenn ich wüsste, wie man solch eine
> privilegierte Funktion einrichten würde. Flexibler wäre man aber, wenn
> auch der Weg über AJAX möglich wäre, man weiß ja nie, welche Anforderung
> als nächstes kommt ...
Sie legen eine neue User-Rolle, z.B. cms, an und geben dieser das Recht
das Modul 'export' aufrufen zu können. Anschließend weisen Sie der Rolle
eine IP-Adresse (des Rechners, auf dem das CMS läuft bzw. der Job, der
die Ausgabe für das CMS generiert) zu. Der Rolle guest entziehen sie nun
den Zugriff auf das Modul. Nun kann der Export nicht mehr von jedem
beliebigen Benutzer aufgerufen werden.
Dieses Vorgehen verhindert aber nicht, dass jemand über die einfache
Suche nach einer Mailadresse sucht. Sie können also bislang nicht
einstellen, dass nur bestimmte User-Rollen auf bestimmte Suchfelder
zugreifen können.
AJAX ist auch jetzt schon möglich. Die Frage ist nur, wie performant das
am Ende ist. Die Erzeugung eines XML-Exports kann je nach Größe einige
Sekunden dauern. In jedem Fall müssten Sie aber bei dieser Variante
wieder allen den Zugriff auf das Modul 'export' gestatten.
Beste Grüße,
Sascha Szott
--
Sascha Szott :: KOBV/ZIB :: <szott at zib.de> :: +49 30 84185-457