(edit)
Unwichtige Korrekturen ausblenden - Änderungen im Wiki Quelltext
(:redirect 'http://docs.studip.de/develop/Entwickler/QuickSearch':)
$attr_array = array('title' => 'nur ein Suchfeld')
Man ist nicht auf SQLSearch beschränkt. Jeder Programmierer kann eigene Suchobjekte definieren und so zum Beispiel auch eine Lucene-Index-Suche implementieren, wenn ihm gerade danach ist. Die Suchklassen müssen alle von der Klasse SearchType abgeleitet werden und mindestens die Methoden includePath() und (sinnvollerweise) getResults(...) überschreiben. Falls die Suchklasse im Kern von Stud.IP benutzt wird, sollte sie auch im Verzeichnis lib/classes/seachtypes/ hinterlegt werden. Aber Pluginbauer können ihre Suchklassen natürlich auch im Plugin hinterlegen.
includePath()
getResults(...)
lib/classes/seachtypes/
Eine kleine Beispielsuchklasse könnte zum Beispiel so aussehen:
class SeminarTypSuchen extends SearchType { public function getTitle() { return _("Seminartyp suchen"); } public function getResults($input, $contextual_data = array()) { $typen = $GLOBALS['SEM_TYPE']; foreach($typen as $key => $typ) { if (strpos($typ['name'], $input) === false) { unset($typen[$key]); } else { $typen[$key] = array($key, $typ['name']); } } return $typen; } public function includePath() { return __file__; } }
Diese Klasse ist für den Fall gedacht, dass es in Stud.IP unübersichtlich viele Semeinartypen gibt. Diese Typen sind in der config.inc.php definiert und finden sich also nicht in der Datenbank. Für diesen Zweck ist also die Klasse SQLSearch unpraktikabel.
Die Methode getTitle gibt nur den Schriftzug, der später im leeren Formularfeld stehen soll, wider. Die Methode getResults erledigt gewissermaßen die ganze Arbeit, durchsucht das Array aller Seminartypen nach dem eingegeben String und gibt ein Ergebnisarray der Form array(array(ID_des_Seminar_Typs, Name_des_Typs), ...) zurück. Die Methode includePath ist notwendig, damit diese Klasse gefunden wird (es gibt einen internen kleinen Autoloader), hat aber stets den gleichen Inhalt, kann also für alle Erweiterungsklassen von SearchType so übernommen werden.
getTitle
getResults
array(array(ID_des_Seminar_Typs, Name_des_Typs), ...)
includePath
Und das sollte es auch gewesen sein. Man kann noch einen Avatar für seine Suchergebnisse angeben, was sich aber für Seminartypen nicht gerade anbietet. Dennoch würde man da tun, indem man die Methoden getAvatar und getAvatarImageTag überschreibt. Siehe dazu Dokumentation im Quellcode.
getAvatar
getAvatarImageTag
Für ganz einfache Suchen wie der Suche nach einem username oder einer user_id kann man statt eines Suchobjektes auch einfach als zweiten Parameter im Konstruktor von QuickSearch "username", "user_id", "Seminar_id", "Institut_id" oder "Arbeitsgruppe_id" schreiben. Also:
Für ganz einfache Suchen wie der Suche nach einem username oder einer user_id kann man als Suchobjektes auch einfach die Klasse "StandardSearch mit Parameter "username", "user_id", "Seminar_id", "Institut_id" oder "Arbeitsgruppe_id" schreiben. Also:
print QuickSearch::get("seminar", "Seminar_id")
print QuickSearch::get("seminar", new StandardSearch("Seminar_id"))
[@
(:source lang=php linenum:)[@
Und so wird es dann aussehen:
In lib/classes/QuickSearch.class.php wird eine GUI-Klasse bereit gestellt, mit der man ein einzeiliges Suchfeld inklusive AJAX-Dropdown Menü schnell und einfach an jede Stelle einbauen kann. Vorteile:
lib/classes/QuickSearch.class.php
Im HTML gibt es dann das Input-Feld, das man erwartet und ein weiteres unsichtbares Input-Feld für die ID. Meistens sucht man nach etwas wie Personen, die einen klar lesbaren Namen haben. Aber der Programmierer will an der Stelle eigentlich nicht den Namen, sondern lieber eine user_id haben. Die user_id wird dann versteckt im Hintergrund gespeichert. Der Programmierer kann QuickSearch einbinden, wie ein Input-Feld, in das der Nutzer wie magisch nur die user_id eingegeben hätte - der Nutzer gibt aber den Klarnamen ein. QuickSearch bietet diese Architektur ganz automatisch.
Üblicherweise besteht die Suche aus zwei Elementen, die zusammen arbeiten: erstens, das Suchelement, das quasi ein Model ist, das konkret nach etwas sucht, und zweitens die QuickSearch-Klasse, die diese Suche ausführt und sich um die Ausgabe kümmert.
$suche = new SQLSearch("SELECT username, Nachname " . "FROM auth_user_md5 " . "WHERE Nachname LIKE :input " . "LIMIT 5", _("Nachname"), "username"); print QuickSearch::get("username", $suche) ->setInputStyle("width: 240px") ->render();
Die Variable $suche ist also das Objekt, das die Suche durchführt. Dieses Objekt ist nicht notwendigerweise ein Objekt der Klasse SQLSearch, sondern ein Objekt der Klasse SearchType (wovon SQLSearch eine Unterklasse ist). SQLSearch ist nun eine spezielle Klasse, die beliebige SQL-Queries auf die Datenbank anwenden kann. In diesem Query bezeichnet :input stets den Suchstring, den ein Nutzer später eingibt.
$suche
:input
Die Klasse QuickSearch kümmert sich danach dann um die Ausgabe. Der erste Wert des Konstruktors ist immer der Name des Suchfeldes im HTML, also zum Beispiel <input name="username"> . Der zweite Parameter ist dann das Suchobjekt, das wir vorher definiert haben. Danach folgen einige Methoden, um die Ausgabe weiter zu konfigurieren wie setInputStyle("width: 240px") und die Methode render() veranlasst dann die Ausgabe des Ganzen.
<input name="username">
setInputStyle("width: 240px")
render()
print QuickSearch::get("seminar", "Seminar_id") ->setInputStyle("width: 240px") ->render();
Quelle: Basis-Wiki-Hilfe | Letzte Änderung: 01.04.2011 23:49 Uhr, tthelen | Local view: Basis-Hilfe