Michael Pöhler: «input type=int....

Hallöchen!

Ich habe für unser Intranet nen Bestellkatalog geschrieben, dort macht es natürlich nur Sinn z.B. ganze Bleistifte zu bestellen ;-)

Eigentlich dachte ich, daß es reichen müßte, wenn ich Netscape sage, daß es nur ganzzahlige Eingaben akzeptieren soll....

geht das nicht mit <input type=int.... ? oder habe ich da was falsch verstanden?

Ich habe nämlich keine Lust die Eingabe nach dem senden zu runden oder schon bei der Eingabe zu prüfen, da die ganze Sache schon unendlich langsam ist!! Vielzuviele Artikel!!

Danke vielmols, Euer Micha

  1. Eigentlich dachte ich, daß es reichen müßte, wenn ich Netscape sage, daß es nur ganzzahlige Eingaben akzeptieren soll....

    geht das nicht mit <input type=int.... ? oder habe ich da was falsch verstanden?

    Das geht natuerlich nicht. HTML ist meines Wissens nach eine MarkupLanguage und keine Programmiersprache mit vordefinierten Datentypen. Dir wird also nicht anderes uebrigbleiben, als die Benutzereingaben nach Abschicken zu pruefen und dann in einen Interger umzuwandeln.

    Viele Gruesse, Thomas Hieck

    1. Ich hatte diesen Befehl
      <INPUT TYPE=INT... aus der HTML Referenz 3.2... wie ich gerade sehe, taucht der Befehl bei der aktuellen Version nicht mehr auf!

      Trotzdem, was hindert den Browser daran, nur bestimmte Eingaben zuzulassen? Bei passwords geht's doch auch

      Gruß, Micha

  2. Hallo!

    ...
    geht das nicht mit <input type=int.... ? oder habe ich da was falsch verstanden?

    sorry, aber IMHO gibt es für solche Fälle nur <input type="text" ...>. Die Browser scheren sich erstmal nicht darum, welchen Typ die Daten später haben werden. Falls die Eingabemöglichkeiten sich in überschaubarem Rahmen halten (z.B. 1,2,...,10), könnstest Du  natürlich eine Auswahlliste (siehe <../../tchd.htm>) nehmen, in der nur ganze Zahlen angeboten werden.

    Ich habe nämlich keine Lust die Eingabe nach dem senden zu runden oder schon bei der Eingabe zu prüfen, da die ganze Sache schon unendlich langsam ist!! Vielzuviele Artikel!!

    Um welche Größenordnung handelt es sich denn? Ich kann mir nicht vorstellen, daß eine CGI-seitige Kontrolle von Eingabefeldern zu merklichen Performance-Einbußen führt. Meistens liegt der Hund woanders begraben, z.B. Netzwerkprobleme (ein beliebter Fehler bei Intranets ist z.B., daß interne Sites über Proxy statt "direkt" angesprochen werden - wird seeehr langsam!). Oder ein ungünstiger Suchalgorithmus. Falls Dich das Problem mit der Performance weiter wurmt, solltest Du vielleicht noch genauere Details posten, z.B. über verwendete Skriptsprache, Suchalgorithmus, Server-Software usw.

    Viele Grüße

    Andreas

    1. Bei der Sache geht es darum, daß so um die tausend Artikel bestellt werden können.
      Als Skriptsprache verwende ich Perl.

      Ich denke ich werde die Leute einfach bis zur Version 2.0 auf dieses Feature warten lassen!

      Es hat sich halt im laufenden betrieb herausgestellt, daß manche Leute auch halbe Bleistifte bestellen!

      1. Hallo nochmal!

        Bei der Sache geht es darum, daß so um die tausend Artikel bestellt werden können.
        Als Skriptsprache verwende ich Perl.

        Werden die Artikelbezeichnungen als Text in einem Textfeld eingegeben oder über eine Liste? Falls die Suche des entsprechenden Artikels in einer Datei mit Tausenden von Einträgen der zeitliche 'Flaschenhals' sollte, fällt mir dazu der Artikel "Programmierter Spielgewinn" oder so ähnlich aus der vorletzten C‚t (Nr. 7/99) ein - Stichwort: Hashfunktionen. Die Methode besteht grob darin, aus der Artikelbezeichnung eine Checksumme zu berechnen, die z.B. von 00 bis 99 gehen darf (-> Hash-Funktion). Danach könntest Du Deine Artikeldatei (z.B. articles.dat) in 100 Dateien splitten (article00.dat, article01.dat ...) und danach sämtliche Artikel gemäß ihrer Hashfunktion in die Dateien einsortieren lassen.

        Wenn dann jemand einen Artikel sucht, wird erst die Hashfunktion berechnet - irgendeine Zahl von 00-99 - und dann nur noch in der Datei mit der entsprechenden Nummer gesucht, in der sich normalerweise nur noch um die 10 Einträge befinden dürften. Ergebnis: Statt im Mittel 500 Textvergleiche benötigt das Skript dann nur noch ca. 5-10!
        Soviel als Anregung, denn - mit Perl sollte so etwas eigentlich gut realisierbar sein.

        Viele Grüße

        Andreas Bierhals

  3. Hallo Markus

    Ich habe nämlich keine Lust die Eingabe nach dem senden zu runden oder schon bei der Eingabe zu prüfen, da die ganze Sache schon unendlich langsam ist!! Vielzuviele Artikel!!

    Kennst du die JavaScript-Ueberpruefung aus dem Beispiel von <../../tedf.htm> - ich sehe nicht, was daran unendlich langsam sein soll? Man muss sich halt die Muehe machen, das Script so anzupassen, wie man es braucht.
    In dem oben genannten Beispiel findest Du unter anderem eine Stelle, wo ein Formularfeld daraufhin ueberprueft wird, ob es eine Altersangabe enthaelt. Da wird genau das abgeprueft was Du brauchst, naemlich ob in dem Feld eine Ganzzahl eingegeben wurde.

    Man muss es halt akzeptieren, dass es nicht fuer jeden Wunsch einen HTML-Befehl gibt (der naechste will naemlich nur Eingaben mit exakt 10 Zeichen Laenge pro Feld zulassen und der uebernaechste keine Umlaute usw.). Eben darum hat man eine Programmiersprache wie JavaScript um HTML drumherum geschaffen, mit der man sich solche Wuensche selber erfuellen kann.

    viele Gruesse
      Stefan Muenz

    1. In der Tat war das mit der Geschwindigkeit wohl ein dummes Argument! My brain just hit a bad sektor!!

      Bloß bin ich eben in Referenz Handbuch 3.2 über eben diesen befehl gestolpert und wollte nun eifach wissen warum es bei mir nicht geht!