Aufgrund des aktuell recht miesen Ladeverhaltens der auf zerbit.de bislang verwendeten live-Searchbox für die Suche in diesem Web, habe ich mich entschlossen BOSS (Build your own Search Engine) von Yahoo einmal auszuprobieren. Schön an dieser Lösung ist, daß man die Suchergebnisse über eine API im XML-Format abrufen und sie dann nahtlos in das Layout der eigenen Seite integrieren kann.

Notwendig war in diesem Zusammenhang natürlich auch ein Seiten-Navigator, wie man ihn auf Suchergebnisseiten gewohnt ist. Je nachdem wieviele Gesamttreffer eine Suche ergibt und wieviele Treffer auf einer Seite dargestellt werden, sollten unterschiedlich viele Seiten-Links (dargestellt als kleine Buttons) im Navigator enthalten sein, jedoch maximal 15 um einzeilig zu bleiben. Bei der Anzeige einer Seite größer als 15, sollte der Navigator "nach rechts rollen", d.h. der erste darzustellende Seiten-Link sollte sich um eins verschieben, bis die maximale Anzahl an Seiten erreicht ist.

Möglichkeiten

Eine mögliche Lösung für die Implementierung des Navigators wären statische Hyperlink-Controls gewesen, die in Abhängigkeit der anzuzeigenden Trefferseite ihren Text und ihren Link ändern, aber damit wäre die maximale Anzahl an Seitenlinks per Code auf 15 zementiert und wenig Raum für eine schnelle Anpassung, wenn es dann doch einmal mehr sein sollten. Die größte Flexibilität wäre erreicht, wenn man in der web-config definieren könnte, wie "breit" der Navigator sein soll und der Code dies dynamisch in HTML umsetzt.

Für dieses Problem bietet ASP.NET über die Methode Controls.Add die Möglichkeit zur Laufzeit Steuerelemente in einen beliebigen Container einzufügen, wie unter anderem Uwe Grone in seinem MSDN Solve Artikel beschreibt.

  Dim lnk As HyperLink = New HyperLink()
  lnk.Text = "..."
  lnk.NavigateUrl = "..."
  Me.Panel1.Controls.Add(lnk)

Dieser Ansatz hat allerdings den Haken, dass das Hyperlink-Control keinen Konstruktor bietet, mit dem man die notwendigen Attribute direkt übergeben kann. Bei einer nicht bekannten Anzahl an zu erzeugenden Controls kommt da recht viel Code zustande, vor allem, wenn man zwei Navigatoren braucht: einen oben auf der Seite und den anderen unten.

Einige ASP.NET-Controls besitzen die Möglichkeit zum seitenweisen Anzeigen der übergebenen Daten (Paging), was auf den ersten Blick sehr sinnvoll ist, um dem Benutzer nicht endlos scrollen lassen zu müssen. Ein Klick auf "nächste Seite" und die nächsten 20 Treffer werden angezeigt. Auf den ersten Blick eine schicke Sache, auf den zweiten aber nicht besonders effizient, denn die gesamten Daten, werden von der ASP.NET.Applikation im Speicher gehalten!

Die bessere Alternative ist ja wohl, sich immer nur die Datenmenge vom Datenbank-Server zu holen, die in dem Moment gebraucht wird, also SQL-Server-Paging zu implementieren.

Bis einschließlich SQL-Server 2000 war ein effizientes serverseitiges Paging mittels T-SQL nicht immer ein Vergnügen. Entweder man pumpte die Daten über eine Stored-Procedure in temporäre Tabellen und ließ sich den Teil der Daten zurückgeben den man gerade brauchte oder man erzeugte dynamisches SQL, was auf die Dauer nur sehr schlecht wartbar war.

Mit der Veröffentlichung der 2005'er-Version des SQL-Servers hielt ein Feature Einzug, daß sich wunderbar für Paging nutzen lässt: ROW_NUMBER.