Exalead:CloudView - Verfeinerungen werden bei neuer Suche nicht zurückgesetzt

[aVogt]

Hallo,

ich habe folgendes Problem mit Exalead:CloudView

Nach einer Suche werden die Suchergebnisse eingeschränkt (das Merkmal ist eine Kategorie).
Danach soll eine neue Suche ausgeführt werden. Über folgenden Link habe ich gehofft, alle Einschränkungen zurückzusetzen:
http://[URL]?redirectUrl=index.jsperrorUrl=index.jsp%3Ferror&q=

Das funktioniert aber nicht. Bei einer neuen Suche wird immer die vorherige Einschränkung der Suchergebnisse wieder angezeigt.

Also:
1. Suche: Suche nach xyz
2. Verfeinerung: Verfeinerung der Suchergebnisse z.B. nach Abteilung abc
3. Suchformular aufrufen
4. Suche nach fgh
5. Suchergebnis ist bereits nach der Abteilung abc eingeschränkt.

Wie kann ich die Einschränkungen bei einer neuen Suche zurücksetzen?

Grüße
Andreas

[marro]

Hallo Andreas,

eigentlich werden die Verfeinerungen bei jeder neuen Suche automatisch zurückgesetzt, es sei denn bei der Suche werden die bisher getätigen Verfeinerungen z.B. in einem Hidden-Feld dem Suchformular mitgegeben oder irgendwo in der Session persistiert und dann erneut ausgegeben. Wird das Suchservlet wie von Dir beschrieben nur mit redirectUrl und Query aufgerufen (und enthält die Query nur ein simples Suchwort ohne weitere Einschränkungen), dann sind die Verfeinerungen bei der Antwort auf diese Anfrage auf jeden Fall zurückgesetzt.

Ich vermute, dass bei euch irgendwo noch eine Logik implementiert ist, die die Verfeinerungen von einer Suchanfrage zur nächsten übernimmt.

Viele Grüße

Donato

[aVogt]

Hallo Donato,

in einem Hiddenfeld wird nichts gespeichert.

Als einzige Verfeinerung wird bei jedem Suchaufruf die Quelle mit angegeben:

z.B: (Urlaub) (corporate/tree:"Top/Source/SAB_Intranet").

Eigenartiger Weise funktioniert das Rücksetzen der Verfeinerungen auf unserer Internetseite (da wird aber noch Exalead one - 4.6 verwendet - mit dem entsprechenden Modul).

Der einzige Unterschied den es zwischen den Suchen gibt: Im Internet wird die Quelle nicht per JavaScript zu dem Suchstring hinzugefügt, sondern per redirekt im Template.

Hast Du eine Idee, in welchem die Verfeinerung in der Session stehen könnte? Irgendwie muss ja darauf dann in der Suchausgabe zugegriffen werden?

Grüße

Andreas

[marro]

Hallo Andreas,

ich muss meine Aussage von vorhin korrigieren: Die Verfeinerungen werden auf jeden Fall zurückgesetzt, wenn die Suche per POST-Request abgeschickt wird und nichts weiter angegeben wird. Bei einem GET-Request werden die Verfeinerungen beibehalten (in der Session-Variable "context" gespeichert). Diese Umstellung von Modulversion 1.x zu 2.x war notwendig, weil die Verfeinerungen in Exalead Cloudview ein wenig anders funtionieren als noch in Exalead one.

Viele Grüße

Donato

[aVogt]

Hallo Donato,

das mit dem "post" scheint schon mal ein guter Hinweis zu sein.

Aber. Wenn ich etwas suche wird mir erst eine leere Seite angezeigt. In den Tomcatlogs wird nichts protokolliert. Aktualisiere ich die Seite (F%) wird mir das neue Suchergebnis angezeigt.

Nehme ich die automatische Anmeldung heraus (<fsp:authorize force="false" />) funktioniert es ohne Probleme, da werden die verfeinerungen gelöscht.

Mit automatischer Anmeldung werden zwar auch die Verfeinerungen gelöscht, aber erst nach "F5" 😞

An was könnte das nun wieder liegen, hast Du eine Idee?

Grüße

Andreas

[marro]

Hallo Andreas,

ich fasse nochmal zusammen, um sicher zu sein, dass ich das jetzt richtig verstanden habe: Eine Suche ohne authorize-Tag zeigt sofort die Suchergebnisse und die Verfeinerungen sind zurückgesetzt. Eine Suche mit authorize-Tag zeigt zunächst eine leere Seite. Erst nach F5 werden die Suchergebnisse angezeigt und die Verfeinerungen sind zurückgesetzt. Ist das richtig?

