BlackCat CMS Forum

shadowcat hat geschrieben:Nachdem ich mich jetzt zwei Tage mit dem Lucene-Kram rumgeschlagen habe, stelle ich das vorerst mal zurück. Ich glaube, vorher gehe ich lieber nochmal grundsätzlich an die Such-Schnittstelle. Das wäre dann aber ein Thema für 2.x (wobei das auch 2.1, 2.2 etc. heißen kann).

Vielleicht können wir da gemeinsam was aushecken, für mich ist die Suche im kitFramework und die Anbindung an die Suche des jeweiligen CMS ohnehin ein Thema. Cool wäre eine Schnittstelle, die sich mit Zend, Symfony, BC und dem kitFramework verträgt ...

Ja, das können wir uns mal auf die ToDo-Liste schreiben. Ich denke an eine Index Search Engine, die unabhängig läuft und deren Daten man dann von BC aus abgreifen kann. Das ginge dann auch für kF und andere. Ich hatte vor Jahren mal so ein Ding, aber ich weiß nicht mehr, wie das hieß. Ich suche noch.

Eine wirklich effektive SE müßte compiliert sein, da hat man wieder das Problem mit den Billighostern. Swish-e wäre so ein Kandidat.

Eine Sache gibt's aber noch für 1.1, nämlich die Open Graph Geschichte. Schaffst Du das mit dem Helper noch?

Hier können wir diskutieren, was evtl. geeignet ist.

Was man mal angucken könnte:

ZendSearch_Lucene (reines PHP)
iSearch - http://www.isearchthenet.com/pro/index.php
Swish-e
Sphinx - http://sphinxsearch.com/
Sphider - http://www.sphider.eu/
TSEP - http://sourceforge.net/projects/tsep/
OpenSearchServer (vermutlich oversized) - http://www.opensearchserver.com/

shadowcat hat geschrieben:Ja, das können wir uns mal auf die ToDo-Liste schreiben. Ich denke an eine Index Search Engine, die unabhängig läuft und deren Daten man dann von BC aus abgreifen kann. Das ginge dann auch für kF und andere. Ich hatte vor Jahren mal so ein Ding, aber ich weiß nicht mehr, wie das hieß. Ich suche noch.
Eine wirklich effektive SE müßte compiliert sein, da hat man wieder das Problem mit den Billighostern. Swish-e wäre so ein Kandidat.

Ich habe mich noch gar nicht damit beschäftigt, müsste mich auch erst einmal umschauen. Wir haben es ja normalerweise nicht mit Mega-Installationen zu tun, das ärgste was ich in Petto habe ist eine Installationen mit ca. 1.200 Seiten und eine zweite mit ca. 2.500 Seiten und es gibt eine kitEvent Installation die wohl bis Ende des Jahres die Marke für 5.000 Veranstaltungen reißen wird (die Suche erfolgt über das kitFramework und ist bislang völlig ok). In der Regel dümpeln die Installationen irgendwo zwischen 5 und 50 Seiten rum, größere Seiten schaffen auch mal 200+ aber das sind Ausnahmen.

Eine Sache gibt's aber noch für 1.1, nämlich die Open Graph Geschichte. Schaffst Du das mit dem Helper noch?

Ich denke mal, dass es bei mir im Laufe der kommenden Woche spürbar ruhiger wird, ja, sollte ich schaffen - ich warte auf das Sommerschlglöchlein ...

Ich denke, das Hauptproblem ist, dass fertige Search Engines fertige (=gerenderte) Seiten durchsuchen. Wir brauchen aber eigentlich was, das es den Modulen überläßt, was in den Index kommt und was nicht. Es sei denn, wie stellen diesen Ansatz komplett um.

Eine fertige, brauchbare Library habe ich bisher nicht gefunden, abgesehen von ZendSearch_Lucene.

shadowcat hat geschrieben:Ich denke, das Hauptproblem ist, dass fertige Search Engines fertige (=gerenderte) Seiten durchsuchen. Wir brauchen aber eigentlich was, das es den Modulen überläßt, was in den Index kommt und was nicht. Es sei denn, wie stellen diesen Ansatz komplett um.

Eine fertige, brauchbare Library habe ich bisher nicht gefunden, abgesehen von ZendSearch_Lucene.

Ja, wir brauchen was, das die Module einbindet. Das momentane Konzept ist allerdings nicht gut. Mal abgesehen von dem unglaublichen Overhead den die aktuelle Suche auf der Grund der endlosen Zeichensatzorgien hat, ist es nicht geschickt, erst die Module suchen zu lassen, sie dann ein Ergebnis zurückliefern zu lassen, dass dann noch mal geparst wird.

Ins Grobe gedacht:

Die Module erstellen eine vollständige Zusammenfassung, nur TEXT von jedem für sie relevanten Index und liefern optional auch noch ein Bildchen dazu.
Diese Zusammenfassung schieben sie in die Search Engine und erhalten eine ID zurück.
Die Search Engine nutzt die Zusammenfassungen für eine Volltextsuche und bildet daraus (Täglich, Stündlich ... nach Bedarf) einen Index der für eine Echtzeitsuche genutzt wird.
Die Treffer im Suchergebnis werden mit der ID der Module verlinkt.
Wird ein Treffer aufgerufen, fordert die Search Engine mit Hilfe der ID den Inhalt beim Modul an und baut die Zielseite auf.

Eine Modul-ID brauchen wir nicht, das geht über die Section-ID.

Meine Überlegung war folgende: Wir bauen eine komplett neue Schnittstelle, so daß die alte search.php weiterhin funktioniert. (Was man damit anfängt muß man sehen.) Diese Schnittstelle wird vom Core beim _Speichern_ (also im Backend) aufgerufen. Somit hat man immer nur eine einzelne Section, maximal eine einzelne Seite zu indizieren.

Was das Modul für den Index zurückliefert, muß man sich im Detail noch überlegen. Bei Lucene kann man ja beliebige Felder ablegen, zudem hat jedes Document sowieso eine ID. Man kann auch definieren, daß der Text zwar indiziert, aber nicht selbst im Index gespeichert wird, was die Größe des Index reduziert.

Auf diesen Index kann nun grundsätzlich jedes beliebige Tool zurückgreifen. Sicherlich muß man das absichern, bei Zend_Lucene gibt es dafür Mechanismen. Da die Schnittstelle immer das Zend_Lucene ist (in diesem Beispiel jedenfalls), muß das Tool - also etwa kF - nur diese Schnittstelle benutzen.

Alternative: Beim Speichern wird die Ausgabe der view.php an den Index geliefert.

Lucene hat übrigens einen kompletten HTML-Parser an Bord, so daß man sich das Ausfiltern von HTML-Tags sparen kann.

shadowcat hat geschrieben:Lucene hat übrigens einen kompletten HTML-Parser an Bord, so daß man sich das Ausfiltern von HTML-Tags sparen kann.

Das kitFramework hat den HTML Purifier an Bord (u.a. für die flexContent Importfunktion) ...