input, type="number"

[mathefritz]

läßt sich verhindern daß bei input type="number"
am rechten Eingabefeldrand die Auf-/Ab-Pfeile erscheinen ?
(es sollen auch Eingaben mit führender 0 möglich sein,
die 0 darf nicht verschwinen [Ost-Plz] )

[JürgenB]

Hallo,

läßt sich verhindern daß bei input type="number"
am rechten Eingabefeldrand die Auf-/Ab-Pfeile erscheinen ?

so mache ich es:

input[type="number"]::-webkit-outer-spin-button, input[type="number"]::-webkit-inner-spin-button 
    { -webkit-appearance: none; margin:0 }
input[type="number"] { -moz-appearance: textfield }

ich weiß aber nicht, ob das noch aktuell ist.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

input[type="number"]::-webkit-outer-spin-button, input[type="number"]::-webkit-inner-spin-button 
    { -webkit-appearance: none; margin:0 }
input[type="number"] { -moz-appearance: textfield }

ich weiß aber nicht, ob das noch aktuell ist.

Eher nicht:

“Note: This specification intentionally refrains from making the appearance of all possible form controls and sub-controls available as values, as had previously been attempted by earlier proposals for this property and by several UA vendors in experimental implementations. […] Instead, this specification only provides 'auto', 'none'.” [CSS-UI-4]

Firefox kann die experimentelle Unterstützung von textfield jederzeit wieder fallenlassen.

Und WebKits/Blinks die experimentellen Pseudoelemente.

LLAP 🖖

[JürgenB]

Hallo @Gunnar Bittersmann,

ich weiß aber nicht, ob das noch aktuell ist.

Eher nicht:

und wie mache ich es dann, wenn ich ohne Increment/Decrement-Pfeile auf Geräten mit Software-Tastatur den Ziffernblock als Default haben möchte?

Gruß
Jürgen

[TS]

Hallo und guten Morgen Jürgen,

und wie mache ich es dann, wenn ich ohne Increment/Decrement-Pfeile auf Geräten mit Software-Tastatur den Ziffernblock als Default haben möchte?

Sag ich doch immer: diese hochschlauen Typen von W3C oder wer auch immer die Browserentwicklung steuert haben zwar auf jede normale Frage eine blöde Antwort oder RFC, aber wirklich vordenken können die nicht - und nachdenken scheinbar auch nicht, denn sonst würden sie die EDV-Erfahrungen der letzten 100 Jahre nicht einfach so arrogant zur Seite fegen, sondern würden sie nutzen!

Browser sind und bgleiben Kinderkakke!

Grüße
TS

[Linuchs]

Browser sind und bgleiben Kinderkakke!

Und für beide gilt: Wichtig ist, was hinten rauskommt.

Linuchs

[Gunnar Bittersmann]

@@JürgenB

und wie mache ich es dann, wenn ich ohne Increment/Decrement-Pfeile auf Geräten mit Software-Tastatur den Ziffernblock als Default haben möchte?

inputmode="numeric". [Spec]

Can I use? Eher nicht. Also Tickets gegen die Browser schreiben.

Vorläufig noch so, wie du’s machst. Mit ungewisser Zukunft, darauf wollte ich hinweisen.

LLAP 🖖

[dedlfix]

Tach!

läßt sich verhindern daß bei input type="number" am rechten Eingabefeldrand die Auf-/Ab-Pfeile erscheinen? (es sollen auch Eingaben mit führender 0 möglich sein, die 0 darf nicht verschwinen [Ost-Plz])

Postleitzahlen sind keine Zahlen sondern Strings.

Daumenregel: Wenn damit nicht gerechnet werden soll (im mathematischen Sinne) sind es keine Zahlenfelder.

Gegeben sei die Zeichenfolge 42. Wenn man das als Zahl ansieht, wären auch Schreibweisen wie 42.00 oder 4.2E1 gültig. Da diese Schreibweisen in Zusammenhängen wie beispielsweise dem deinen aber ungültig sind, sind es eben keine Zahlen und dürfen auch nicht so behandelt werden.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Gegeben sei die Zeichenfolge 42. Wenn man das als Zahl ansieht, wären auch Schreibweisen wie 42.00 oder 4.2E1 gültig.

Oder auch XLII. ;-)

LLAP 🖖

[Mr. Postman]

läßt sich verhindern daß bei input type="number"
am rechten Eingabefeldrand die Auf-/Ab-Pfeile erscheinen ?
(es sollen auch Eingaben mit führender 0 möglich sein,
die 0 darf nicht verschwinen [Ost-Plz] )

Dir sollte eigentlich bei einer Nachsuche mit Google erst Input und dann Pattern aufgefallen sein.

Machen wir die Sache (gleich kommt eh der Gunnar und sagt uns mit guter Begründung, was hieran falsch ist) stufenweise etwas komplizierter:

<label for="PLZ"><span class="accesskey">P</span>LZ:</label>
<input pattern="\d{5}" title="Deutsche Postleitzahl" required="required" type="test" accesskey="P" name="PLZ" id="PLZ" value="" />

oder:

<label for="PLZ"><span class="accesskey">P</span>LZ:</label>
<input pattern="\d{4}" title="Schweizer Postleitzahl" required="required" type="test" accesskey="P" name="PLZ" id="PLZ" value="" />

