Bekomme ich fiat mit Komma neben volvo?
Sicher (implode hilft), aber wie du schon bemerkt hast: das macht man nicht. Bau das Datenbankdesign so um dass jeder Eintrag eine Zeile (in einer extra Tabelle) bekommt. Dir wird ein kaputtes Datenbankdesign sonst früher oder später auf die Füße fallen und du musst es unter großem Aufwand dann doch korrigieren, mach es also besser gleich richtig.
Genau was ich befürchtet hatte: Die Schleife läuft leer durch, anschließend haben $key und $val jeweils den letzten Wert. Du musst das Eintragen in die DB innerhalb der Schleife erledigen:
Und prepared Statements dabei natürlich richtig verwenden - so wie du das machst ist es falsch: im Query dürfen nur Platzhalter stehen, die Werte werden mit execute (bzw. eine bind-Methode) übergeben (Pseudocode):
$query = "INSERT INTO tabelle (spalte) VALUES (:value)"
$stm = $db->prepare($query)
foreach($_POST[…] as …){
$stm->execute(['value' => $value])
}Zudem fehlt beim Aufbau der Datenbankverbindung noch ein »;charset=utf8mb4« am Ende des DSN (bei dir die Variable $server) damit definiert ist in welcher Form du Daten bekommst bzw. in welcher Form sie die Datenbank erwartet - wenn du das weglässt bist du auf die Standardeinstellung angewiesen und die kann sich ändern.
Aber bei Codepen zeigt er mir das nur richtig an wenn nth-child 4,5,6,7 sind.
In das HTML-Feld gehört nur das was in <body> steht, kein vollständiges HTML-Dokument (das CSS entsprechend ins CSS-Feld).
Ich hatte es einfacherhalber mit Komma in die Datenbank schreiben lassen um im Nachgang die Werte nicht wieder in Komma umwandeln lassen muss.
Die Datenbank brauch einen Punkt, sonst kann sie nicht damit rechnen. Andersrum wird eher ein Schuh daraus: verwende intern immer den Punkt als Dezimaltrenner - nur dann wenn du die Werte als Text (in einem Eingabefeld bleibt der Punkt) ausgibst, bekommt der Benutzer den Wert ordentlich mit Komma formatiert angezeigt.
Wie meinst Du das mit dem output-Element? Stehe da gerade etwas auf dem Schlauch?
Die Felder die ein readonly-Attribut haben sind doch dazu da um die Ergebnisse von Javascript-Berechnungen auszugeben, oder? Das sind also keine Eingabe- sondern Ausgabefelder - und dafür gibt es output (die natürlich nur sichtbar sein sollten wenn Javascript auch aktiviert ist, ohne JS sind die ja relativ sinnlos)
Zu SELECT *...was spricht in dem konkreten Fall gegen ein *?
Siehe z.B. https://www.pg-forum.de/t/warum-man-ke…den-sollte/5062 (ja, der Eintrag ist schon älter, er ist aber immer noch aktuell)
Der Wert nach dem gesucht wird, ist quasi unveränderbar vorgegeben und kann durch den Benutzer nicht geändert werden.
Das ist ein Irrtum: der Wert wird per POST-Request übertragen und kann damit vom Benutzer manipuliert werden (schon klar, vielleicht nicht von jedem Laien grundsätzlich ist es aber möglich). Kontextwechsel müssen *immer* behandelt werden ohne Ausnahme! (das gilt übrigens nicht nur für die zu SQL sondern z.B. auch für die nach HTML, d.h. wenn du irgendwas im HTML-Code an den Browser ausgibst)
Es gibt 20 Posten-Möglichkeiten bei einem Angebot die einzeln hinterlegt werden.
Da lag ich ja richtig, das Datenbankdesign ist tatsächlich kaputt: was ist wenn z.B. nur ein Posten hinterlegt wird, oder was ist wenn es mal 21 Posten sein sollen? Die Posten gehören in eine zweite Tabelle in der jeder Datensatz einen Posten zu einem Angebot enthält - beschäftige dich mit dem Thema Normalisierung.
Bist du bei deinem eigentlichen Problem weitergekommen? Liegt es an dem Komma als Feldtrenner an dem Javascript wieder aufgetrennt wird?
Ich lasse mittel Ajax ein Formular (Kostenangebot) aus einer Datenbank füllen, darunter auch reichlich Input-Felder mit Preisen. Diese haben bekannter Weise das Format 12,34, sprich 2 Nachkommastellen. In der Datenbank selbst ist das richtige Format hinterlegt (mit Komma, nicht mit Punkt).
Wie kommst du darauf dass es mit Komma richtig wäre? Richtig ist mit Punkt, alle Programmiersprachen (und auch HTML, siehe unten) und Datenbanken erwarten einen Punkt als Dezimaltrenner.
Auszug aus dem Formular was mittels Ajax gefüllt wird:
Das Formular ist kaputt:
Die stmmactionangebot.php:
PHP<?php session_start(); $connect = mysqli_connect("localhost", "*****", "******", "office"); $angebotsnummer = $_POST["angebotsnummer"]; $code = $_POST["angebotsnummer"]; $query = "SELECT * FROM angebote WHERE angebotsnummer = $angebotsnummer "; $result = mysqli_query($connect, $query); while($erg = mysqli_fetch_assoc($result)) echo $erg["kundennummer"] . "," . $erg["anrede"] . "," […]; ?>
Der Code hat gleich mehrere Problem (eines davon ist gefährlich!):
Dein eigentliches Problem dürfte aber das unpassende Datenformat sein in dem du die Werte an Javascript schickst: du klebst einfach alles mit Komma zusammen und trennst es im Javascript wieder auf - allerdings ohne Rücksicht darauf ob der Wert selbst auch ein Komma enthält … Verwende besser ein Format wie JSON, damit solltest du das Problem nicht haben (PHP und Javascript können beide standardmäßig mit JSON umgehen).
Gibt es da eine Möglichkeit?
Nein. Wie der Funktionsname schon sagt verschlüsselt die Funktion nicht, sie erstellt ein Hash des Passworts - und dieser Vorgang ist nicht umkehrbar. Wenn ein Benutzer sein Passwort vergessen hat bleibt nur ein neues zu setzen - wobei dass ein Benutzer normalerweise ohne Hilfe des Admins machen können sollte.
Geht es noch kürzer ?
Klar: Zeilenumbrüche entfernen, </form> weglassen, name-Attribut weg, Anführungszeichen um Attributwerte weglassen, das Bild im gleichen Verzeichnis speichern und nur "b" nennen; zudem noch den PHP-Teil nach hinten (spart das »?>«), dort das if weglassen und die Kurzform des php-Tag verwenden (»<?=var_dump($_GET);«). var_dump() ist zum einen gefordert und zum anderen gibt print_r immer was zurück was - auf Kosten zusätzlicher Zeichen - unterdrückt werden müsste wenn man <?= verwenden will.
Natürlich ist das valide, warum sollte es das nicht sein? Input mit type="image" ist valides HTML.
das input selbst ist grundsätzlich schon valide, meine gesamte Konstruktion aber nicht: es fehlt das HTML-Grundgerüst und z.B. das alt-Attribut des input. Wobei mir auffällt dass auch 49 Zeichen reichen: da waren noch 4 Anführungszeichen drin die man weglassen kann.
Wie viele Zeichen braucht ihr?
Welchen Weg geht ihr da?
53. Allerdings entspricht das nicht ganz der Aufgabenstellung, um das Bild darzustellen habe ich ein input mit type=image verwendet, ein Klick darauf überträgt die Koordinaten des Klicks womit keinerlei Javascript notwendig ist. Valide usw. ist das natürlich überhaupt nicht, da mir die Aufgabe aber wohl in Richtung wie CSSBattle geht ist das in dem Fall schon ok.
Das sollte schon gehen.
Nein, da der Pfad ($verzeichnis) fehlt.
genauer habe ich mir den Code jetzt nicht angesehen, aber verwende statt "keyup" mal "input" als Eventhandler.
Einer div-Box, die absolut positioniert ist (das Framework berechnet das Layout server-seitig),
… und hat sich damit selbst disqualifiziert. Ein Layout kann nicht serverseitig berechnet werden und postion als Layoutmittel ist auch nur sehr mäßig sinnvoll - verwende grid bzw. flex und lass den Browser das Rechnen machen.
Genau dies war die Lösung.
Nein ist es nicht. Damit trittst du die Barrierefreiheit mit Füßen (nein, auch ein Auftraggeber ist kein Grund, Barrierefreiheit ist für Seiten afaik teilweise sogar Pflicht!) - deswegen habe ich auch nicht auf outline hingewiesen (das war in diversen Threads schon öfters für solche Rahmen verantwortlich), auch weil ich immer noch auf Code gewartet hatte …
Hat jemand von euch eine Idee wie ich diesen Rahmen ausblenden kann?
Ohne den Code der Seite zu kennen lässt sich da nur raten, ich würde aber mal darauf tippen dass die Antwort lautet: am besten garnicht. Vermutlich ist der Rahmen dazu da um die Tabs auch per Tastatur bedienbar zu machen - und wenn du den Rahmen entfernst, lassen sich die Tabs nicht mehr per Tastatur bedienen da nicht mehr erkennbar ist welcher Tab gerade den Focus hat.
Wegen dein :Focus funktioniert das auch nur beim a Element , falls ich mich jetzt nicht irre.
Du irrst dich, <button> kennt auch :focus.
Ich habe eine Seite erstellt, welche über AJAX und JavaScript mehrere Farbcodes und Namen hierzu aus einer JSON-API zieht (Feste Anzahl).
Es gibt dann eine Tabelle, in welcher der Zellenhintergrund in dem Farbcode gefärbt wird und der Name als Inhalt drin steht. Das funktioniert auch alles schon soweit gut. Nun kann es aber vorkommen, dass der Farbcode Schwarz ist - und die Schrift auch. Das verringert die Lesbarkeit enorm, insbesondere auf einem Ausdruck
Eine direkte Lösung habe ich jetzt auch nicht, da wirst du wohl den Kontrast berechnen und ggf. auf weiße Schrift umschalten müssen (falls es Farben gibt auf denen weder weiß noch schwarz gut lesbar ist ggf. noch weitere Schriftfarben vorhalten).
Nachtrag: ich habe nicht genau genug gelesen, sowas hast du ja drin, nur funktioniert es nicht (warum hat Sempervivum ja schon geschrieben). Evtl. kann ein Blick auf den verlinkten Kontrastrechner trotzdem nicht schaden, evtl. berechnet der das anders/besser?
Es ist auch JScript eingebunden, da die Scriptvorlage die ich gefunden und angepasst habe dies nutzt. Das funktioniert auch. Wenn ich es recht verstanden habe ist im JScript $ als "Zentraler Name" definiert. Das finde ich aber nirgends und ich vermute, dass ich einfach den Wald vor lauter Bäumen nicht sehe
Wie schon geschrieben: jQuery, nicht jScript (das ist was anderes). Was das $ bedeutet steht im Handbuch zu jQuery - was da allerdings nicht steht, ist dass jQuery hier völlig überflüssig ist: du nutzt nur $(document).ready() und dafür reicht Vanilla-JS völlig aus. Ein einfaches document.addEventListener('DOMContentLoaded', … ); macht das gleiche, spart aber die JQuery-Datei. Der Ajax-Request würde sich auch mit jQuery lösen lassen, ist aber auch nicht nötig: Fetch API existiert.
document.getElementById('weft_1_cell').bgColor = colorAPI['WeftList'][0]['ColorList'][0]['ColorItem']['Color']; document.getElementById('weft_1').value = colorAPI['WeftList'][0]['ColorList'][0]['ColorItem']['Name'];
Ohne jetzt den HTML-Code dazu zu kennen, würde ich mal schwer vermuten dass man das mit einer kurzen Schleife und ohne die IDs abfrühstücken kann.
Alles bündig, wie es gewünscht wird.
Nicht wirklich:
html-seminar.de/woltlab/attachment/3114/
und auch in der breiten Ansicht sind die vier Elemente nicht wirklich bündig - mit etwas Pixel-Schubbsen wird das aber auch nichts.
