Tommi: Wieviele <option>s verkraftet <select>?

Moin,
ich möchte den Inhalt einer Datenbank per PHP in HTML-Seiten ausgeben, und zwar immer nur eine Bestimmte Menge pro Seite. Um die Seiten auswählen zu können, möchte ich ein PD-Menü (mit <select>) ausgeben.
Jetzt würde mich interessieren, wieviele Zeilen (<options>) das Menü haben kann. Um die hundert scheinen ja noch kein Problem zu sein (es erscheint dann ja auch ein Scrollballken) aber was, wenn das tausend und mehr werden?

Schon mal Danke,
Tommi

  1. Jetzt würde mich interessieren, wieviele Zeilen (<options>) das Menü haben kann. Um die hundert scheinen ja noch kein Problem zu sein (es erscheint dann ja auch ein Scrollballken) aber was, wenn das tausend und mehr werden?

    Eine maximale Anzahl gibt es da nicht. Nur mit tausenden von Einträgen wirst Du den Rechner des Seitenbetrachter wahrscheinlich in die Knie zwingen, weil der Browser relativ viel Speicher und CPU belegt. Außerdem kann der Seitenaufbau relativ lange dauern.
    Ich würde an Deiner Stelle das ganze mal auf verschiedenen Rechnern ausprobieren oder was vielleicht besser wäre, die options auf mehrere selects aufteilen, falls das irgendwie machbar ist.

  2. Jetzt würde mich interessieren, wieviele Zeilen (<options>) das Menü haben kann.

    Vom Technikaspekt her: nahezu unbegrenzt.
    Vom Usabilityaspekt her: ca. sieben, maximal zehn.

    was, wenn das tausend und mehr werden?

    Sinnvoll aufteilen.

    Christoph

  3. Moin!

    ich möchte den Inhalt einer Datenbank per PHP in HTML-Seiten ausgeben, und zwar immer nur eine Bestimmte Menge pro Seite. Um die Seiten auswählen zu können, möchte ich ein PD-Menü (mit <select>) ausgeben.
    Jetzt würde mich interessieren, wieviele Zeilen (<options>) das Menü haben kann. Um die hundert scheinen ja noch kein Problem zu sein (es erscheint dann ja auch ein Scrollballken) aber was, wenn das tausend und mehr werden?

    Denke dran, dass jemand dein Menü bedienen muß. Und der wird wenig erfreut sein, wenn er nur deshalb, weil er die letzte Seite sehen will, erstmal durch tausende von Seitennummern scrollen muß.

    Die bessere Methode wäre: Stelle fest, wieviele Seiten es gibt, und zeige diese Information an. Packe folgende Buttons dazu: "Zur ersten Seite", "zur vorigen Seite", "zur nächsten Seite", "zur letzen Seite". Und für das Springen zu einer bestimmten Seite gibst du ein Textfeld hinzu, in das man die gewünschte Seitennummer tippen kann.

    Allerdings ist eine Seitennummer ziemlich abstrakt. Stell dir einfach nur mal das Telefonbuch vor: Suchst du da nach Seitennummern? Wohl eher nicht. Abhängig von der Art der Ausgabe wird es wahrscheinlich eine bessere Methode geben, um dem Benutzer Zugriff auf die Datenbank zu geben.

    Wenn du mal genauer beschreiben würdest, was du vor hast, gibts hier bestimmt eine Lösung.

    - Sven Rautenberg

    --
    "Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)
    1. Die bessere Methode wäre: Stelle fest, wieviele Seiten es gibt, und zeige diese Information an. Packe folgende Buttons dazu: "Zur ersten Seite", "zur vorigen Seite", "zur nächsten Seite", "zur letzen Seite". Und für das Springen zu einer bestimmten Seite gibst du ein Textfeld hinzu, in das man die gewünschte Seitennummer tippen kann.

      Das mit dem Textfeld ist 'ne Idee! (vor- und zurück-Buttons hab' ich bereits).

      Allerdings ist eine Seitennummer ziemlich abstrakt. Stell dir einfach nur mal das Telefonbuch vor: Suchst du da nach Seitennummern? Wohl eher nicht.

      Das stimmt. Wichtig sind eigentlich auch nur die ersten paar Seiten, es soll aber "theoretisch" möglich sein, zu jeder beliebigen Seite zu kommen (wie gesagt, das mit Textfeld ist glaube ich nicht schlecht - eine Suchfunktion ist auch bereits eingebaut).

      Tommi