oder:

<label for="PLZ"><span class="accesskey">P</span>LZ:</label>
<input pattern="\d{4,5}" title="Schweizer oder deutsche Postleitzahl" required="required" type="test" accesskey="P" name="PLZ" id="PLZ" value="" />

ODER:

<label for="PLZ"><span class="accesskey">P</span>LZ:</label>
<input pattern="D-\d{5}|CH-\d{4}|A-\d{4}" title="Schweizer, österreichische oder deutsche Postleitzahl mit vorangestelltem D-, CH- oder A- und 4 bzw. 5 Ziffern" required="required" type="test" accesskey="P" name="PLZ" id="PLZ" value="" />

Die selben Pattern kannst Du dann auch serverseitig benutzen um die Eingaben zu prüfen. Also bietet sich eine zentrale Konfiguration hierfür an. Das macht es einfacher wenn Dir auch bekannt wird, wie Franzosen, Belgier oder Angelsachsen Posteitzahlen zusammenstöpseln. Was ein Pattern oder ein regulärer Ausdruck ist musst Du eh lernen...

[Gunnar Bittersmann]

@@Mr. Postman

gleich kommt eh der Gunnar und sagt uns mit guter Begründung, was hieran falsch ist

Da wäre nunächst einmal das x bei type="test".

AFAIK ist accesskey eher verwirrend als hilfreich.

Und dann wäre noch die Frage nach dem Sinn, ein Formular ausschließlich für Deutschland bzw. Schweiz bzw. … vorzusehen.

LLAP 🖖

[mathefritz]

Danke allen Antwortenden, für Eure Mühen
ich werde mich hier wohl auf Sorgfaltt und Verstand des/der Erfassser/innen und
der Postdienste verlassen müßen. Es geht dießmal um Daten die per php/mysql
in einer Datenbanktabelle landen müssen, und bei diesem Transfer geht, wenns
input type="number" war, die führende 0 ohnehin verloren. Wird also ein ungeprüfter
Text oder ein 2test Eingabefeld das entweder leer sein oder O enthalten muß.
Ich mach das für einen Bekannten, der "mit dem Kopf durch die Wand will" und mir kaum
die Zeit zu gründlichem Studium der mir neuen Materie läßt.

"Guten Rutsch!"

[Rolf b]

In der Datenbank geht die führende Null bei der PLZ verloren? Dann ist das falsch modelliert.

PLZ ist type="text", number ist falsch. Korrektes Format prüft man per pattern, wenn du einen Live-Check auf erlaubte Zeichen willst, muss wohl JavaScript heran.

Beratungsresistente Kunden sollte man, wenn man es sich leisten kann, in den Ex-Kunden Status versetzen. Denn spätestens, wenn der durch die Wand gerammte Kopf eine Beule entwickelt, oder der Rammpunkt sich als statisch kritisch erweist, will dieser Typ Kunde von seiner Resistenz nichts mehr wissen und macht dich verantwortlich. Oder fordert zumindest Abhilfe. Woraufhin du dem gebastelten und verabscheuten Konstrukt weitere Ekligkeiten hinzufügen musst. Es wird nicht besser.

Und wenn es ein Gefälligkeitsdienst für einen Bekannten ist, wird die Sache noch schlimmer, denn solche Projekte haben keinen Endetermin.

[mathefritz]

Danke Rolf b für die einfühlsamen Worte;

ja, die 0 geht verloren wenn im Formular type="number" ist und Für die DB-Spalte "i" gegeben ist.
Was Du mit "falsch modelliert" meinst verstehe ich nicht.

Auf PLZe verschiedener Staaten werde ich noch nicht eingehen, aber ich habe pattern="\d+"
hinzugenommen ( was dann ein required entbehrlich macht);

es stellt sich noch die Frage ob sich VERHINDERN läßt daß die Eingabetaste SUBMIT bewirkt -
denn für den Erfasser ist es unangenehm danach ein zurückgesetzes Formular zu bekommen

[Matthias Apsel]

Hallo mathefritz,

ja, die 0 geht verloren wenn im Formular type="number" ist und Für die DB-Spalte "i" gegeben ist.
Was Du mit "falsch modelliert" meinst verstehe ich nicht.

Wenn aus dem Postleittext 01234 die Zahl 1234 gemacht wird, ist deine Datenhaltung falsch modelliert.

Auf PLZe verschiedener Staaten werde ich noch nicht eingehen, aber ich habe pattern="\d+"
hinzugenommen ( was dann ein required entbehrlich macht);

Warum ist das Ausfüllen dieses Feldes nicht mehr erforderlich?

es stellt sich noch die Frage ob sich VERHINDERN läßt daß die Eingabetaste SUBMIT bewirkt -
denn für den Erfasser ist es unangenehm danach ein zurückgesetzes Formular zu bekommen

Ja.

PS: Du brauchst
die
Zeilenum-
brüche nicht per Hand zu setzen.

Bis demnächst
Matthias

[mathefritz]

Hallo Matthisas, Danke für Deinen Beitrag, und ein gutes 2017.

Auf PLZe verschiedener Staaten werde ich noch nicht eingehen, aber ich habe pattern="\d+" hinzugenommen ( was dann ein required entbehrlich macht);

