Solr Powered ISFDB – Teil #7: Einfache Benutzeroberfläche
Dies ist Teil 7 einer (nicht enden wollenden?) Serie von Artikeln über die Indizierung und Suche der ISFDB.org-Daten mit Solr.…
Dies ist Teil 7 einer (nicht enden wollenden?) Serie von Artikeln über die Indizierung und Suche der ISFDB.org-Daten mit Solr.
Als wir uns das letzte Mal trennten, hatte ich die Pseudonym-Informationen für Autoren hinzugefügt, so dass alle wichtigen Informationen, nach denen man bei der Suche nach Autoren oder Titeln suchen kann, ziemlich gut abgedeckt waren. Diese Woche werde ich das Thema wechseln und ein wenig über eines der Dinge sprechen, an denen ich am wenigsten gerne arbeite: Benutzeroberflächen.
(Wenn Sie zu Hause mitarbeiten möchten, können Sie den Code auf github auschecken. Ich beginne mit dem blog_6-Tag und werde im Laufe des Artikels auf bestimmte Commits verweisen, in denen ich etwas geändert habe, bis hin zum blog_7-Tag, der das Endergebnis dieses Artikels enthält).
Haftungsausschluss #1: Ich bin kein UI-Typ
Zunächst einmal sollte ich klarstellen, dass ich nicht wirklich gerne an UI-Zeug arbeite. Ich bin am glücklichsten, wenn ich einfach nur am Backend-Code hacke, der Daten verarbeitet und strukturiert zurückgibt – so dass andere Leute UI-Code schreiben können, um sie auf hübsche Weise anzuzeigen. Abgesehen davon sind Benutzeroberflächen natürlich wichtig, und bei der Arbeit mit Suchcode/Daten ist es wichtig, einen einfachen Mechanismus zu haben, mit dem man sich die Daten, mit denen man arbeitet, während der Iteration genau ansehen kann. Ich lese gerne XML-Rohdaten, wenn ich mit Solr arbeite, aber bei der Optimierung der Relevanz und der Anpassung von Konfigurationen können Sie oft viel schneller arbeiten, wenn Sie eine einfache Benutzeroberfläche haben (selbst wenn es nur ein schneller Prototyp ist), mit der Sie die Ergebnisse und die Anzahl der Facetten leicht einsehen können.
Solr verfügt über ein Plugin namens Solritas, mit dem Sie direkt in Solr mithilfe von Velocity-Vorlagen Benutzeroberflächen erstellen können. Da ich eine einfache Benutzeroberfläche benötige und mich mit Velocity nicht auskenne, scheint dies eine gute Wahl zu sein, um heute eine einfache Benutzeroberfläche zu erstellen. (und dabei ein paar Dinge zu lernen)
Haftungsausschluss #2: Trennung von Logik und UI
Ich bin der festen Überzeugung, dass eine gute Anwendung eine klare Trennung zwischen der Anwendungslogik und der Präsentation der Ergebnisse haben sollte. Zwar haben viele Leute mit Solritas einige sehr schöne Benutzeroberflächen für Solr erstellt, aber ich persönlich halte es für keine gute Idee, dass Solr Webseiten generiert, die von den Benutzern direkt konsumiert werden. Ich betrachte Solr als einen DataStore – ein Repository für Daten/Logik. Ich behandle ihn genauso wie eine Datenbank, ein NoSql-Repository oder ein lokales Dateisystem. Ich möchte, dass er von meinen Benutzern abgeschottet ist und dass sie ihn über eine Anwendungsschicht nutzen, die in ihrem Namen mit Solr kommuniziert.
Davon abgesehen: Es hat sicherlich Vorteile, wenn Sie Solr direkt eine HTML-basierte Benutzeroberfläche für sich erstellen lassen. Bei der Erstellung von Prototypen, Proof of Concepts, internen Tools usw. kann es durchaus praktisch sein, ein bewegliches Teil weniger in Ihrem System zu haben. Und für die Zwecke dieses Blogs, in dem es in erster Linie darum geht, Solr-Funktionen kennenzulernen und zu demonstrieren, gibt es kaum einen Nachteil.
Es sollte auch angemerkt werden, dass es in Solr bereits eine gute Trennung zwischen Logik und Präsentation gibt. Solritas ist als QueryResponseWriter implementiert, der Zugriff auf die Solr-Antwort hat, nachdem der SolrRequestHandler sie verarbeitet hat. Es ist wahrscheinlich möglich, dass eine Velocity-Vorlage Logik und Datenverarbeitung enthält, aber dazu müssten Sie sich schon sehr anstrengen. Solange Sie bei der Implementierung Ihrer Velocity-Vorlagen also eine Trennung der Bereiche im Auge haben, sollte eine spätere Neuimplementierung in einer anderen Anwendung (unter Verwendung der Ausgabe eines anderen QueryResponseWriters) völlig problemlos möglich sein.
Ok, genug der Haftungsausschlüsse. Es ist Zeit, anzufangen.
Schritt #1: Wiederverwendung einiger Vorlagen
Als ich heute Morgen aufstand, wusste ich so gut wie nichts über den VelocityResponseWriter (oder Velocity!). Was ich wusste, war, dass Sie ihn in Ihrer solrconfig.xml deklarieren und dann auf einige Velocity-Vorlagen verweisen. Für den Anfang habe ich also die vorhandenen Vorlagen aus den VelocityResponseWriter-Beispielkonfigurationen kopiert und die grundlegenden Änderungen an der solrconfig.xml vorgenommen, um sie zu verwenden. Beachten Sie, dass ich auch meine build.xml leicht modifiziert habe, um die Jars, die ich benötige, in mein lib-Verzeichnis zu kopieren.
Das Ergebnis war nicht die schönste Benutzeroberfläche der Welt, aber nicht schlecht, wenn man bedenkt, dass ich keinen Code schreiben/ändern musste…
Ohne mir die Beispielvorlagen anzusehen oder etwas über die Velocity-Syntax zu lernen, konnte ich einige Verbesserungen vornehmen, indem ich einfach meine solrconfig.xml und schema.xml änderte. Ich begann mit dem Hinzufügen einiger Standard-Facetten. Dadurch erhielt ich eine schnelle und schmutzige linke Navigation mit einigen Facetten-Links, so dass ich auf einen Blick sehen kann, wie die verschiedenen Dokumente organisiert sind, aber es zeigte auch einige Einschränkungen in den Vorlagen, die ich kopiert hatte:
- Sie scheinen die Anzahl der „facet.query“ standardmäßig nicht anzuzeigen.
- Die Vorlage scheint „/itas“ fest einprogrammiert zu haben (der Pfad, unter dem sie in der Beispiel-Solrconfig.xml registriert wurde), was bedeutet, dass die Facettenlinks und das Suchfeld nicht funktionieren, da ich einen anderen Namen für den Request Handler gewählt habe
Jetzt hätte ich mich in die Arbeit stürzen und versuchen können, diese Dinge zu beheben, aber ich weiß zufällig, dass viel Arbeit in die Verbesserung dieser Vorlagen für die nächste Version von Solr gesteckt wurde. Ich war mir ziemlich sicher, dass ich auch ohne ein Upgrade von Solr in der Lage sein würde, nur die Vorlagen zu aktualisieren und all ihre Verbesserungen zu nutzen. Also habe ich es ausprobiert, und die Dinge wurden definitiv visuell ansprechender…
…aber es gab immer noch einige Probleme…
- Die neueren Vorlagen haben fest kodierte Feldnamen für die Anzeige
- Meine Abfrage-Facetten zum Herausfiltern von Pseudo-Autoren wurden angezeigt, aber sie erschienen zweimal (einmal im Bereich Facettierung?)
- In den neuen Vorlagen war der Pfad für den Request Handler immer noch fest codiert, aber jetzt ist er fest codiert in „/browse“.
…also war es an der Zeit, mir die Hände schmutzig zu machen und Geschwindigkeit zu lernen!
Schritt #2: Vorlagen anpassen
Ich begann damit, die Anzeige der einzelnen Ergebnisse zu ändern, damit ich die gewünschten Felder zurückerhalten konnte. Als ich im Velocity-Verzeichnis herumstöberte, fand ich heraus, dass die Vorlage, die für die Erstellung der einzelnen Dokumente verantwortlich ist, „doc.mv“ heißt (ich habe sie gefunden, indem ich nach „Price:“ gesucht habe, da dies hart kodiert zu sein schien). Das erste, was mir auffällt, ist, dass Geschwindigkeitsdirektiven ein „#“-Präfix zu verwenden scheinen und alles andere wie normales HTML aussieht … mit Ausnahme von Echo-Variablen und Funktionsausgaben, die „$“ zu verwenden scheinen … na ja. Ich dachte mir, ich fange einfach an, auf den Dingen herumzuhacken, und irgendwann habe ich den Dreh raus. (es stellte sich heraus, dass man mit „#“ auf Makros verweist und mit „$“ auf Objekte, die Methoden haben können)
Ich habe mit etwas Einfachem begonnen: dem Herausreißen der „More Like This“-Links. Ich habe vor, „More Like This“ irgendwann einmal zu zeigen, aber nicht heute. (Es ist besonders interessant, dass diese MLT-Links anscheinend ausgeblendet werden sollten, wenn kein spezieller Parameter angegeben wurde, aber bei mir wurden sie immer angezeigt … ein Grund mehr, sie herauszureißen). Ich habe auch das Div „result-title“ aktualisiert, so dass es statt des Feldes „name“ die Felder „title“ und „canonical_name“ gefolgt von doc_type anzeigt. Auf diese Weise hätte ich immer eine gute „Überschrift“ für jedes Element, unabhängig vom doc_type. (Letztendlich wollte ich die Anzeige vom „doc_type“ abhängig machen, aber ich habe mit kleinen Schritten begonnen).
Ich habe gleich zu Beginn einige Probleme entdeckt. Offenbar hatte ich einige Titeldokumente ohne ein Feld „Titel“. Ich bin mir nicht sicher, wie das passiert ist, aber ich habe eine schnelle Abfrage verwendet, um alle TITLE-Dokumente zu finden , und habe danach gesucht, ob sie einen Begriff im Feld title enthalten. Offensichtlich habe ich vor einiger Zeit einen Fehler eingeführt und ihn nicht bemerkt.
Als ich mir meine DIH-Konfiguration ansah, stellte ich fest, dass ich den „Titel“ definitiv als „imdb_url“-Feld indiziert hatte … offensichtlich ein dummer Cut/Paste-Fehler, den ich vor einiger Zeit gemacht und bis jetzt nicht bemerkt hatte. Stellen Sie sich das mal vor. Nachdem ich das behoben hatte, konnte ich weitere Verbesserungen an den Feldern vornehmen, die für jeden meiner doc_types angezeigt wurden (und die Präsentation auf der Grundlage des Dokumenttyps steuern).
All diese Änderungen habe ich vorgenommen, indem ich mich durch die Velocity-Syntax gekämpft habe, indem ich die vorhandenen Vorlagen als Beispiele verwendet habe und indem ich wusste, dass es sich unter der Haube um Java-Objekte handelt. Ich bin sicher, ein Velocity-Experte würde sagen, dass meine Änderungen sehr klobig und übermäßig kompliziert waren – aber so weit, so gut.
Schritt #3: Aufräumen
Jetzt hatte ich also eine sehr rudimentäre Anzeige, aber in der Benutzeroberfläche war noch eine Menge „Schrott“ von den kopierten Beispielvorlagen übrig. Ich wollte das alles herausnehmen. Das ging ganz einfach, indem ich nach dem Text suchte, der erzeugt wurde und den ich nicht haben wollte…
- „Kontrollkästchen „Nach Preis erhöhen
- Range Facets (nicht verfügbar in Solr 1.4.1, und die Velocity-Vorlage hat einen fest kodierten Preis)
- Spatial (nicht verfügbar in Solr 1.4.1, und die ISFDB-Daten haben keine Lat/Lon-Felder
Mir ist auch aufgefallen, dass es eine Menge debugbezogener Links gab, die nichts zu tun schienen. Als ich mir den HTML-Quelltext der generierten Seiten ansah, wurde mir klar, dass hier versucht wurde, jQuery zu verwenden, aber laut der Javascript-Konsole in meinem Browser funktionierte jQuery überhaupt nicht. Ein Blick auf die generierten HTML-„Skript“-Verknüpfungen machte deutlich, dass die Velocity-Vorlagen davon ausgingen, dass eine bestimmte Version von jQuery direkt im Verzeichnis „/solr/admin/“ verfügbar war, und die Version in Solr 1.4.1 ist etwas älter. Also habe ich den jQuery-Verweis zusammen mit dem Debug-Aufruf (der davon ausging, dass das uniqueKey-Feld ‚id‘ war) korrigiert.
Schritt #4: Hyper-Verknüpfung
Zu diesem Zeitpunkt war die Benutzeroberfläche immer noch keineswegs hübsch, aber sie war funktional und viel einfacher zu lesen als die rohe XML- (oder JSON-) Ausgabe von Solr. (auch wenn die meisten Felder immer noch nicht angezeigt wurden). Das Einzige, was ich noch tun wollte, bevor ich den Tag beendete, war, einige Hyperlinks hinzuzufügen:
- Verknüpfen Sie Titel mit ihren Autoren
- Autoren mit ihren Titeln verknüpfen
- Verknüpfen Sie Pseudonyme und Autoren miteinander
Ich bin mir sicher, dass der „richtige“ Weg, vieles davon in Velocity zu tun, einige wiederverwendbare Makros wären, aber ich habe einfach angefangen (es kann später immer noch überarbeitet werden).
Die Verknüpfung mit einzelnen Autoren (von Pseudonymen oder Titeln, die nur einen Autor haben) war ziemlich einfach, ebenso wie die Verknüpfung mit der Liste der Titel eines Autors. In beiden Fällen handelte es sich um einen einfachen Link mit einem einzelnen Wert aus dem aktuellen Ergebnis. Die Verknüpfung mit allen Autoren eines Titels oder allen Pseudonymen eines Autors war etwas komplizierter, da ich Werte aus mehreren Feldern (den „ids“ und den „names“) miteinander in Beziehung setzen musste und bis zu diesem Zeitpunkt hatte ich in Velocity nur mit einfachen „foreach“-Schleifen gearbeitet. Ich musste also in der Dokumentation nachschlagen und herausfinden, wie ich indizierte for-Schleifen verwenden konnte, um die Verknüpfungen herzustellen. Das war nicht allzu mühsam. Allerdings hatte ich anfangs Schwierigkeiten, weil ich im Benutzerhandbuch für die falsche Version von Velocity nachgeschlagen hatte und sich die Variable für den Zugriff auf den Look Counter geändert hat.
Fazit (vorläufig)
Und damit ist diese neueste Ausgabe des blog_7-Tags abgeschlossen.
Das Endergebnis ist etwas, das einfache Suchergebnisse anzeigen kann, wobei Titel und Autoren untereinander verlinkt sind. Es ist immer noch ziemlich hässlich, aber ich denke, es ist auf jeden Fall nützlich…
Ich hoffe, dass ich beim nächsten Mal weitere Verbesserungen an der grundlegenden Benutzeroberfläche vornehmen kann (hoffentlich ohne mich zu sehr in das Thema Velocity zu vertiefen).