Wird der User denn durch das Authorize-Tag authentifiziert? Ist er nach dem Aufruf der Seite also angemeldet? Falls ja würde es mich wundern, wenn auch danach noch eine Suche zunächst eine leere Seite anzeigt. Denn wenn ein User angemeldet ist, macht das Authorize-Tag im Grunde überhaupt nichts (wenn force="false" ist). Nur wenn kein Benutzer angemeldet ist, versucht das Tag eine Authentifizierung. Es ist durchaus möglich, dass das Tag je nach Konfiguration der Personalisierung und verwendetem Browser aus irgendeinem Grund hängenbleibt. Das sollte dann allerdings auch unabhängig von der Suche der Fall sein.

Grüße

Donato

[aVogt]

Hallo Donato,

Du hast richtig verstanden.

So sieht der test aus:

1. mit <fsp:authorize force="false" /> am Anfang jeder Seite

- alle offenen Browser schließen
- Seite aufrufen (automatische Anmeldung - Nutzer wird angemeldet)
- Suchen
- leere Seite
- F5
- Anzeige Suchergbnisse
- Suchergebnisse verfeinern
- neuen Suchbegriff eingeben
- leere Seite
- F5
- Anzeige Suchergbnisse (Verfeinerungen aufgehoben)

2. ohne <fsp:authorize force="false" />

- alle offenen Browser schließen
- Seite aufrufen (keine automatische Anmeldung - kein Nutzer angemeldet)
- Suchen
- Anzeige Suchergbnisse
- Suchergebnisse verfeinern
- neuen Suchbegriff eingeben
- Anzeige Suchergbnisse (Verfeinerungen aufgehoben)

Wenn ich mich ganz dunkel erinnere bin ich genau aus diesem grund (leere Seite) bei dem Suchformular auf get umgestiegen (entweder hatte ich das mit dem Helpdesk geklärt oder hier ..., hab nur grad wenig Zeit danach zu suchen).

>Wird der User denn durch das Authorize-Tag authentifiziert? Ist er nach dem Aufruf der Seite also angemeldet?

Das ist der Fall. Der Nutzer wird angemeldet und bleibt es auch.

> Es ist durchaus möglich, dass das Tag je nach Konfiguration der Personalisierung und verwendetem Browser aus irgendeinem Grund hängenbleibt. Das sollte dann allerdings auch unabhängig von der Suche der Fall sein.

Bis jetzt hat sich noch niemand gemeldet, dass es irgendwo beim normalen navigieren zu so einem Problem kommt. Die automatische Anmeldung wird in zwei Projekten verwendet.

Grüße

Andreas

[marro]

Danke für die genaue Schilderung. Dann hatte ich das doch nicht ganz richtig verstanden. Ich war davon ausgegangen, dass die Authentifizierung erst nach der ersten Suchanfrage durchgeführt werden würde. Also scheint die Authentifizierung schon mal ok zu sein. Ich hab nur leider keine Idee, woran es sonst liegen könnte. Eventuell ein Caching-Problem? Wenn die Ergebnisse nach einem F5 angezeigt werden, kann die Suche an sich auch nicht das Problem sein, denn eine Aktualisierung der Seite lädt ja nur die Seite neu. Die Suche hat aber bereits einen Schritt vorher stattgefunden und wird durch F5 nicht erneut ausgeführt.

Wurde denn darauf geachtet, das Authorize-Tag ganz an den Anfang der Seite zu packen? Es darf sich kein HTML vor dem  Authorize-Tag befinden (auch keine HTML-Kommentare).

Grüße

Donato

[aVogt]

Der Anfang der JSP-Datei sieht bei mir wie folgt aus:

<%@ page language="java" contentType="text/html; charset=UTF-8" %>

<%@ page import="java.io.*,

        java.lang.*,

        java.net.*,

        java.text.*,

        java.util.*"%>

<%@ page import="de.sachsen.sab.it.common.exalead.ExaleadUtil"%>

<%@ taglib prefix="search" uri="/WEB-INF/exalead.tld" %>

<%@ taglib uri="/WEB-INF/firstpersonalisation.tld" prefix="fsp" %>

<fsp:authorize force="false" />

Ich habe auch die beiden Zeile:

<%@ taglib uri="/WEB-INF/firstpersonalisation.tld" prefix="fsp" %>

<fsp:authorize force="false" />

ganz an den Anfang gestellt. Es kommt zum selben Verhalten mit der leeren Seite.

Grüß

Andreas

[marro]

Hmm, es ist schwierig, das Problem hier auf eine bestimmte Komponente einzugrenzen.

Hier noch ein paar vage Ideen:

• Erscheint die leere Seite auch, wenn die Suche mit dem alten Modul (1.x) und exalead enterprise:one durchgeführt wird?
• Vielleicht hilft ein <meta http-equiv="expires" content="0"> um ein automatisches Neuladen der Seite zu forcieren.
• Ist das Problem Browser-unabhängig?
• Man könnte testweise per JSP-Code prüfen, ob bereits ein Benutzer angemeldet ist (Session-Attribut "FIRSTpersonalisation.user") und in diesem Fall das Authorize-Tag nicht in die Seite schreiben.

Viele Grüße

Donato