Warum ist das Ausfüllen dieses Feldes nicht mehr erforderlich?

hatte den Eindruck, daß dann bei leerem PLZ Feld Submit nicht angenommen wird, weil ja das \d+ Pattern mindestens ein Zeichen dort verlangte - hab mich wohl getäuscht; NICHT getäuscht aber habe ich mich, daß Fehlende Einträge farbig umrandet werden - ok - ist Browserabhängig ( chrome tut es nicht ).

es stellt sich noch die Frage ob sich VERHINDERN läßt daß die Eingabetaste SUBMIT bewirkt - denn für den Erfasser ist es unangenehm danach ein zurückgesetzes Formular zu bekommen Ja.

Das "Ja" verstehe ich als Zustimmung zur Einstufung als "unangenehm". Ist es also, auf einfache Weise, unmöglich, dem Erfasser ein unverändertes Eingaabefeld zu hinterlassen wenn der php-Code es nicht akzeptiert hat. ( im speziellem Fall sollte es eigentlich nichtmehr eintreten. )

Gruß F.

<html><head><meta charset="utf-8"><title>Erfassung</title></head>
<body>
<h1>Companies</h1>
<?php
if (isset($_POST["firmenname"]) && $_POST["firmenname"] != "" && 
    isset($_POST["strassehn" ]) && $_POST["strassehn" ]  != "" &&
    isset($_POST["plz"       ]) && $_POST["plz"       ]  != "" &&
    isset($_POST["stadt"     ]) && $_POST["stadt"     ]  != ""
   ) {

    if ($db = mysqli_connect("............", // passende
                             "............", // Parameter
                             "...........",
                             "............") ) {
    echo "connected",$_GET["reg"];
    $sql = "INSERT INTO FlyerVersandAdresse" . $_GET["reg"]."
    (firmenname,
     strassehn,
     plz,
     stadt,
     land)
     VALUES (?, ?, ?, ?, ?)";
     $kommando = mysqli_prepare($db, $sql);
     mysqli_stmt_bind_param
     ($kommando, "ssiss", $_POST["firmenname"], $_POST["strassehn"],
                          $_POST["plz"],        $_POST["stadt"],
                          $_POST["land"]
     );
     if (mysqli_stmt_execute($kommando) ){
         $id = mysqli_insert_id($db);
         echo "Eintrag $id hinzugef&uuml;gt.
         <a href=\"gb-edit45.php?id=$id\">Bearbeiten</a>";
     } else {
              echo "Fehler: " . mysqli_error($db) . "!";
            }
     mysqli_close($db); echo "closed";
} else {
        echo "Fehler: " . mysqli_connect_error() . "!";
       }
}
?>
<form method="post">
Name:       <input type="text"   name="firmenname"        required /><br />
Straße/Hnr: <input type="text"   name="strassehn"         required /><br />
PLZ/ZIP:    <input type="text"   name="plz" pattern="\d+" required /><br />
Stadt:      <input type="text"   name="stadt"             required /><br />
ggf Land:   <input type="text"   name="land"            /><br />
            <input type="submit" name="Submit" value="Eintragen" />
</form>
 <a href = "https://cloudlogin02.world4you.com/index.php/apps/files">Kaffeepause</a>
</body>
</html>

Der Code ist zusammengestückelt abgetipp aus "Christian Wenz, Tobias Hauser: PHP 7 und MySQL" von meinem Bekannten und angepaßt von Ihm und mir. Er wird aufgerufen aus einer Datei die Nur Links mit Parametern zur Ergänzung der Tabellennamens enthalten.

[Gunnar Bittersmann]

@@mathefritz

    echo "connected",$_GET["reg"];

Es ist 2017 (Prost Neujahr!) und man muss das immer noch immer wieder sagen:

Fehler: Du darfst niemals Daten unsicherer jeglicher Herkunft (z.B. Nutzereingaben) unbehandelt in HTML ausgeben. Sicherheitslücke!!

Wo echo ist, sollte htmlspecialchars() nicht weit sein.

         echo "Eintrag $id hinzugefügt.

Es ist 2017 (Prost Neujahr!), da muss man keine Umlaute mehr verstümmeln.

Name:       <input type="text"   name="firmenname"        required /><br />
Straße/Hnr: <input type="text"   name="strassehn"         required /><br />
PLZ/ZIP:    <input type="text"   name="plz" pattern="\d+" required /><br />
Stadt:      <input type="text"   name="stadt"             required /><br />
ggf Land:   <input type="text"   name="land"            /><br />
            <input type="submit" name="Submit" value="Eintragen" />

Es ist 2017 (Prost Neujahr!) und man muss das immer noch immer wieder sagen:

Fehler: Eingabefelder brauchen unbedingt eine Beschriftung (label) Ohne label ist ein Formular nicht bedienbar – nicht von Nutzern, die auf assistive Technologien wie Screenreader angewiesen sind.

Fehler: PLZ sind keine Zahlen. Es gibt Länder, da werden auch Buchstaben in PLZ verwendet. Dein Formular ist untauglich zur Angabe einer Adresse in bspw. Großbritannien. Weg mit dem pattern!

Für Buttons sollte man nicht input, sondern das das button-Element verwenden.

br hat (außer bei Gedichten/Liedtexten, Postadressen u.ä.) nichts in HTML zu suchen. Du kannst Label(!) und Eingabefeld in p wrappen. Oder display: block im Stylesheet.

PLZ und Ort (nicht „Stadt“) könnten auch nebeneinander in einer Zeile stehen.

Der Code ist zusammengestückelt abgetipp aus "Christian Wenz, Tobias Hauser: PHP 7 und MySQL"

Es ist leider öfter so, dass es Autoren von Artikeln/Büchern über PHP oder JavaScript an Grundkenntnissen zu HTML mangelt.

LLAP 🖖

[dedlfix]

Tach!

Fehler: Du darfst niemals Daten unsicherer Herkunft (z.B. Nutzereingaben) unbehandelt in HTML ausgeben. Sicherheitslücke!!

Fehler: Die Herkunft der Daten ist belanglos. Jegliche Daten müssen immer HTML-gerecht ausgegeben werden (oder welcher Kontext auch immer vorliegt). Sicherheitslücken sind nur ein Aspekt. Selbst wenn "brauch ich nicht, läuft ja in einer sicheren Umgebung" gilt, führt das zu Fehlern, wenn je nach Kontext bestimmte Zeichen in den Daten sind.

Man sollte auch nicht zu zimperlich mit seinen eigenen Schöpfungen sein und probieren, wie robust sich die Anwendung verhält. Einfach mal alle Nicht-Buchstaben und -Ziffern aus dem ASCII-Bereich/von der Tastatur eingeben und schauen, dass diese komplett und unverfälscht dargestellt werden.

dedlfix.

[Matthias Apsel]

Hallo Gunnar Bittersmann, @mathefritz

    echo "connected",$_GET["reg"];

Es ist 2017 (Prost Neujahr!) und man muss das immer noch immer wieder sagen:

Fehler: Du darfst niemals Daten unsicherer jeglicher Herkunft (z.B. Nutzereingaben) unbehandelt in HTML ausgeben. Sicherheitslücke!!

Und in diesem Fall genauso oder noch schlimmer

$sql = "INSERT INTO FlyerVersandAdresse" . $_GET["reg"]."

Fehler: Die ungeprüfte und unmaskierte Übernahme eines GET-Parameters ist wirklich eine Sicherheitslücke. Die Ausgabe ungeprüfter Daten ins HTML macht ggf. das HTML kaputt, erlaubt einen Angriff auf den Rechner des Nutzers, ungeprüfte Daten in einem SQL-Befehl erlauben Zugriff auf deine Datenbank.

Bis demnächst
Matthias

[Felix Riesterer]

Lieber Matthias,

    echo "connected",$_GET["reg"];

Fehler: Du darfst niemals Daten in der Datenbank aufgrund eines GET-Requests ändern, es sei denn, es handelt sich um eine Log-Funktion (siehe REST).

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Fehler: Du darfst niemals Daten in der Datenbank aufgrund eines GET-Requests ändern, es sei denn, es handelt sich um eine Log-Funktion (siehe REST).

TL;DR-Begründung: Ein Linkchecker oder ähnlicher Automat ändert sonst Daten beim Drüberlaufen.

dedlfix.

[Linuchs]

Fehler: PLZ sind keine Zahlen.

Trau der deutschen Sprache nicht! Konto-, Kunden- und Telefonnummern sind auch keine Nummern. Ich behandle sie gerne mal so und gebe meine Kundennummer am Telefon durch:

"Dreimilliardenfünfmillionenachtunddreißigtausendzweiundsechzig".

Sowas wurde noch nie auf Anhieb verstanden. Beim Namen kann man ja nachfragen: "Bitte buchstabieren Sie". Aber wie sollte man Nummern per Buchstaben übermitteln?

Doch ja: D wie Dora, R wie Richard, E wie Emil, ...

Es gibt Länder, da werden auch Buchstaben in PLZ verwendet. Dein Formular ist untauglich zur Angabe einer Adresse in bspw. Großbritannien. Weg mit dem pattern!

Diese Behauptung ist nicht richtig. In solchen Ländern heisst das Feld "postcode" und ist schon vom Begriff nicht als Falle für Programmierer geeignet.

In den Niederlanden sind die Postcode z.B. 4356 BP, 5 Stellen reichen nicht.

Linuchs

[Gunnar Bittersmann]

@@Linuchs

Fehler: PLZ sind keine Zahlen.

Trau der deutschen Sprache nicht!

Sag ich doch.

Es gibt Länder, da werden auch Buchstaben in PLZ verwendet. Dein Formular ist untauglich zur Angabe einer Adresse in bspw. Großbritannien. Weg mit dem pattern!

Diese Behauptung ist nicht richtig.

?? Welche jetzt genau nicht?

In solchen Ländern heisst das Feld "postcode"

Sag ich doch.

LLAP 🖖

[Linuchs]

Es gibt Länder, da werden auch Buchstaben in PLZ verwendet. Dein Formular ist untauglich zur Angabe einer Adresse in bspw. Großbritannien. Weg mit dem pattern!

Diese Behauptung ist nicht richtig.

?? Welche jetzt genau nicht?

Dass "Länder" so ein Feld PLZ nennen, nicht mal in ihrer Landessprache.

[Gunnar Bittersmann]

@@Linuchs

Es gibt Länder, da werden auch Buchstaben in PLZ verwendet. Dein Formular ist untauglich zur Angabe einer Adresse in bspw. Großbritannien. Weg mit dem pattern!

Diese Behauptung ist nicht richtig.

?? Welche jetzt genau nicht?

Dass "Länder" so ein Feld PLZ nennen, nicht mal in ihrer Landessprache.

Das wollte ich nicht behauptet haben.

LLAP 🖖

[Matthias Apsel]

Hallo mathefritz,

Hallo Matthisas, Danke für Deinen Beitrag, und ein gutes 2017.

Ebenso.

es stellt sich noch die Frage ob sich VERHINDERN läßt daß die Eingabetaste SUBMIT bewirkt - denn für den Erfasser ist es unangenehm danach ein zurückgesetzes Formular zu bekommen Ja. Das "Ja" verstehe ich als Zustimmung zur Einstufung als "unangenehm". Ist es also, auf einfache Weise, unmöglich, dem Erfasser ein unverändertes Eingaabefeld zu hinterlassen wenn der php-Code es nicht akzeptiert hat.

Es ist mit JavaScript recht einfach möglich, ein Absenden unrichtiger Daten zu verhindern. Bösewichte können sich allerdings ebenso einfach darüber hinwegsetzen. Diese clientseitige Prüfung ersetzt aus diesem Grund nicht die serverseitige Prüfung. In deinem Fall scheinen mir die Maßnahmen required ausreichend zu sein.

Interessant dürfte für dich auch sein, das versehentliche mehrfache Absenden gleicher Datensätze zu verhindern. Es ist guter Stil, jedem Datensatz eine ID zu verpassen, besser vom DBS verpassen zu lassen.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Es ist mit JavaScript recht einfach möglich, ein Absenden unrichtiger Daten zu verhindern.

Ohne JavaScript auch.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Es ist mit JavaScript recht einfach möglich, ein Absenden unrichtiger Daten zu verhindern.

Ohne JavaScript auch.

Ja. Deshalb schrieb ich, dass im konkreten Fall required ausreichend ist.

Bis demnächst
Matthias

[TS]

Hallo und guten Morgen Gunnar,

Es ist mit JavaScript recht einfach möglich, ein Absenden unrichtiger Daten zu verhindern.

Ohne JavaScript auch.

Zeigen, nicht nur quasseln!

Grüße
TS

[Matthias Apsel]

Hallo TS,

Zeigen, nicht nur quasseln!

Diese Art und Weise gefällt mir nicht.

https://wiki.selfhtml.org/wiki/HTML/Tutorials/Formulareingaben_mit_HTML5_validieren#browsereigene_Validierung_mit_HTML5

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@TS

Es ist mit JavaScript recht einfach möglich, ein Absenden unrichtiger Daten zu verhindern.

Ohne JavaScript auch.

Zeigen, nicht nur quasseln!

Die HTML-Spec kennst du? MDN auch? MSDN? SELFHTML-Wiki?

Lesen, nicht nur quasseln!

LLAP 🖖

[Rolf b]

Frohes Neues 🎆

Die Sache mit der Datenmodellierung und -Übertragung ist vielschichtig.

1. Im HTML.
   Da gehört type="text" und ein Pattern hin.
2. Im PHP - Datenempfang.
   Hier musst du nochmal alle Input-Regeln prüfen (weil Input nie vertrauenswürdig ist). Wenn du meinst, Werte irgendwie normieren zu müssen (z.B. PLZ auf 5 Stellen füllen, oder wer weiß was sonst, musst du das dem Anwender spiegeln und nicht in die DB schreiben. Kannst du die Eingabe ohne Modifikation speichern, kommt
3. PHP - Übergabe an MySQL Einen String speichert man mit Typcode s, und das DB Feld muss natürlich passen. Wenn du nur 5-stellige PLZ hast, dann CHAR(5). Hast du PLZ mit variabler Länge, dann z.B. VARCHAR(6). Dann geht auch keine führende Null verloren.

Wenn die DB für die PLZ eine Column mit numerischem Typ definiert, klappt das natürlich nicht, das wäre dann der Modellierungsfehler.

Ein CHAR Feld in der DB, das du mit Typcode i schreibst, wäre ein Programmierfehler...

Rolf

[mathefritz]

Danke Rolf b, für Beitrag und Neujahrswunsch .

Deinen Hinweisen dürfte inzwischen entsprochen sein, aber in die DB kann ich augenblicklich nicht hinein . Siehe auch meine letzte Antwort an Matthias

Nun doch noch eine Frage in diesem Thread: wie stellt man am einfachsten die Anzahl Zeilen ( also Records, oder wie auch immer man's nennt)
fest die eine Tabelle schon / noch( weil u.u. auch gelöscht wird ) enthält ? Info nötig, da Anzahl begrenzt werden soll ( und damit Anzahl daraus erzeugter Serienbriefe )

Mir schein da ohnehin eine Extradatei sinnvoll in der darüber "Buch geführt" wird und die Grenze/n enthält.

[Matthias Apsel]

Hallo mathefritz,

Nun doch noch eine Frage in diesem Thread: wie stellt man am einfachsten die Anzahl Zeilen ( also Records, oder wie auch immer man's nennt)
fest die eine Tabelle schon / noch( weil u.u. auch gelöscht wird ) enthält ? Info nötig, da Anzahl begrenzt werden soll

SELECT COUNT(*)
FROM `Tabelle`

Bis demnächst
Matthias

[mathefritz]

DANKE Matthias !! Mit gemütlichem Studium des Buches wäre ich natürlich auch darauf gestoßen.

[mathefritz]

nochmals Hallo Mattias, einiges versteh ich wohl noch nicht.

Verbinden klappt, aber bereits $cmd ist dann leer

 <html><head><meta charset="utf-8">
<title>COUNT</title></head>
<?php
   $db = mysqli_connect("......",
                        ".......",
                        "........",
                        "....."
          );
  
   if (!$db) { die("Keine DB-Verbindung");
   }
   echo "verbunden<br>";   

   $sql = "SELECT COUNT (*) FROM FlyerVersandAdresseBadenWuerttemberg";

                                $cmd = mysqli_prepare($db, $sql);
   if (! $cmd ) {echo "cmd?",$cmd,"<br>";}
                                $e = mysqli_stmt_execute($cmd);
   if ( ! $e ) echo "exe?<br>";

   mysqli_close($db);
?>
 <body>
</body>

[Matthias Apsel]

Hallo mathefritz,

Verbinden klappt, aber bereits $cmd ist dann leer

Gibts denn die Tabelle?

Man kann sich auch SQL-Fehlermeldungen anzeigen lassen.

var_dump(mysqli_error($db))

Bis demnächst
Matthias

[mathefritz]

Hallo Matthias, danke für den Hinweis;

Die Tabelle existiert

ich habe nun nach dem SELECT ...

var_dump(mysqli_error($db));exit()

eingefügt und erhalte

verbunden!
string(0) ""

(ach ja, das "!" nach Verbunden um zu sehen ob auch tatsächlich die geänderte Version schon auf dem Webspace hochgeladen war )

[Rolf b]

Count verträgt keine Leerstelle, soweit ich weiß. Also

SELECT COUNT(*)
FROM ...

Rolf

[mathefritz]

danke, damit wird es etwas auskunftsfreudiger, aber wie bekomme ich

$e = mysqli_stmt_execute($cmd);

nun aus dem $e die Anzahl der Zeilen heraus?

[Rolf b]

Schau dir mal diese Hilfeseite an.

Allerdings würde ich hier auf prepare und execute verzichten und statt dessen mit mysqli_query direkt ein mysqli_result holen und mit mysqli_fetch_row die erste (und hier auch einzige) Ergebniszeile ermitteln.

$result=mysqli_query($db, $cmd);
$row=mysqli_fetch_row($result);
$count=$row[0];

Da so was öfter gebraucht wird, empfiehlt sich dafür das Schreiben einer Funktion sql_get_single_value.

Rolf

[mathefritz]

Danke Rolf, aber leider läuft es noch nicht

 <html><head><meta charset="utf-8"><title>COUNT</title></head>
<?php
   $db = mysqli_connect(".....",
                        "........",
                        "........",
                        "........."
          );
  
   if (!$db) { die("Keine DB-Verbindung");
   }
   echo "verbunden<br>";   

   $sql = "SELECT COUNT(*) FROM FlyerVersandAdresseBadenWuerttemberg";

   $cmd = mysqli_prepare($db, $sql);
                                
   $e = mysqli_query($db, $cmd); $row = mysqli_fetch_row($e);
   
   echo $row[0];
   mysqli_close($db);
?>
 <body></body>

mehr als das echo verbunden bekomme ich nicht .

[Gunnar Bittersmann]

@@mathefritz

   echo $row[0];

Hättest du die Gute, die dir gegebenen Hinweise auch zu befolgen?

Wenn alles Gesagte ungehört verhallt, vergeht einem jede Lust, dir noch zu antworten.

LLAP 🖖

[mathefritz]

tut mir leid, Gunnar, wenn ich Dich verärgert habe;

dürfte ich, bitte, trotzdem wissen was an dem echo $row[0] zu bemängeln ist, und was noch falsch ( bitte nich wieder Auf die Formulargestaltung hinweisen. Blinde kommen als Erfasser nicht in Betracht ? )

[Achot]

Hallo,

dürfte ich, bitte, trotzdem wissen was an dem echo $row[0] zu bemängeln ist, und was noch falsch ( bitte nich wieder Auf die Formulargestaltung hinweisen. Blinde kommen als Erfasser nicht in Betracht ? )

echo htmlspecialchars($row[0])

Damit sollte auch @Gunnar Bittersmann zufrieden sein :)

[mathefritz]

Danke Achot, leider machte das das Echo nicht sichtbar.

[Achot]

Danke Achot, leider machte das das Echo nicht sichtbar.

Vielleicht solltest du dir dieses YouTube Video dazu anschauen
https://www.youtube.com/watch?v=d7NXMkj-uVQ

[mathefritz]

herzlichen Dank, das Video - auch wenn's mühsam war - hat geholfen

[mathefritz]

ja, wie folgt

<?php
/*....
*/.
   $db = mysqli_connect(".....",
                        ".........",
                        ".......",
                        "..........."
          );
  
   if (!$db) { die("Keine DB-Verbindung");
   }
   echo "verbunden<br>";   

   $sql = "SELECT COUNT(*) FROM FlyerVersandAdresseBadenWuerttemberg";

   $e = mysqli_query($db, $sql); $row = mysqli_fetch_row($e);
   
//   echo htmlspecialchars($row[0]);
     echo $row[0];
   mysqli_close($db);
?>

Ist das Ergebnis das gewünschte - aber ich benötige es als function

<?php
function Anzahl($daba,$region){

echo "Reg: ",$region,"<br>";

 if ( !$daba )   die("DB lost");
 if ( !$region ) die("reg lost");

 $sqll = "SELECT COUNT(*) FROM FlyerVersandAdresse" . $region;

 echo "sqll: ",$sqll,"<br>";

 if (!$sqll) die("sql lost");

 $e   = mysql_query($daba,$sqll); if (!$e) die("e lost");

 $row = mysqli_fetch_row($e); if (!$row) die("row lost");

 return htmlspecialchars($row[0]);
}
/* ........
*/

und da klappt es nicht, für $e gibts keinen Wert ( dort "die" )

[Rolf b]

1. Du hast einen Tippfelher drin: Nimm mysqli_query, nicht mysql_query.

2. Der Ort für den richtigen Einsatz von htmlspecialchars ist die Ausgabe an den Browser. Wenn du eine Funktion "Anzahl" schreibst, sollte sie eine Anzahl zurückgeben, also eine Zahl. Was mit der Zahl geschieht, ist Sache des Aufrufers. Vielleicht soll damit gerechnet werden? Der Autor der "Anzahl" Funktion soll das nicht wissen und schon gar nicht vorgeben. Code korrekt auf Funktionen zu verteilen kann sich zu einiger Hirnakrobatik entwickeln 😱.

Rolf

[mathefritz]

Danke, das wars wirklich !

[Matthias Apsel]

Hallo mathefritz,

Danke, das wars wirklich !

Beachte insbesondere die Hinweise zur Sicherheit.

Bis demnächst
Matthias

[dedlfix]

Tach!

$sqll = "SELECT COUNT(*) FROM FlyerVersandAdresse" . $region;

Das riecht ganz stark nach verbesserungswürdigem Datenbankdesign. Warum sind die Regionen in separaten Tabellen? Warum ist die Region nicht nur ein Kriterium innerhalb einer gemeinsamen Tabelle?

Warum wird die Region einfach so in die Query gesetzt? Ist absolut sichergestellt, dass als Region nicht beliebige Code übergeben werden kann?

if (!$sqll) die("sql lost");

Sowas ist schnell und schmutzig, aber keine für den Produktivbetrieb geeignete Fehlerbehandlung. Das Script stirbt ganz jämmerlich und oftmals gibt man dabei noch Interna preis, die der Anwender nicht wissen muss. Aufgabe von Funktionen ist nicht, das Programm zu steuern, sondern Daten zu liefern. Der Programmfluss sollte vom aufrufenden Code definiert werden. Der weiß besser, was im Falle eines Falles zu tun ist.

$e = mysql_query($daba,$sqll); if (!$e) die("e lost");

Fehler finden in der Entwicklungsumgebung: var_dump() ist das Werkzeug der Wahl (wenn man keinen Debugger zur Verfügung hat). Zudem sollte das error_reporting auf E_ALL gestellt sein und display_errors auf 1. Vermutlich hättest du dann zwar auch nicht gefunden, dass da ein i im Funktionsnamen fehlt, aber es hätte sicher Meldungen über falsche Parameter gegeben.

return htmlspecialchars($row[0]);

Und wie schon von Rolf b gesagt, das Aufbereiten für irgendeine Ausgabe ist auch nicht Aufgabe der Datenbesorgungsfunktion.

dedlfix.

[Gunnar Bittersmann]

@@mathefritz

dürfte ich, bitte, trotzdem wissen was an dem echo $row[0] zu bemängeln ist,

Steht doch im verlinkten Posting ganz oben.

Blinde kommen als Erfasser nicht in Betracht ?

Und Einäugige auch nicht.

Und Grünäugige auch nicht.

Und Rothaarige auch nicht.

Du erkennst, dass „… kommen nicht in Betracht“ Bullshit ist?

Du hast keinen Einfluss darauf, ob Nutzer deiner Seiten Beeinträchtigungen haben. (Diese müssen auch nicht permanent sein, sondern können auch zeitweilig oder situationsbedingt auftreten.)

Du hast keinen Einfluss darauf, ob Menschen mit Beeinträchtigungen deine Seiten nutzen wollen.

Du hast Einfluss darauf, in welchem Maße Menschen mit Beeinträchtigungen deine Seiten können.

Behinderte sind nicht behindert, sie werden behindert.

Im Übrigen kommt inklusives Design (Barrierefreiheit) allen zugute.

LLAP 🖖

[Regina Schaukrug]

Blinde kommen als Erfasser nicht in Betracht ?

Und Einäugige auch nicht.

Und Grünäugige auch nicht.

Und Rothaarige auch nicht.

Du erkennst, dass „… kommen nicht in Betracht“ Bullshit ist?

Naja. Wenn es um "Erfasser" geht, dann meint der TO wohl Angestellte, welche die Daten von Schriftstücken/Zetteln ablesen und eingeben. Weshalb Blinde von der Tätigkeit und damit der Nutzung der "Webseite" tatsächlich ausgeschlossen sind. Für mich geht das aus einigen anderen Äußerungen des des TO auch so hervor.

Was jetzt die mangelnde Sicherheit betrifft:

Es sollte nicht vergessen werden, dass eine nicht unbeträchtliche Zahl von Angriffen auf IT-Systeme von innen her erfolgt. Z.B. durch unzufriedene Mitarbeiter, von denen es ausgerechnet in den, sich selbst als "seriös" bezeichnenden Firmen, die, wie hier zweifelsfrei geradezu modellhaft vorliegend, mit einem "Fachkräftemangel" zu kämpfen haben, überdurchschnittlich viele gibt.

[Gunnar Bittersmann]

@@Regina Schaukrug

Naja. Wenn es um "Erfasser" geht, dann meint der TO wohl Angestellte, welche die Daten von Schriftstücken/Zetteln ablesen und eingeben. Weshalb Blinde von der Tätigkeit und damit der Nutzung der "Webseite" tatsächlich ausgeschlossen sind. Für mich geht das aus einigen anderen Äußerungen des des TO auch so hervor.

Selbst wenn deine Spekulation zutreffen sollte, wäre das kein Grund, anderes Markup zu verwenden als man es bei einer Webseite tun würde.

Es wäre allerdings ein Grund, den Workflow zu überdenken. Warum sind die Daten erst auf Zetteln und nicht gleich elektronisch erfasst? Warum „Erfasser“ und nicht OCR?

Es sollte nicht vergessen werden, dass eine nicht unbeträchtliche Zahl von Angriffen auf IT-Systeme von innen her erfolgt. Z.B. durch unzufriedene Mitarbeiter […]

Was nichts damit zu hat, dass man Systeme nach außen hin absichern muss.

LLAP 🖖

[Regina Schaukrug]

Warum sind die Daten erst auf Zetteln und nicht gleich elektronisch erfasst?

Ich rate mal: Gewinnspielcoupons

Warum „Erfasser“ und nicht OCR?

Solche Firmen beschäftigen zu Löhnen unter dem Gesetz und ohne Sozialabgaben zu zahlen. OCR ist denen zu teuer. Außerdem sind die Handschriften derer, die Gewinnspielcoupons ausfüllen, oft fürchterlich.

Zu gewinnen gibt es Preise a la "3 Tage-Reise nach Venedig für 99 Euro". (Tag 1 Abreise um 23:30, Tag 3 Ankunft um 07:00 - das wird aber sehr klein gedruckt...)

[Rolf b]

Ich weiß nicht, was du geändert hast, und auf Video gucken habe ich jetzt keine Lust. Jedenfalls habe ich dich in die Irre geführt und bitte um Entschuldigung. Natürlich muss man $sql an mysqli_query übergeben, und ein prepare ist dann nicht nötig.

Zum htmlspecialchars bei Debug-Echos... Da würde dir Franziskus Absolution erteilen, denke ich...

Rolf

[Matthias Apsel]

Hallo Rolf b,

Frohes Neues 🎆

Ebenso.

1. Im HTML.
Da gehört type="text" und ein Pattern hin.

Da type="text" der Standardwert ist, kann dieser Typ auch weggelassen werden.

Bis demnächst
Matthias

[pl]

Idee: Gib dem Kunden eine <textarea> oder ein contenteditable="true" wo er seine Postanschrift so reinschreibt wie sie auf einen Briefumschlag gehört.

MfG

[TS]

Hallo und guten Abend,

läßt sich verhindern daß bei input type="number"
am rechten Eingabefeldrand die Auf-/Ab-Pfeile erscheinen ?

Gibt es zu dieser Frage schon eine Lösung, oder habe ich die nur überlesen?

Grüße
TS

[Gunnar Bittersmann]

@@TS

läßt sich verhindern daß bei input type="number"
am rechten Eingabefeldrand die Auf-/Ab-Pfeile erscheinen ?

Gibt es zu dieser Frage schon eine Lösung, oder habe ich die nur überlesen?

JürgenB hatte eine genannt. Die ist aber nicht „schon“, sondern eher „noch“.

LLAP 🖖

[TS]

Hallo und guten Morgen Gunnar,

JürgenB hatte eine genannt. Die ist aber nicht „schon“, sondern eher „noch“.

Danke für die Klarstellung. Das hatte ich jetzt tatsächlich so aufgefasst, dass "man es nicht macht" weil es sowieso nicht funktioniert. Es funktioniert aber doch in den meisten mir zugänglichen Browsern (noch).

Und Du meinst, dass es da demnächst noch ein zusätzliches Attribut geben könnte, das das Verhalten steuert?

Was mich an diesen Input-Constraints stört: Warum nehmen die überhaupt erst Zeichen an, die nicht reingehören? In der guten alten Zeit hätte man die Eingabe abgelehnt und ein kurzes BELL-Signal ausgegeben.

Browser sind und bleiben scheinbar Kinderkakke!

Grüße
TS

[Linuchs]

In der guten alten Zeit hätte man die Eingabe abgelehnt und ein kurzes BELL-Signal ausgegeben.

Zeigen, nicht nur quasseln.

BELL-Signal - so echt, dass meine Hundemeute beim Anhören mitgebellt hat.

Linuchs