Checkboxen im PHP mit SQL

[PHP-Neuling]

Hi, wie sicherlich jeder 2. Beitrag hier, startet auch dieser mit dem Intro "Sorry, ich bin absoluter Neuling"

Ich habe gerade erst mit PHP angefangen, habe mir 2 Bücher geholt und nun angefangen eine erste Seite zu entwickeln (für die Firma)

Ich muss zugeben, dass es erstmal ungewöhnlich mit PHP ist. Die ganzen Punkte und echos. Aber die ersten Schritte laufen mittlerweile ganz gut. Meine Bücher erläutern aber leider nicht alle Themen. Beispielsweise Checkboxen und/oder Radio Buttons

Ich sehe/verstehe einfach nicht, wie ich da hin komme. Daher die 2 Fragen

Wie sende ich eine 1 in die Datenbank, wenn eine checkbox gesetzt ist? Und vor allem - und daran scheiterts tatsächlich am ehesten - Wie lese ich im input aus, ob der Datenbankeintrag für diese spezielle Checkbox "1" ist, und lasse anschließend die Checkbox "checked" anzeigen?

Ich komme da einfach nicht dahinter. Hoffentlich ist jemand bereit mir da zu helfen.

Zur Technik

mein query in die DB läuft über die Variable $DATA anschließend wird eine Tabelle angezeigt, deren Inhalte aus der DB kommen sollen while ($Datensatz = $DATA->fetch_object()) { ?> Die TDs enthalten alle <input> Felder <td>IrgendEinWert</td><td><input type="text" name="IrgendEinWert" value="<?php echo $Datensatz->IrgendEinWert; ?>"></td> Die Inhalte werden angezeigt, soweit so gut. Aber wie frage ich <input type="checkbox" name="IrgendEineCheckBox" value=1"> ab?

Viele Grüße. und bleibt gesund

[TS]

Hello,

Ich muss zugeben, dass es erstmal ungewöhnlich mit PHP ist. Die ganzen Punkte und echos. Aber die ersten Schritte laufen mittlerweile ganz gut. Meine Bücher erläutern aber leider nicht alle Themen. Beispielsweise Checkboxen und/oder Radio Buttons

Ich sehe/verstehe einfach nicht, wie ich da hin komme. Daher die 2 Fragen

Wie sende ich eine 1 in die Datenbank, wenn eine checkbox gesetzt ist?

Die Frage wird in ein paar Minuten eher lauten: wie erkenne ich, dass ich ein FALSE (oder eine 0) an die Datenbank übermitteln muss, wenn kein Checkbox-Parameter übertagen wurde?

Vielleicht sollte ja außerdem gerade dieses Datensatzfeld gar nicht durch den Benutzerdialog bedient werden? Solch ein Szenario ist durchaus möglich und üblich!

Das Problem ist also komplexer!

Ein paar Grundregeln der CS-Dialog-Datenverarbeitung:

• verändere nichts, was Du vorher nicht gelesen hast
• arbeite mit Sessions. Datensätze, deren alter Inhalt sich nicht im Sessionpuffer befindet, dürfen nicht verändert werden
• beschaffe dir aus der Datenbank (Metadaten der Tabelle, INFORMATION_SCHEMA) die Spaltentypen
• prüfe bei der Antwort vom Client die Darstellbarkeit der Requestparameter im Zieltyp der Datenbanktabelle.
• beachte den Kontextwechsel und das passende Escaping
• speichere dir in der Session alle Felder des Formulars, die bei der nachfolgenden Antwort (dem Update Request) des Clients vorhanden sein müssen und dürfen. Nur Checkboxen und Radios dürfen in den Post-Parametern fehlen. Alle anderen müssen vorhanden sein. Mehr Parameter dürfen nicht vorhanden sein.
• bei auftretenden Fehlern schreibe einen Logeintrag in dein Textlog der App, der dann durch fail2ban verstanden und behandelt werden kann.

Es gibt noch viel mehr dazu zu schreiben, damit es ein Kochrezept wird. Aber fang erst einmal langsam an und stelle deine Fragen dazu.

Glück Auf
Tom vom Berg

[PHP-Neuling]

Hi

Ich danke Dir erst einmal für deine Reaktion.

Die Frage wird in ein paar Minuten eher lauten: wie erkenne ich, dass ich ein FALSE (oder eine 0) an die Datenbank übermitteln muss, wenn kein Checkbox-Parameter übertagen wurde?

Hier dachte ich daran, standartmäßig eine "NULL" zu verschicken, ausser eben die checkbox hat einen Wert. wenn ich das richtig verstanden habe, werden Checkboxen ausschließlich übertragen beim POST, wenn sie gesetzt sind ?!

• verändere nichts, was Du vorher nicht gelesen hast

Hier verstehe ich den Zusammenhang nicht

• arbeite mit Sessions. Datensätze, deren alter Inhalt sich nicht im Sessionpuffer befindet, dürfen nicht verändert werden

Mein grundlegendes Konzept geht von Session-Variablen aus. Auch wenn ich noch nicht soweit bin, um diese im PHP umzusetzen 😀 Das aber wird später Thema, welches ich mir aus den Büchern ziehe

• beschaffe dir aus der Datenbank (Metadaten der Tabelle) die Spaltentypen

Was meinst du mit Spaltentypen? Ich lese über den fetch alle Daten der DB aus, welche die ID "ID1" haben. Die ID1 ist ein querystring aus einer vorherigen Übersichtsseite

• prüfe bei der Antwort vom Client die Darstellbarkeit der Requestparameter im Zieltyp der Datenbanktabelle.

Auch hier stehe ich auf dem Schlauch

• beachte den Kontextwechsel und das passende Escaping

siehe eins oben drüber

• speichere dir in der Session alle Felder des Formulars, die bei der nachfolgenden Antwort (dem Update Request) des Clients vorhanden sein müssen und dürfen. Nur Checkboxen und Radios dürfen in den Post-Parametern fehlen. Alle anderen müssen vorhanden sein. Mehr Parameter dürfen nicht vorhanden sein.

Checkboxen und Radios sollen fehlen? mhh

Jetzt bin ich in gesamtheitlicher Sicht noch mehr verwirrt, als vorher schon 🐵

[Auge]

Hallo

Die Frage wird in ein paar Minuten eher lauten: wie erkenne ich, dass ich ein FALSE (oder eine 0) an die Datenbank übermitteln muss, wenn kein Checkbox-Parameter übertagen wurde?

Hier dachte ich daran, standartmäßig eine "NULL" zu verschicken, ausser eben die checkbox hat einen Wert.
wenn ich das richtig verstanden habe, werden Checkboxen ausschließlich übertragen beim POST, wenn sie gesetzt sind ?!

Das ist korrekt.

Wenn man statt kein Wert/ein Wert immer einen Wert (im Zweifelsfall einen definierten Nein-Wert, zum Beispiel 0) haben will, benutzt man (je nach Anwendungsfall) statt der Checkbox(en) Radio-Buttons mit einem vordefiniertem Standardwert oder man benutzt zusätzlich zur Checkbox ein davorstehendes Hidden-Feld gleichen Namens mit dem Standardwert. Wird die Checkbox nicht aktiviert, wird der Wert des Hidden-felds übertragen, ist die Checkbox angeklickt, überschreibt ihr Wert den des Hidden-Felds.

<input type="hidden" name="agb-zustimmung" value="0">
<input type="checkbox" name="agb-zustimmung" id="id-agb" value="1"><label for="id-agb">ich stimme der AGB zu</label>

• beschaffe dir aus der Datenbank (Metadaten der Tabelle) die Spaltentypen

Was meinst du mit Spaltentypen?

Die Spalten der Datenbanktabelle haben Datentypen (zum Beispiel varchar für Text, int für Ganzzahlen, datetime für ein Datum mit Uhrzeit). Das lässt sich bedingt automatisiert auf die HTML-Eingabefeldtypen übertragen. Wenn man selbst die Anwendung schreibt und die Strukturen nicht zu unübersichtlich sind, kann man diese Zuordnung (Feldtyp in der Datenbank zu Feldtyp des Eingabefelds im HTML-Quelltext) auch händisch vornehmen.

• prüfe bei der Antwort vom Client die Darstellbarkeit der Requestparameter im Zieltyp der Datenbanktabelle.

Auch hier stehe ich auf dem Schlauch

Selbes Vorgehen wie oben, nur umgekehrt (HTML nach Datenbank)

• beachte den Kontextwechsel und das passende Escaping

siehe eins oben drüber

Artikel zum Thema Kontextwechsel in unserem Wiki.

Checkboxen und Radios sollen fehlen? mhh

Nein, sie dürfen fehlen; zumindest Checkboxen dürfen das (wenn du nicht Vorkehrungen triffst).

Tschö, Auge

[PHP-Neuling]

okay jetzt hab ich das verstanden. Es ging um die Datentypen. Die habe ich über die mysqlbench angepasst, chars, int's und tinyint's für die checkboxen. Passt auch (meines wissens nach) mit meinen input und formularfeldern zusammen

Bei den Checkboxen hätte ich eben gern "0" oder "1". Der weg um das "immer" zu erreichen wäre das von dir angesprochene Hidden field. Finde ich sinnvoll, irgendwie

Nun stellt sich wieder die Frage ... Wie rufe ich beim Laden der Site ab, dass $IrgendEinWert1 eine 1 innehat, und setze somit die checkbox als "checked" ? <?php if $IrgendEinWert1 == 1 ...?> funktioniert so nicht ❓

grüße, und nochmal vielen Dank an Alle

[Felix Riesterer]

Lieber PHP-Neuling,

Bei den Checkboxen hätte ich eben gern "0" oder "1". Der weg um das "immer" zu erreichen wäre das von dir angesprochene Hidden field. Finde ich sinnvoll, irgendwie

finde ich grauselig, irgendwie.

Wenn ich in der DB immer eine 0 oder eine 1 stehen habe, dann gefällt mir das nicht. Lieber wäre mir null oder 1. Oder es steht eben kein Eintrag da, oder doch. Kommt auf Deine DB-Struktur an.

<?php if $IrgendEinWert1 == 1 ...?> funktioniert so nicht ❓

Es benötigt das checked-Attribut.

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

hy

ja, genau so hatte ich das versucht, da mir das so logisch vorkam

<input type="checkbox" name="IrgendEinName1" value="1" <?php IF ($DATA->irgendeinwert1 ==1 ) { "checked="checked" "; }?> />

Aber das war nicht erfolgreich. Die Checkbox nicht gesetzt, kein Fehler. Der Wert "1" stand bereits in der Tabelle (Zum Test per Hand eingetragen)

[Der Martin]

Hallo,

> <input type="checkbox" name="IrgendEinName1" value="1" <?php IF ($DATA->irgendeinwert1 ==1 ) { "checked="checked" "; }?> />

das schmeißt zumindest einen Syntaxfehler, weil "checked="checked" " keine gültige PHP-Anweisung ist.

Außerdem ist die Großschreibung bei Keywords (wie hier das if) sehr unüblich.

Live long and pros healthy,
 Martin

[PHP-Neuling]

okay da hatte ich was verwechselt ... so hier scheints zu gehen

<?php if ($Datensatz->IrgendEinWert1 == 1) { ?> checked="checked"<?php  };?>>

[PHP-Neuling]

... wobei ich mich frage, ob das der richtige weg ist? Das ist ja eine riesige Codezeile für eine popelige Checkbox

<input type="checkbox" name="checkboxen[]" value="IrgendEinWert1" <?php if ($Datensatz->IrgendEinWert1 == 1) { ?> checked="checked"<?php  };?>>

[Gunnar Bittersmann]

@@PHP-Neuling

... wobei ich mich frage, ob das der richtige weg ist?

Geschweifte Klammern im HTML-Template halte ich nicht für den richtigen Weg. Da bietet sich die alternative Syntax für Kontrollstrukturen an. S.a. diese Diskussion von Anfang bis Ende.

Das ist ja eine riesige Codezeile für eine popelige Checkbox

Du kannst ja Zeilenumbrüche machen:

	<input
		type="checkbox"
		name="checkboxen[]"
		value="IrgendEinWert1"
<?php if ($Datensatz->IrgendEinWert1 == 1): ?>
		checked="checked"
<?php endif; ?>
	/>

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[dedlfix]

Tach!

... wobei ich mich frage, ob das der richtige weg ist? Das ist ja eine riesige Codezeile für eine popelige Checkbox

<input type="checkbox" name="checkboxen[]" value="IrgendEinWert1" <?php if ($Datensatz->IrgendEinWert1 == 1) { ?> checked="checked"<?php  };?>>

Ja, die Länge des Codes ist nicht weiter relevant. Hauptsache ist, dass er verständlich ist. Der Computer kann auch mit größeren Datenmengen sehr gut umgehen. Die Wartbarkeit für Menschen ist das wichtigere Kriterium.

Wenn du abkürzen möchtest, dann zum Beispiel so:

<input type="checkbox" name="checkboxen[]" value="IrgendEinWert1" <?= $Datensatz->IrgendEinWert1 ? 'checked' : ''?>>

Das Attribut checked muss nur da sein. Es muss keinen Inhalt haben. Selbst wenn es als checked="" dasteht, ist es gesetzt.

Es kann sinnvoll sein, für HTML-Code den PHP-Block zu verlassen. Vor allem dann, wenn es sich nicht nur um Stückchen sondern ganze Elemente (eins oder mehrere) handelt. Solchen Code kann dann auch ein Editor besser mit Highlighting etc. unterstützen, weil er die Syntaxbereiche besser erkennen kann. Wenn stattdessen ein String-Literal Code enthält, ist das für die Editoren schwerer zu erkennen.

<?php if ($error) { ?>
    <p>Fehler vorhanden.</p>
<?php } ?>

oder auch

<?php if ($error): ?>
    <p>Fehler vorhanden.</p>
<?php endif; ?>

Welche der beiden Varianten du verwendest, ist eine Sache der persönlichen Vorliebe.

In deinem Fall fügst du lediglich das checked hinzu oder auch nicht, da ist es durchaus vertretbar, das als String in PHP zu notieren statt zwei PHP-Blöcke und einen HTML-Bereich dazwischen zu haben.

Die Test-Bedingung auf = 1 kann man weglassen, denn der Wert 1 wird im booleschen Kontext bereits als true anerkannt, und die Alternative 0 oder auch NULL als false.

Und zu guter Letzt kann man das if-Konstrukt durch den ternären Operator ?: ersetzen, als auch das eingebaute echo bei <?= verwenden.

dedlfix.

[TS]

Hello,

... wobei ich mich frage, ob das der richtige weg ist? Das ist ja eine riesige Codezeile für eine popelige Checkbox

<input type="checkbox" name="checkboxen[]" value="IrgendEinWert1" <?php if ($Datensatz->IrgendEinWert1 == 1) { ?> checked="checked"<?php  };?>>

Das macht doch nichts. Du musst sie doch nur ein einziges Mal schreiben, wenn Du eine Funktion daraus machst.

Und das System wiederholt sie dann wo und wie oft Du willst ;-)

Glück Auf
Tom vom Berg

[PHP-Neuling]

das wäre sogar ganz großartig, da ich sehr viele von diesen Checkboxen habe Aber ich wüsste nicht, wie man das umsetzt

nochmal vielen Dank an Alle. Das Abkürzen und lesbarer machen des Codes ist sehr hilfreich, auch wenn ich nicht alles umsetzen werde, um auch später noch erkennen zu können was ich da gemacht habe ;) Als Neulanddraufgänger geht halt doch das ein oder andere mal verloren

Grüße

[Tabellenkalk]

Hallo,

Aber ich wüsste nicht, wie man das umsetzt

Mit folgenden Stichworten solltest du in deinen Büchern fündig werden: Schleifen und Funktionen.

Gruß
Kalk

[Felix Riesterer]

Lieber PHP-Neuling,

... wobei ich mich frage, ob das der richtige weg ist? Das ist ja eine riesige Codezeile für eine popelige Checkbox

ich persönlich vermische keinen HTML-Code mit PHP-Code. In meinen Projekten steht HTML-Code in HTML-Dateien und PHP-Code in PHP-Dateien.

Um nun HTML-Dokumente dynamisch zu erstellen, verwende ich die DOMDocument-Klasse von PHP. Damit kann ich vorhandene HTML-Dateien einlesen, um sie wie Vorlagen zu behandeln.

Andere verwenden Template-Systeme. Aber Du hast ja erst angefangen. Da willst Du bestimmt nicht auch noch damit erschlagen werden.

Liebe Grüße

Felix Riesterer

[Matthias Apsel]

Hallo Felix Riesterer,

ich persönlich vermische keinen HTML-Code mit PHP-Code. In meinen Projekten steht HTML-Code in HTML-Dateien und PHP-Code in PHP-Dateien.

Um nun HTML-Dokumente dynamisch zu erstellen, verwende ich die DOMDocument-Klasse von PHP. Damit kann ich vorhandene HTML-Dateien einlesen, um sie wie Vorlagen zu behandeln.

Kannst du mal ein Beispiel geben?

Etwa: Es soll eine DB für Autos erstellt werden. Die Einträge dieser DB sollen bearbeitet werden können. Die HTML-Seite könnte also autos_bearbeiten.html heißen.

Wenn in der DB noch keine Autos vorhanden sind, soll ein leeres Formular angezeigt werden, anderenfalls sollen in einer Tabelle die vorhandenen Autos dargestellt werden.

Bis demnächst
Matthias

[Felix Riesterer]

Lieber Matthias,

Kannst du mal ein Beispiel geben?

das würde in einem Tutorial ausarten. Hast Du da gerade eines bestellt? ;-)

Liebe Grüße

Felix Riesterer

[Matthias Apsel]

Hallo Felix Riesterer,

Kannst du mal ein Beispiel geben?

das würde in einem Tutorial ausarten. Hast Du da gerade eines bestellt? ;-)

Wenn du so nett sein könntest …
Dem Wiki schadet es sicher nicht.

Bis demnächst
Matthias

[Felix Riesterer]

Lieber Matthias,

Kannst du mal ein Beispiel geben?

das würde in einem Tutorial ausarten. Hast Du da gerade eines bestellt? ;-)

Wenn du so nett sein könntest …

[x] done

Kritik dazu gerne, aber bitte (natürlich!) in einem neuem Thread.

Liebe Grüße

Felix Riesterer

[Gunnar Bittersmann]

@@Matthias Apsel

Wenn in der DB noch keine Autos vorhanden sind, soll ein leeres Formular angezeigt werden, anderenfalls sollen in einer Tabelle die vorhandenen Autos dargestellt werden.

Und das Formular für ein weiteres Auto, evtl. hinter „+ Auto hinzufügen“ versteckt.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello lieber Felix,

Bei den Checkboxen hätte ich eben gern "0" oder "1". Der weg um das "immer" zu erreichen wäre das von dir angesprochene Hidden field. Finde ich sinnvoll, irgendwie

finde ich grauselig, irgendwie.

Wenn ich in der DB immer eine 0 oder eine 1 stehen habe, dann gefällt mir das nicht. Lieber wäre mir null oder 1. Oder es steht eben kein Eintrag da, oder doch. Kommt auf Deine DB-Struktur an.

Es ist allgemeiner Konsens (nicht Gesetz) bei Datenbanken, dass NULL in Feldern bedeutet, dass dieses Feld noch keine Bearbeitung erfahren hat, der Benutzer noch keine Entscheidung getroffen hat. Es lässt also in diesem Beispiel die Spaltenwerte NULL, FALSE bzw 0 und TRUE bzw 1 zu.
Ob NULL überhaupt erlaubt ist und wie der Default lautet legt man ja beim CREATE-Statement der Tabelle fest.

Bei SQL-Abfragen muss man das dann je nach DBMS auch extra beachten.

Und zu deinem anderen Vorschlag: Wieso sollte man in die Datenbank nicht gleich checked="checked" {1} für TRUE eintragen und □ (Leerstring) für FALSE? Auf die paar Bytes kommt es heutzutage auch nicht mehr an.

{1} mir persönlich würde ja checked auch genügen, aber da war doch mal was?
Das kann @Gunnar Bittersmann vielleicht besantworten.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Und zu deinem anderen Vorschlag: Wieso sollte man in did Datenbank nicht gleich checked="checked" {1} für TRUE eintragen und "" für FALSE?

Weil die Datenbank agnostisch sein sollte, wofür die Daten verwendet werden und wie sie ausgegeben werden. Es könnte auch andere Ausgabeformate als HTML geben (PDF, native Apps, …). HTML-Code hat in der Datenbank i.d.R. nichts zu suchen.

{1} mir persönlich würde ja checked auch genügen, aber da war doch mal was?

checked würde in HTML-Syntax genügen; in XHTML-Syntax muss jedes Attribut einen Wert zugewiesen bekommen.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello,

Und zu deinem anderen Vorschlag: Wieso sollte man in did Datenbank nicht gleich checked="checked" {1} für TRUE eintragen und "" für FALSE?

Weil die Datenbank agnostisch sein sollte, wofür die Daten verwendet werden und wie sie ausgegeben werden. Es könnte auch andere Ausgabeformate als HTML geben (PDF, native Apps, …). HTML-Code hat in der Datenbank i.d.R. nichts zu suchen.

Das stimmt!
Diese Grundregel hatte ich doch tatsächlich noch nicht berücksichtigt ;-)

Glück Auf
Tom vom Berg

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Und zu deinem anderen Vorschlag: Wieso sollte man in did Datenbank nicht gleich checked="checked" {1} für TRUE eintragen und "" für FALSE?

Weil die Datenbank agnostisch sein sollte, wofür die Daten verwendet werden und wie sie ausgegeben werden. Es könnte auch andere Ausgabeformate als HTML geben (PDF, native Apps, …). HTML-Code hat in der Datenbank i.d.R. nichts zu suchen.

Attribute und Parameter sind aber Daten und keine Auszeichnung (HTML), auch wenn sie im HTML notiert werden. Ob da nun Richtig, Falsch oder checked ausgeschrieben in der Datenbank steht, ändert nichts daran, dass es ein Datenwert ist. Das ist nur eine Frage, ob man vollständig normalisieren will.

Außerdem kennt z.B. MySQL auch dee Spaltentypen ENUM und SET, die hier schon eine Übersetzung von Klartext in binär vornehmen.

Spirituelle Grüße
Euer Robert

[Der Martin]

Hallo,

Außerdem kennt z.B. MySQL auch dee Spaltentypen ENUM und SET, die hier schon eine Übersetzung von Klartext in binär vornehmen.

und soweit ich weiß auch BOOL, was für eine reine Ja/Nein-Aussage prädestiniert wäre.

Live long and pros healthy,
 Martin

[TS]

Hello,

Hallo,

Außerdem kennt z.B. MySQL auch dee Spaltentypen ENUM und SET, die hier schon eine Übersetzung von Klartext in binär vornehmen.

und soweit ich weiß auch BOOL, was für eine reine Ja/Nein-Aussage prädestiniert wäre.

Ich bin gerade am Wanken. Welchen Datentyp würde ich wählen, wenn die Entscheidung nicht zwischen Richtig und Falsch, sondern zwischen Rot und Blau fallen müsste? ;-p

Glück Auf
Tom vom Berg

[Der Martin]

Hi,

Außerdem kennt z.B. MySQL auch dee Spaltentypen ENUM und SET, die hier schon eine Übersetzung von Klartext in binär vornehmen.

und soweit ich weiß auch BOOL, was für eine reine Ja/Nein-Aussage prädestiniert wäre.

Ich bin gerade am Wanken. Welchen Datentyp würde ich wählen, wenn die Entscheidung nicht zwischen Richtig und Falsch, sondern zwischen Rot und Blau fallen müsste? ;-p

hmm, da wäre ENUM sicher eine semantisch passende Alternative.
Und wie ist es bei Ja, Nein, Vielleicht und Egal? - Diese Alternativen lassen sich schon in eine Reihenfolge bringen - wobei die Differenzierung zwischen Vielleicht und Egal (beide eindeutig zwischen Ja und Nein) schwierig ist. Aber ein ENUM als reiner Aufzählungstyp würde der Bedeutung nicht gerecht, finde ich.

Live long and pros healthy,
 Martin

[Tabellenkalk]

Hallo,

und soweit ich weiß auch BOOL, was für eine reine Ja/Nein-Aussage prädestiniert wäre.

Ich bin gerade am Wanken. Welchen Datentyp würde ich wählen, wenn die Entscheidung nicht zwischen Richtig und Falsch, sondern zwischen Rot und Blau fallen müsste? ;-p

Das wäre nur in Pillenform boolesch

Gruß
Kalk

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

und soweit ich weiß auch BOOL, was für eine reine Ja/Nein-Aussage prädestiniert wäre.

Ich bin gerade am Wanken. Welchen Datentyp würde ich wählen, wenn die Entscheidung nicht zwischen Richtig und Falsch, sondern zwischen Rot und Blau fallen müsste? ;-p

Das wäre nur in Pillenform boolesch

Da gibts aber auch noch die gestreiften. Die sind aber diaboleisch.

Spirituelle Grüße
Euer Robert

[Gunnar Bittersmann]

@@robertroth

Attribute und Parameter sind aber Daten und keine Auszeichnung (HTML), auch wenn sie im HTML notiert werden. Ob da nun Richtig, Falsch oder checked ausgeschrieben in der Datenbank steht, ändert nichts daran, dass es ein Datenwert ist.

Tom wollte aber nicht checked in die Datenbank schreiben, sondern checked="checked". Genau darauf habe ich geantwortet.

Wer lesen kann, ist klar im Vorteil. Die beiden, die mein Posting herabgewertet haben, können es offensichtlich nicht.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Raketengrundradar]

Wer lesen kann, ist klar im Vorteil. Die beiden, die mein Posting herabgewertet haben, können es offensichtlich nicht.

Wie auch immer, was die möglichen Gründe für die eine negative Bewertung Deines Beitrages sein sollen liegt auch für mich völlig im Dunkeln. Vielleicht hast Du diese mit dem Wort „agnostisch“ überfordert?

Allerdings ist auch mir ein gewisser Mangel aufgefallen: So um die drei, Begeisterung auslösende „WTF!“ hätten das demonstrierte Missfallen sicherlich verringert wenn nicht zu starkem Gefallen verkehrt. Einfache Sprache ist hilfreich.

[TS]

Hello,

Tom wollte aber nicht checked in die Datenbank schreiben, sondern checked="checked". Genau darauf habe ich geantwortet.

Wer lesen kann, ist klar im Vorteil. Die beiden, die mein Posting herabgewertet haben, können es offensichtlich nicht.

Dito:

{1} mir persönlich würde ja checked auch genügen, aber da war doch mal was?  
Das kann @Gunnar Bittersmann vielleicht besantworten.  

Die von Dir geforderte Agnostizität bezüglich des Datenmodells erscheint mir zwar theoretisch richtig zu sein, hat aber eben in der Praxis mit der gewählten Normalisierungsstufe zu tun. Warum sollte man eine weitere Tabellenebene für die Neutral->HTML-Parameter-Übersetzung einführen ins Datenmodell, wenn man doch seit zwanzig Jahren weiß, dass die Koppelung MySQL-PHP-HTML Bestand hat und bestenfalls durch CSS ergänzt wird?

Da wäre mMn eher eine Neutral->Sprache->HTML-Übersetzung wichtiger.

Also ja, eigentlich hast Du Recht, aber in der Praxis hält es von den wesentlichen Entwicklungsentscheidungen ab und macht unnütz das System lahm.

Deshalb auch einen Minuspunkt. Du hättest auch die andere Seite erwähnen müssen, um einen Pluspunkt dafür zu bekommen.

Es war also nicht der fremdsprachliche Begriff, sondern die unreflektierte Insbildsetzung als die Wahrheit™, die mich gestört hat. :-)

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Tom wollte aber nicht checked in die Datenbank schreiben, sondern checked="checked". Genau darauf habe ich geantwortet.

mir persönlich würde ja checked auch genügen, aber da war doch mal was?

Verdrehe jetzt bitte nicht die Tatsachen. Du wolltest HTML-Code in die Datenbank schreiben, keinen ENUM-Wert.

wenn man doch seit zwanzig Jahren weiß, dass die Koppelung MySQL-PHP-HTML Bestand hat und bestenfalls durch CSS ergänzt wird?

dashamwaschonimmahsogmacht driven development^[1] funktioniert seit 20 Jahren. Nicht.

Also ja, eigentlich hast Du Recht, aber in der Praxis hält es von den wesentlichen Entwicklungsentscheidungen ab und macht unnütz das System lahm.

Unsinn.

Es hat einen Grund, warum es „Datenbank“ heißt und nicht „HTML-Code-Bank“. Versuche, ihn zu verstehen!

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

---

1. Credits: @webrocker ↩︎

[TS]

Hello,

Tom wollte aber nicht checked in die Datenbank schreiben, sondern checked="checked". Genau darauf habe ich geantwortet.

mir persönlich würde ja checked auch genügen, aber da war doch mal was?

Verdrehe jetzt bitte nicht die Tatsachen. Du wolltest HTML-Code in die Datenbank schreiben, keinen ENUM-Wert.

Ich wollte den Attributwert (also Daten) direkt ohne weitere Normalisierung in die DB schreiben und habe ersatzweise das ganze Attribut benannt, falls dies notwendig würde. Ob dies nun HTML-Code im Sinne von Beschreibungssprache, oder nur ein Datenwert in HTML-Notation wäre, darüber würde ich gerne noch diskutieren. Checked alleine würde ich jedenfalls nicht als der Beschreibungssprache zugehörig, sondern als Attributwert bezeichnen. Und das ist eindeutig ein Datum.

wenn man doch seit zwanzig Jahren weiß, dass die Koppelung MySQL-PHP-HTML Bestand hat und bestenfalls durch CSS ergänzt wird?

dashamwaschonimmahsogmacht driven development[^1] funktioniert seit 20 Jahren. Nicht.

Amdere würden dies als "best Practice" bezeichnen, ich nur als "Augenmaß bewahren". Wenn man sich durch einen solchen Kompromiss eine Menge Overhead ersparen kann, halte ich das für wirtschaftlich richtig und fachlich vertretbar, da nachvollziehbar und ggf. zu gegebener Zeit noch reparierbar.

Glück Auf
Tom vom Berg

[Matthias Apsel]

Hallo TS,

Checked alleine würde ich jedenfalls nicht als der Beschreibungssprache zugehörig, sondern als Attributwert bezeichnen. Und das ist eindeutig ein Datum.

Und wenn es keine Attribute gibt?

Bis demnächst
Matthias

[TS]

Hello,

Hallo TS,

Checked alleine würde ich jedenfalls nicht als der Beschreibungssprache zugehörig, sondern als Attributwert bezeichnen. Und das ist eindeutig ein Datum.

Und wenn es keine Attribute gibt?

Verstehe ich jetzt nicht adhoc.

Wenn Du aber meinst, wenn dort kein checked stehen sollte, dann bleibt der Wert in der DB eben auch auf dem neutralem Element, bzw. Defaultwert "" stehen. Wo ist da also das Problem?

Wie würdest Du denn z. B. die Farbe oder das Bild des Hintergrundes in der Userkonfiguration der Webseite in der DB speichern?

Glück Auf
Tom vom Berg

[Auge]

Hallo

Checked alleine würde ich jedenfalls nicht als der Beschreibungssprache zugehörig, sondern als Attributwert bezeichnen. Und das ist eindeutig ein Datum.

Und wenn es keine Attribute gibt?

Verstehe ich jetzt nicht adhoc.

Wenn Du aber meinst, wenn dort kein checked stehen sollte, dann bleibt der Wert in der DB eben auch auf dem neutralem Element, bzw. Defaultwert "" stehen. Wo ist da also das Problem?

Das Problem ist, dass der gespeicherte Status, in deinem Fall „checked“, in anderen Kontexten gebraucht werden wird und „checked“ in anderen Fällen als einer HTML-Ausgabe mit an Sicherheit grenzender Wahrscheinlichkeit zu nichts zu gebrauchen sein wird.

Der von dir gepriesene Vorteil der Speicherung von „checked“ statt (wahrscheinlich) true oder 1 löst sich abseits von HTML in Nullkommanichts in Nichts auf. Der für die Generierung einer HTML-Ausgabe eingesparte Arbeitsschritt der Umwandlung eines normalisierten Werts zu „checked“ fällt dann für alle anderen Kontexte an.

Ich halte es keinesfalls für vorteilhaft, einen Vorteil für einen Fall mit Nachteilen für alle anderen Fälle zu erkaufen.

Wie würdest Du denn z. B. die Farbe oder das Bild des Hintergrundes in der Userkonfiguration der Webseite in der DB speichern?

Natürlich werden Farben mit Namen oder eindeutigen IDs gespeichert. Hier ging es aber nicht um Namen sonderm um mehr oder minder boolesche Werte.

Tschö, Auge

[Raketentheoretiker]

Checked alleine würde ich jedenfalls nicht als der Beschreibungssprache zugehörig, sondern als Attributwert bezeichnen. Und das ist eindeutig ein Datum.

Und wenn es keine Attribute gibt?

Natürlich ist es Unsinn, etwas wie den String checked="checked" in eine Datenbank, womöglich sogar noch in ein Feld namens is_checked einzutragen. Ich denke, darüber braucht man nicht streiten. Hier genügt true oder false, bei rudimentären Datenbanken (oder Datenspeichern) die den binären Datentyp nicht unterstützen, meinetwegen 1 oder 0. Jede Erweitung auf andere mögliche Werte verursacht „Kosten“.

Allerdings hat hier das w3c schon Mist gebaut. Etwas wie checked="STRING" hätte niemals genormt werden dürfen, wenn man es gleichzeitig (und insoweit sinnvoll) als boolean definiert.

Kommen wir zu der aufgekommenen Frage, ob es wohl sinnvoll sei, HTML in Datenbanken einzutragen.

Hier kann man durchaus streiten, es kommt aber auf den Anwendungsfall an. Geht es - wie im Falle der Checkbox - um eine Erfassung eingegebener Daten, dann verbietet sich das selbstverständlich - und ich habe durchaus sehr große Schwierigkeiten damit, zu begreifen, wie man auf eine andere Idee kommen könnte. Ganz anders sieht es aus, wenn man aus Performancegründen (fast) ganze Webseiten wegspeichert, was ja so manches (von verschiedenen auch verschieden bewerteten) CMS, Blog- oder Redaktionssystem macht. Hier würde ich einfach darauf abstellen, dass diese im Hinblick auf das „meistverfügbare“ eben kurzerhand eine SQL-Datenbank benutzen (man kann das auch mit strengem Blick „missbrauchen“ nennen), weil (womöglich, es geht ja um fremde Server) nichts anderes (hier ein simpler Key-Value-Speicher) da ist. Freilich könnte man auch einfach das Dateisystem hernehmen, da schmerzt aber manche (im Hinblick auf die Blockgröße) die ineffektive Ausnutzung des Speicherplatzes oder diese haben Probleme mit Rechten zu lösen (Deren Logik bei den üblichen Nutzungen einer SQL-Datenbank mit dem selben Zugangsdatenpaar für Reaktion, Abruf, Moderation, … aber auch extern geschaffen werden muss). Auch darf man nicht vergessen, dass die SQL-Datenbank womöglich „sowieso“ benutzt wird und man also aus nachvollziehbaren Gründen („Vereinfachung von Backup und Wiederherstellung“ könnte man nennen) eine Fraktionierung (Hier: Verteilung) der Datenhaltung vermeiden will. In solchen Fällen kann es sinnvoll sein, direkt HTML (und damit die Vorbelegung von Formularen, siehe checked) in einer Datenbank abzulegen. Das mag ein Bruch mit der „reinen Wissenschaft“ sein, erscheint aus Performancegründen, wegen der einfacheren Handhabung und der fixierten Vorbestimmung (Redaktionssystem für Webseiten, CMS, Blog) aber als „tragbar“. Sonst müsste man die Webseiten (oder deren Teile) aus Datenschnipseln zusammenbauen, was einige „Kosten“ verursachen kann.

[Gunnar Bittersmann]

@@Raketentheoretiker

Allerdings hat hier das w3c schon Mist gebaut. Etwas wie checked="STRING" hätte niemals genormt werden dürfen, wenn man es gleichzeitig (und insoweit sinnvoll) als boolean definiert.

Nein. SGML stammt nicht vom W3C. Und als Sir Tim auf dessen Grundlage HTML entwickelte, war an das W3C auch noch nicht zu denken.

Wie ich schon sagte, sind in HTML (wie auch in XML) sämtliche Attributwerte vom Typ String. Auch wenn einige von ihnen als boolesche Werte oder Zahlen interpretiert werden.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Rolf B]

Hallo Gunnar,

ich denke, dass Jörg lieber sowas wie checked="true" und checked="false" gesehen hätte, was aber dann im XHTML eine andere Semantik für den Sachverhalt "Das Attribut existiert" hervorgerufen hätte.

Insofern denke ich, dass man bei XHTML gar keine andere Wahl hatte, als bei der HTML Logik zu bleiben: Attribut ist da: Checked. Attribut fehlt: Unchecked. Hat der Wert "checked" in XHTML eine Bedeutung? Oder ist das ein Dummytext, der nur der XML-Syntax geschuldet ist? Ich meine, das wäre so.

Rolf

[TS]

Hello,

ich denke, dass Jörg lieber sowas wie checked="true" und checked="false" gesehen hätte, was aber dann im XHTML eine andere Semantik für den Sachverhalt "Das Attribut existiert" hervorgerufen hätte.

Insofern denke ich, dass man bei XHTML gar keine andere Wahl hatte, als bei der HTML Logik zu bleiben: Attribut ist da: Checked. Attribut fehlt: Unchecked. Hat der Wert "checked" in XHTML eine Bedeutung? Oder ist das ein Dummytext, der nur der XML-Syntax geschuldet ist? Ich meine, das wäre so.

Ich meine beobachtet zu haben, dass jeder (?) Attributwert in HTML eineindeutig ist, also keiner auf ein anderes Attribut, als sein eigenes passen würde. Es gäbe somit keine syntaktische Polymorpie.

Ist das jetzt ein Designfehler, oder aber im Nutzen der Interpretierbarkeit eine Redundanz in der Semantik?

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Ich meine beobachtet zu haben, dass jeder (?) Attributwert in HTML eineindeutig ist, also keiner auf ein anderes Attribut, als sein eigenes passen würde.

Schlecht beobachtet.

<img src="…" alt="…" width="42" height="42"/>

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Raketentheoretiker]

ich denke, dass Jörg lieber sowas wie checked="true" und checked="false" gesehen hätte,

Genau so. Denn es ist völlig unlogisch, dass

		<input type="checkbox" checked=false> (false)<br>
		<input type="checkbox" checked=0> (0)<br>

im Browser so interpretiert wird:

… während es in JS dann mit [0,1], [true,false], ["y", "n"] so funktioniert:

function setChecked( id, checked ) {
    if ( "n" == checked[0] ) {
       checked = false;
    }
    document.getElementById( id ).checked = Boolean( checked );
}

[Raketeningrid]

Es ist Mist, wenn sich halb Deutschland dazu verabredet, mich um 11:05 anzurufen...

ich denke, dass Jörg lieber sowas wie checked="true" und checked="false" gesehen hätte,

Genau so. Denn es ist völlig unlogisch, dass

		<input type="checkbox" checked=false> (false)<br>
		<input type="checkbox" checked=0> (0)<br>
    <input type="checkbox" checked=""> (0)<br>

im Browser so interpretiert wird:

… während es in JS dann mit [1,0], [true,false], ["y", "n" | "" ] dann doch wie „naturgemäß erwartet“ funktioniert:

function setChecked( id, checked ) {
    if ( "n" == checked.toLowerCase().charAt( 0 ) ) {
       checked = false;
    }
    document.getElementById( id ).checked = Boolean( checked );
}

[Gunnar Bittersmann]

@@Raketeningrid

Es ist Mist, wenn sich halb Deutschland dazu verabredet, mich um 11:05 anzurufen...

😊

Protip: Als registrierter Nutzer kannst du deine Postings nachträglich korrigieren. Aber wem sag ich das?

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Christian Kruse]

Hallo Gunnar,

Protip: Als registrierter Nutzer kannst du deine Postings nachträglich korrigieren.

Als anonymer User auch. Wenn man das hier anhakt:

Freundliche Grüße,
Christian Kruse

[RaketenQuadratIngrid]

Nur, falls das jemand mal einsetzt …

function setChecked( id, checked ) {
    if (
          'string' === typeof( checked )
       && 'n'      === checked.toLowerCase().charAt( 0 )
    ) {
       checked = false;
    }
    document.getElementById( id ).checked = Boolean( checked );
}

Sonst schmeisst das mit setChecked( 'foo', true ) oder setChecked( 'foo', 1 ) natürlich Fehler.

[Rolf B]

Hallo Raketenjörg,

ich verstehe dein Unbehagen, aber was machst Du mit schlecht geschriebenem JS, gerade in Libraries, das das checked-Attribut und nicht das checked-Property abfragt. Denn es ist ja ein Irrtum, zu meinen, dass das das gleiche sei.

Das Irre ist, dass das checked-Property dem checked-Attribut so lange folgt, wie man das checked-Property nicht schreibt, sondern nur liest. Nach dem ersten Schreibzugriff auf das Property folgt es dem Attribut nicht mehr, sondern hat den geschriebenen Wert, egal was man mit dem Attribut danach noch anstellt. Dafür sorgt wohl das Duo Infernale aus getter und setter, das auf dem Prototypen von HTMLInputElement sitzt.

Legacy, ick hör Dir poltern.

Rolf

[TS]

Hello,

[•••]

es stimmt schon traurig, wenn man mal in die Tiefe der Elaborate der Superentwickler schaut. Ganz so, als würde man eine Koloskopie vor der Ernüchterung betreiben :-(

Glück Auf
Tom vom Berg

[Raketentheoretiker]

Elaborate der Superentwickler

Naja. Wie man beschreibungssprachen und Programmiersprachen plant musste die Menschheit auch erst lernen - und wir machen sowas erst rund 70 Jahre.

Aber HTML5 z.B. hätte man schon säubern können...

[Gunnar Bittersmann]

@@Rolf B

Insofern denke ich, dass man bei XHTML gar keine andere Wahl hatte, als bei der HTML Logik zu bleiben

Ja. Jedes XHTML-1-Dokument sollte auch von einem HTML-Parser verarbeitet werden können.

Hat der Wert "checked" in XHTML eine Bedeutung?

Es ist der einzige erlaubte.

Oder ist das ein Dummytext, der nur der XML-Syntax geschuldet ist? Ich meine, das wäre so.

Ein HTML-Parser hakt die Checkbox auch bei ungültigem Wert checked="invalid" an.

Keine Ahnung, was ein XHMTL-Parser tut. Ich hab anscheinend keinen mehr. Haben alle Browser den inzwischen rausgeschmissen? Unterstützt niemand mehr application/xhtml+xml?

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Julius]

Hallo Raketentheoretiker,

Ganz anders sieht es aus, wenn man aus Performancegründen (fast) ganze Webseiten wegspeichert, was ja so manches (von verschiedenen auch verschieden bewerteten) CMS, Blog- oder Redaktionssystem macht. Hier würde ich einfach darauf abstellen, dass diese im Hinblick auf das „meistverfügbare“ eben kurzerhand eine SQL-Datenbank benutzen (man kann das auch mit strengem Blick „missbrauchen“ nennen), weil (womöglich, es geht ja um fremde Server) nichts anderes (hier ein simpler Key-Value-Speicher) da ist.

Siehe auch hierzu: SQLite: 35% Faster Than The Filesystem
Natürlich beziehen sich die 35% auf einen konkreten Anwendungsfall, das ist nicht allgemeingültig. Aber das Beispiel zeigt, dass man sich jeweils für den konkreten Anwendungsfall überlegen muss, was sinnvoll ist.

Gruß
Julius

[Gunnar Bittersmann]

@@Gunnar Bittersmann

checked würde in HTML-Syntax genügen; in XHTML-Syntax muss jedes Attribut einen Wert zugewiesen bekommen.

s.a. Erklärung im anderen Thread

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[dedlfix]

Tach!

Es ist allgemeiner Konsens (nicht Gesetz) bei Datenbanken, dass NULL in Feldern bedeutet, dass dieses Feld noch keine Bearbeitung erfahren hat, der Benutzer noch keine Entscheidung getroffen hat.

Man kann NULL auch als "keine Daten vorhanden" interpretieren. Dass das etwas anderes als "im fachlichen Sinne nicht gesetzt" ist, merkt man spätestens dann, wenn man nach diesem Wert abfragen muss. Da alle Operationen mit NULL als einem der Operanden zum Ergebnis NULL führen, muss man immer eine Extrawurst braten, wenn man NULL-Werte berücksichtigen möchte, z.B. den Operator IS NULL bemühen.

NULL = NULL → NULL → false
NULL = 42 → NULL → false

dedlfix.

[MudGuard]

Hi,

Man kann NULL auch als "keine Daten vorhanden" interpretieren. Dass das etwas anderes als "im fachlichen Sinne nicht gesetzt" ist, merkt man spätestens dann, wenn man nach diesem Wert abfragen muss. Da alle Operationen mit NULL als einem der Operanden zum Ergebnis NULL führen, muss man immer eine Extrawurst braten, wenn man NULL-Werte berücksichtigen möchte, z.B. den Operator IS NULL bemühen.

Insbesondere werden bei Abfragen wie
select * from tabelle where spalte != 42
oder
select * from tabelle where spalte not in (17, 23, 42)
die Zeilen, die in spalte ein NULL stehen haben, NICHT ausgegeben - obwohl NULL ja durchaus was anderes als 42 ist bzw. nicht in der Menge {17, 23, 42} enthalten ist.

cu,
Andreas a/k/a MudGuard

[Camping_RIDER]

Aloha ;)

Wenn ich in der DB immer eine 0 oder eine 1 stehen habe, dann gefällt mir das nicht. Lieber wäre mir null oder 1. Oder es steht eben kein Eintrag da, oder doch.

Sehe ich nicht generell so. Man beachte, dass ein großer semantischer Unterschied zwischen null (kein Wert, so viel wie "keine Aussage über diese Eigenschaft") und dem Wert 0 (nada, niente, nichts, neutrales Element der Addition in üblichen Zahlenräumen) besteht.

Wenn es ganz allgemein gesprochen um eine Eigenschaft geht, die entweder 0 oder 1 ist, dann sollte auch in der Datenbank dort entweder 0 oder 1 stehen, während der mögliche Ẁert null für Spezialfälle (kaputt, noch kein Wert, keine Entscheidung getroffen) stehen und je nach Anwendungsfall 0-wertig oder 1-wertig gewertet werden kann.

Siehe auch den entsprechenden Wikipedia-Artikel zur Semantik von SQL-Null...

Grüße,

RIDER

[Rolf B]

Hallo Tom,

Expertenstreit vor einem Neuling ist nie gut, aber ein paar Anmerkungen habe ich doch.

• verändere nichts, was Du vorher nicht gelesen hast
• arbeite mit Sessions. Datensätze, deren alter Inhalt sich nicht im Sessionpuffer befindet, dürfen nicht verändert werden

Da beschreibst Du Details für ein Grundproblem. Es ist aber nicht zwingend, das Grundproblem mittels dieser Details zu bearbeiten. Es sind auch keine Probleme von PHP oder SQL, sondern Grundprobleme der Web-Entwicklung.

Grundproblem 1 lautet: Ein Web ist keine Einzelbenutzer-Anwendung. Dinge, die bei einem Desktop-Programm mit lokalen Daten problemlos sind, sind im Web-Umfeld tödlich. Bei den beiden von Dir genannten Punkten geht es darum, dass zwei (oder mehr) Anwender den gleichen Datensatz lesen und dann updaten wollen. Wenn der erste Anwender schreibt, ist das noch ok. Aber der zweite Anwender überschreibt die Änderungen des ersten, weil er gar nicht weiß, dass es sie gegeben hat.

Grundproblem 2 lautet: Das pessimistische Sperren von Datensätzen ist in der Multiuser-Welt verpönt (sprich: man setzt ein "In Bearbeitung" Kennzeichen in dem Satz, den man gelesen hat). Solche Kennzeichen neigen dazu, vergessen zu werden. Es reicht schon, wenn der Anwender einfach den Browser schließt.

Deswegen reicht der Hinweis "Verändere nichts, was Du vorher nicht gelesen hast" nicht aus. Tabellen, die man updaten will, brauchen eine Versionsmarke, die sich pro Update verändert. Das kann entweder ein Zähler oder eine Timestamp-Column sein. Die Versionsmarke dient dazu, ein so genanntes "optimistisches Sperren" umzusetzen. Man liest die Daten und präsentiert sie dem User. Die Versionsmarke speichert man in der Session. Manche Programmierer verwenden auch einen Viewstate, d.h. verborgene Eingabefelder im HTML Formular, aber der muss verschlüsselt und signiert sein, damit ihn Anwender nicht fälschen können. Sessions sind normalerweise einfacher.

Der Anwender will vielleicht gar nichts ändern. Aber wenn doch, dann macht man das

• in einer Transaktion, wenn mehr als eine Table zu updaten ist (d.h. InnoDB, nicht MyISAM)
• beim Update wird in der WHERE Bedingung sichergestellt, dass ein Satz nur geupdated wird, wenn er dem letzten gelesenen Stand entspricht, d.h. die Satzversion der gemerkten Satzversion entspricht.
• Und natürlich wird die Versionsmarke geändert (plus 1 oder aktuellen Timestamp einsetzen).

Geht das schief, kam es zu einer Updatekollision. Wie man damit umgeht, ist eine Wissenschaft für sich. Im einfachsten Fall schreibt man eine Fehlermeldung und bittet den Anwender, seine Änderungen zu wiederholen. Im komplexen Fall versucht man, die Änderungen beider Anwender zu vereinigen, aber das ist nicht trivial und auch nicht immer möglich.

• beschaffe dir aus der Datenbank (Metadaten der Tabelle) die Spaltentypen

Hm. Zur Laufzeit? Warum? Man programmiert doch normalerweise gegen eine bekannte Datenbank. Es gibt zwei Typen von Anwendungen, die sich dynamisch an das DB Schema anpassen können müssen: phpMyAdmin (und ähnliche), und ORM-Libraries. Wenn man sein SQL von Hand erstellt, weiß man normalerweise, welche Spaltentypen vorliegen.

Der wichtigere Rat wäre: Streue das SQL nicht kreuz und quer durch die Anwendung. Versuche, mit möglichst wenigen Statements auszukommen (auch wenn sie ein paar Spalten "zuviel" lesen) und fasse alle SQLs in einem Funktionsmodul zusammen. Gerne auch objektorientiert, wenn man das beherrscht. Für jeden DB-Zugriff eine eigene Funktion. Die kann man dann in den Parametern mit Type Declarations versehen. Ein "DB-Zugriff" kann ein SQL Statement sein, aber ggf. auch mehr, je nach Umständen. Ändert sich dann etwas an der DB, hat man alle SQLs, die man anfassen muss, beisammen.

• prüfe bei der Antwort vom Client die Darstellbarkeit der Requestparameter im Zieltyp der Datenbanktabelle.
• beachte den Kontextwechsel und das passende Escaping

Bzw. konvertiere die Daten geeignet. Vom Client kommen ja immer nur Strings, und dem Client kann man nicht vertrauen. Man muss jedem Request unterstellen, dass ein Hacker ihn schickt, der einem die Website zerschießen will. Zum Kontextwechsel gibt es hier Lektüre.

• speichere dir in der Session alle Felder des Formulars, die bei der nachfolgenden Antwort (dem Update Request) des Clients vorhanden sein müssen und dürfen.

Das ist ähnlich wie beim Lesen der Metadaten: Wozu? Normalerweise weißt Du, welche Daten ein Form erwartet. Solche Informationen musst Du nur speichern wenn die Forms dynamisch sind und auf Grund von DB-Inhalten flexibel zusammengestellt werden. Überzählige POST Parameter ignoriert man eigentlich dadurch, dass man gar nicht danach schaut. Es gibt zwar auch Anwendungen, die über die $_POST Parameter iterieren und sie alle irgendwo hin schreiben, aber DAS ist wirklich ein Einfallstor für Hacker und nicht unbedacht zu tun.

Relevant ist: Checkboxen landen nur im $_POST bzw. $_GET Array, wenn sie angehakt wurden. Sonst nicht. Wenn Du also eine Checkbox auf dem Form hast

<label>
  <input type="checkbox" name="acceptAGB" value="1"/>
  Ich habe die AGB verstanden
</label>

dann musst Du mit isset($_POST['acceptAGB']) prüfen, ob der Wert überhaupt übergeben wurde. Es kann aber auch nützlich sein, für solche Zwecke eine Helferfunktion zu schreiben statt immer isset(...) zu programmieren. Und wie schön, das gibt's schon fertig:

$agb = filter_input(INPUT_POST, 'acceptAGB', FILTER_VALIDATE_BOOLEAN);

filter_input hat diverse Validatoren und Sanitizer und kann Dir einiges an Arbeit abnehmen.

Rolf

[Mitleser]

Hi there,

kommt mir so vor, als würde da jemand die Postings vom Tom der letzten fünfzehn Jahre zum Thema gelesen haben ;-)

mfg ein Mitleser

[Felix Riesterer]

Lieber PHP-Neuling,

wir haben da in unserem Wiki ein Tutorial für Deine Fragen: PHP/Tutorials/Formulare

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

danke ich sehe es nochmal durch

[Robert B.]

Hallo,

für dich auch interessant ist dann das Kapitel über Kontextwechsel, sprich was du tun musst, wenn du Werte aus einem Kontext in einen anderen bringst; hier

while ($Datensatz = $DATA->fetch_object()) {
  ?>
  <td>IrgendEinWert</td>
  <td><input type="text" name="IrgendEinWert" value="<?php echo $Datensatz->IrgendEinWert; ?>"></td>
  <?php
}

ist es aus dem SQL-Kontext ($DATA->fetch_object()) in den HTML-Kontext.

Viele Grüße
Robert

[Raketenhacknix]

Dein Problem ist unerhört trivial und Du kannst es lösen, wenn Du Dir nach dem Ausfüllen des Formulars $_GET und $_POST, und im Fall von Checkboxen die PHP-Funktion isset() einfach mal anschaust.

etwas wie:

if( isset($_POST['checkBoxName'] ) {

dürfte zielführend sein.

Ich habe aber noch was nicht ganz so triviales, und, weil es die Sicherheit betrifft, auch sehr wichtiges:

value="<?php echo $Datensatz->IrgendEinWert; ?>">

Wenn $Datensatz->IrgendEinWert etwas wie

"></input><script>alert("Diese Webseite wurde gehackt!");</script><input value="

enthalten könnte könnte man als Skriptkid „schöne“ Sachen machen. Das Ergebnis ist dann:

<input type="text" name="IrgendEinWert" value=""></input><script>alert("Diese Webseite wurde gehackt!");</script><input value="">

Das ist ein harmloses Beispiel. Bösartige oder auch nur an schnellem Geld interessierte Personen machen weitaus böseres. Um das zu verhindern solltest du htmlspecialchars() verwenden:

value="<?php echo htmlspecialchars( $Datensatz->IrgendEinWert ); ?>">

Ich hoffe, die von Dir zu Rate gezogene Literatur befasst sich auch mit den Sicherheitsmaßnahmen beim Eintrag in die Datenbank. Füge den Artikel zum Thema „Kontextwechsel“ aus dem Selfhtml-Wiki Deiner Leseliste unbedingt hinzu.

[Raktentypokorrekturautomat]

etwas wie:

if( isset($_POST['checkBoxName'] ) {

Das „etwas wie“ beinhaltet selbstverständlich auch vergessene Klammern:

if( isset( $_POST['checkBoxName'] ) ) {

[PHP-Neuling]

Danke Raketenede,

den Artikel auf das hingewiesene htmlspecialchars habe ich gelesen, verstanden, und setze dieses auch direkt um. Das ist ein Ansatz, an den man als Neuling (der erst einmal von grundlegender Funktion begeistert ist, und Sicherheit noch gar keine Rolle spielt) noch nicht direkt mit verfolgt.

Nun mache ich mich an den "trivialen" Teil (...)

[Raketenede]

Da Du nach Deinen Worten PHP-Neuling bist und damit angefangen hast, eine erste Seite (für die Firma) zu entwickeln würde ich Dir dringend raten, den Quelltext überprüfen zu lassen und lieber mehr als weniger fragen.

Die Thematik

Browser ⇆ Webserver ⇆ Datenbank

ist ziemlich komplex und man kann, gerade im Freudentaumel des „Boh! Sowas geht!“ sehr viel falsch machen – was gerade bei kommerziellen Seiten unerhörte und richtig teuer werdende Auswirkungen haben kann.

Das betrifft übrigens nicht nur PHP. Webseiten haben auch andere Kontexte: Datenschutz, Datensicherheit (dazu gehört auch Verfügbarkeit des Auftritts bzw, seiner Funktionen) UWG, Impressumspflicht, …

[PHP-Neuling]

Raketenede, Danke Dir (schöner nick ... )

Nun, ja die Seite ist für unsere Firma. Aber Gott sei Dank nur für interne Verwendung. Die Wahrscheinlichkeit des bösartigen Schabernacks ist also relativ gering, zudem hat auch nur ein begrenzter Satz an Menschen Zugriff auf dieses System, das ich erneuern möchte/muss/darf

Eine Seite im WWW hätte ich auch abgelehnt, und dafür eine ernsthafte Schulung vorangezogen. Da ich für interne Zwecke aber keinen Zeitdruck habe (und corona eh Zeiträume schafft...), versuche ich es hier eben über eigenbildung

Den Kontextwechsel habe ich tatsächlich verstanden. Ich werde dies jetzt immer mit einbeziehen.

[dedlfix]

Tach!

Nun, ja die Seite ist für unsere Firma. Aber Gott sei Dank nur für interne Verwendung. Die Wahrscheinlichkeit des bösartigen Schabernacks ist also relativ gering, zudem hat auch nur ein begrenzter Satz an Menschen Zugriff auf dieses System, das ich erneuern möchte/muss/darf

Betrachte die Sache nicht zu sehr durch die Sicherheitsbrille. Sicherheit vor böswilligen Eingaben ist eigentlich nur ein Nebenthema. Vielmehr kommt es darauf an, dass die Daten korrekt verarbeitet werden. Wenn das sichergestellt ist, ist Code-Injection kein Thema mehr.

Beispielsweise wirst du bei der Schulung der Kollegen zu erwähnen vergessen haben, dass in die Felder bestimmte Zeichen nicht eingegeben werden dürfen, weil sonst die Verarbeitung misslingt. Oder die Kollegen vergessen das wieder, weil sie den Punkt nicht als wichtig betrachten. Im einfachsten Fall erzeugt das nur einen Syntaxfehler. Jedenfalls gibt später mal jemand aus Versehen oder aufgrund einer fachlichen Notwendigkeit diese Zeichen ein, und dann geht dein System kaputt. Deshalb immer darauf achten, dass dort, wo Daten in Code eingefügt werden, diese entsprechend der Regeln des Codes/Kontextes zu bearbeiten sind (üblicherweise Maskieren der Sonderzeichen).

Den Kontextwechsel habe ich tatsächlich verstanden. Ich werde dies jetzt immer mit einbeziehen.

Ein weiteres Thema wäre auch noch die Zeichenkodierung. Nicht alle Systeme haben UTF-8 als Default eingestellt und/oder können damit korrekt umgehen. Teste immer auch mindestens Umlaute, und wenn möglich auch beispielsweise chinesische Zeichen und Unicode-Emojis. Man muss sich auch damit vertraut machen, damit man nicht früher oder später kaputte Daten aufgrund nicht beachteter Kodierungen zu korrigieren hat.

dedlfix.

[PHP-Neuling]

hi dedlfix, und auch Dir danke ich für dein Bemühen,

ich strenge am ende an, dass lediglich Daten eingegeben werden können, die auch verarbeitet werden sollen. Daher arbeite ich auch mit vielen selects sowie auch checkboxen, und so wenig wie möglich freitext. Die Textfelder werden dann in irgendeiner Form gegen fehleingaben gesichert.

UTF8 habe ich bereits über

$db->set_charset('utf8');

eingerichtet

Eure Community hier ist wirklich der Wahnsinn :) Tausend sinnvolle antworten innerhalb weniger Stunden. Danke :)

[MudGuard]

Hi,

Nun, ja die Seite ist für unsere Firma. Aber Gott sei Dank nur für interne Verwendung. Die Wahrscheinlichkeit des bösartigen Schabernacks ist also relativ gering,

Viele Angriffe auf IT-Systeme von Firmen erfolgen von innen.
Unzufriedene Mitarbeiter …

cu,
Andreas a/k/a MudGuard

[PHP-Neuling]

vielleicht darf ich so dreist sein, und kurzum was ganz anderes reinschmeissen.

Da das Auslesen der DB für die Checkboxen nun ebenfalls funktioniert, wollte ich mich an das Speichern Thema machen.

Ich möchte hierfür $_SESSION Variablen verwenden, was sicher sinnvoller ist als alles an die URL zu hauen bei Übergabe an das Speichern skript.

Nun soll ja die Funktion "SESSION" selbst erst aktiviert werden durch

session_start()

Nun erhalte ich leider direkt einen 500er

Fatal error: session_start(): Failed to initialize storage module: wincache

kann das in irgendeiner Art an mir liegen, oder eher am Server? (Speicherberechtigungen?)

Lt PHPInfo ist session aktiv

Screenshot: http://prntscr.com/s39naa

[Rolf B]

Hallo PHP-Neuling,

das liegt nicht am Session-Modul, sondern daran, dass das Session-Modul wincache als Storage-Handler verwendet und der erbricht sich über irgendwas:

Failed to initialize storage module: wincache

Weitere Meldungen gibt es nicht?

Du müsstest Dir also mal anschauen, was an den wincache-Einstellungen falsch sein könnte. Das ist kein Standardbauteil in PHP, sondern eine Erweiterung.

Habe gerade mal die sourceforge-seite von wincache aufgerufen; die sagen, dass sie bis PHP 7.2 unterstützen. Welche PHP Version hast Du am Start?

Alternativ stelle den save_handler auf files.

Rolf

[PHP-Neuling]

hi auf dem server läuft php 5.5.13 Ich selbst habe leider keine Hand über den Server, da dieser im unternehmenseigenen Rechenzentrum liegt. Eine Anfrage diesbzgl ist bereits raus

[Rolf B]

Hallo PHP-Neuling,

PHP 5.5 ist toter als ein Türnagel, das sollte man keinesfalls mehr einsetzen. Aber gerade in betrieblichen Rechenzentren klebt man gerne mal an der Legacy.

Wer ist denn bei euch der Produktverantwortliche für die PHP Installation? Der müsste Dir doch weiterhelfen können. Vorausgesetzt, du machst deinen Job wenn Du PHP programmierst und betreibst da kein innerbetriebliches Hobby 😉

Hast Du Einfluss auf die PHP.INI Datei? Da kannst Du den save_handler ändern.

Du könntest auch versuchen, vor dem Start der Session mit ini_set den save_handler auf files zu ändern. Allerdings setzt das dann voraus, dass der files Savehandler korrekt eingerichtet ist, und nicht jede Installation erlaubt ini_set.

ini_set("session.save_handler", "files");

Wenn alle Stricke reißen musst Du einen benutzerdefinierten Savehandler bauen, aber das ist nichts für Anfänger.

Rolf

[PHP-Neuling]

hi Rolf,

durch das Ändern auf "files" hab ich nun wenigstens den Salat gefunden Der Fehler wurde jetzt durch ein Warning ersetzt. "Permission Denied(13)"

Also werde ich wohl auf's Rechenzentrum warten müssen.

Danke für deine Hilfe :) 👍

Da aus dem Error nun ein Warning wurde, kann ich ja zumindest erst einmal weiter machen. Ich hatte das jetzt so gedacht

<?php
ini_set("display_errors", true);
ini_set("session.save_handler", "files");
session_start(); //Aktiviert die Verwendung von Session Variablen in PHP
// Nulle Session Variablen -->

$_SESSION["Variable1"] = Null ;

?>
<!-- Weise Session Variablen den Wert der Forms zu -->
<?php
$_SESSION["Variable1"] = $_POST["Variable1"];
?>

Ich möchte also eine Session Variable mit dem Namen "Variable1" welche den Wert aus dem inputfeld mit dem Namen "Variable1" erhalten sollen.

Wenn ich dann Lade erhalte ich eine Notice

Notice: Undefined index

Liegt das nun daran, dass noch nichts befüllt wurde und der Index somit noch leer ist? Oder habe ich einen Fehler ?

Grüße

EDIT→ Das hat sich schon erledigt :)

[Rolf B]

Hallo PHP-Neuling,

"Permission Denied(13)"

Das dürfte daran liegen dass PHP auf den Pfad, in dem die Session-Files zu speichern sind, keine Rechte hat.

Euer PHP ist nicht nur alt, sondern wurde scheinbar auch noch nie wirklich benutzt. Ich hoffe, dass Du im RZ einen kompetenten und hilfsbereiten Ansprechpartner findest, da scheint einiges an Arbeit zu warten.

// Nulle Session Variablen -->
$_SESSION["Variable1"] = Null ;

DAS ist nicht nötig, es ist sogar kontraproduktiv für den Fall, dass Du nichts anderes zu Speichern hast. Denn dadurch entsteht ein Array-Eintrag mit Wert Null, der natürlich im Session-File zu speichern ist. Einen alten Wert aus $_SESSION entfernen macht man mit unset ($_SESSION['Variable1']);

Eher würde ich bei Bedarf mit isset($_SESSION["Variable1"]) abfragen, ob der Eintrag vorhanden ist.

Beim $_POST Array musst Du daran denken, dass da nur was drin steht wenn das Formular auch gePOSTet wird. Das kannst Du mit $_SERVER['REQUEST_METHOD'] == 'POST' prüfen.

Rolf

[Felix Riesterer]

Lieber Rolf,

Beim $_POST Array musst Du daran denken, dass da nur was drin steht wenn das Formular auch gePOSTet wird. Das kannst Du mit $_SERVER['REQUEST_METHOD'] == 'POST' prüfen.

wenn Daten in eine DB geschrieben werden sollen, ist nur die POST-Methode sinnvoll. Wir erinnern uns: Wenn ein Request Daten auf dem Server verändern soll, muss er mit POST abgesetzt werden (siehe Wiki: Wann ist GET oder POST zu verwenden?). Sollte unser PHP-Neuling hier tatsächlich GET verwenden, wäre das ein handwerklicher Fehler, den man sofort verbessern müsste. Sein Code legt aber nahe, dass er prinzipiell die POST-Methode verwendet.

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo Felix,

Beim $_POST Array musst Du daran denken, dass da nur was drin steht wenn das Formular auch gePOSTet wird. Das kannst Du mit $_SERVER['REQUEST_METHOD'] == 'POST' prüfen.

wenn Daten in eine DB geschrieben werden sollen, ist nur die POST-Methode sinnvoll.

ja, aber ich vermute, es geht hier um das Abrufen des (unausgefüllten) Formulars, nicht das Abschicken. Das erfolgt üblicherweise mit GET, also ist das $_POST-Array da noch leer.

Das ist natürlich eine zusätzliche Hürde für Einsteiger, wenn dieselbe PHP-Datei für das Formular selbst und die Verarbeitung der eingegebenen Daten zuständig sein soll.

Live long and pros healthy,
 Martin

[dedlfix]

Tach!

Das ist natürlich eine zusätzliche Hürde für Einsteiger, wenn dieselbe PHP-Datei für das Formular selbst und die Verarbeitung der eingegebenen Daten zuständig sein soll.

Andererseits ist die Alternative wesentlich unhandlicher. Wenn das leere Formular in einer Datei ist und die Auswertung in einer zweiten, dann hat man die Rechnung ohne die Eingabefehler gemacht. Bei einem solchen fängt man dann an, einen Programmablauf einzubauen, um von der Auswertung zurück zur Eingabe zu springen. Inklusive Mitnehmen der bereits eingetragenen Daten, damit der Anwender nicht von vorn beginnen muss. Deshalb ist die Affenformulartechnik besser geeignet. Man behandelt Formular und Auswertung in derselben Datei, so dass man das Formular bei Fehlern direkt mit den bisherigen Eingabedaten neu erstellen kann. Erst wenn alles ok ist, springt man zum nächsten Punkt - OK-Meldung oder was auch immer angemessen ist.

dedlfix.

[PHP-Neuling]

hi rolf, ja richtig, dass PHP wurde für mich extra aktiviert. Da war noch nie jemand dran

okay so habe ich das noch nicht gesehen. Halte es aber für sinnvoll die Variablen zu leeren bevor irgendwas gespeichert wird, um immer mit einem frischen System zu speichern. man weiß ja nie was die user machen. Dann entNULLe ich das System und arbeite mit UNSET. Danke :)

Puh. Den Post müsste ich dann mit

<?php
if ($_SERVER['REQUEST_METHOD'] == 'POST' ) { 
$_SESSION["Variable1"] = $_POST["Variable1"];
$_SESSION["Variable2"] = $_POST["Variable2"];
....
}
?>

einleiten, sodass die Variablen auch beim "submit" übernommen werden ?

[Felix Riesterer]

Lieber PHP-Neuling,

Puh. Den Post müsste ich dann mit

<?php
if ($_SERVER['REQUEST_METHOD'] == 'POST' ) { 
$_SESSION["Variable1"] = $_POST["Variable1"];
$_SESSION["Variable2"] = $_POST["Variable2"];
....
}
?>

einleiten, sodass die Variablen auch beim "submit" übernommen werden ?

nein!

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

ui irgendwie hänge ich wohl falsch fest

ich habe ja auch gar kein array(). die Variablen sind normale Variablen (f.e. Variable1) und keine Arrays Ich will lediglich beim click auf Submit den Inhalt (if any) der input felder in die SESSION Variable speichern

Ich glaub ich fang nochmal von vorne an ... 🤦

[Felix Riesterer]

Lieber PHP-Neuling,

auch wenn Du meinst, Dein Problem hätte sich erledigt, hier noch ein Hinweis zu Deinem Code.

<?php
ini_set("display_errors", true);
ini_set("session.save_handler", "files");
session_start(); //Aktiviert die Verwendung von Session Variablen in PHP
// Nulle Session Variablen -->

$_SESSION["Variable1"] = Null ;

?>
<!-- Weise Session Variablen den Wert der Forms zu -->
<?php
$_SESSION["Variable1"] = $_POST["Variable1"];
?>

Man sieht, dass Du grundsätzlich davon ausgehst, dass in den _POST-Daten ein Index Variable1 existiert, ohne das vorher zu prüfen. In dem von mir verlinkten Wiki-Artikel wird gezeigt, wie man das sinnvoller löst, indem man die Datenstruktur, die man gerne hätte, vorher erstellt, um sie dann Stück für Stück mit der vom Browser versandten abzugleichen. Hier einmal anders herum:

$_SESSION['wunsch'] = array(
  'var1' => 0,
  'var2' => '',
  'var3' => false
);

// alle gePOSTeten Daten abklappern
foreach ($_POST as $key => $value) {

  // nur erwartete Daten verarbeiten
  if (array_key_exists($key, $_SESSION['wunsch'])) {
    $_SESSION['wunsch'][$key] = $value;
  }
}

So vermeidest Du Fehler wie undefined index.

In der weiteren Verarbeitung kannst Du dann beliebige Kriterien an den so in der Session festgehaltenen Datenbestand stellen, um zu entscheiden, ob das so in die DB darf, oder ob der User hier inhaltlich nachbessern muss (Stichwort Affenformular).

Nebenbei hat es einen Sinn, mittels der Session auch gleich einen Login-Mechanismus zu implementieren, damit nicht einfach jeder an alles dran kommt.

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

okay ... ich versuche ja Fortschritte zu machen :)

Also, ich habe nach wie vor onTop die unset Regelungen für die Sessions -> Übrigens funktioniert die SESSION jetzt. Unsere zentrale hat mir das PHP eingerichtet

Ich habe eigentlich vor gehabt, eine speichern.php zu haben um die Daten des Formulars dann dort abzuspeichern. Früher (damals noch HTML und etwas VB) hatte ich das stets so gehandhabt, weiss aber gar nicht mehr warum eigentlich

Nun aber habe ich es so gelöst

Der SUBMIT hat ein hidden field bei mit dem namen "aktion"

`<input type="hidden" name="aktion" value="speichern">

<input id="savebutton" type="submit" value="Speichern" onclick="submit">`

im php wird dann geprüft, ob der button geklickt wurde, und erst dann werden auch die SESSION variablen zugewiesen

if (isset($_POST['aktion']) and $_POST['aktion']=='speichern') {

 $_SESSION["Variable1"] = $_POST["Variable1"];
.....

nach zuweisung wird direkt der UPDATE Befehl eingerollt

	$aktualisieren = $db->prepare ("UPDATE TABLE SET WERT1 = '$VARIABLE1' WHERE ID = $ID1");
		$aktualisieren->execute();

Komischerweise funktioniert das NICHT über WERT1 = $_SESSION Setze ich aber vorher die SESSION in eine "normale" Variable um ($VAR11 = $_SESSION...), und nutze dann im UPDATE statt der $_SESSION die $VAR11, dann funktionierts

Muss ich bei den SESSIONs noch irgendetwas beachten ? Es werden immer die korrekten Werte übertragen, also funktioniert ja die Zuweisung der INPUTS in die jeweilige SESSION

[PHP-Neuling]

... so langsam stelle ich aber auch die SESSION Idee in Frage, wenn sowieso alles über eine Seite läuft ... ?

[Felix Riesterer]

Lieber PHP-Neuling,

... so langsam stelle ich aber auch die SESSION Idee in Frage, wenn sowieso alles über eine Seite läuft ... ?

wegen des Logins. Aber der kann ja etwas warten.

Den Programmablauf für das Affenformular stelle ich mir so vor:

1. mögliche POST-Daten werden empfangen und ausgewertet
2. wenn alles passt, wird gespeichert
3. HTML-Dokument zusammensetzen (vorhandene DB-Daten anzeigen?)
   a) Wenn erfolgreich gespeichert wurde, passende Meldung ausgeben
   b) Wenn fehlerhafte oder unvollständige Angaben waren, passende Meldung ausgeben
4. Formular aus HTML-Datei einlesen
5. Wenn fehlerhafte oder unvollständige Angaben waren, diese in die Formularfelder voreintragen

Wobei genau brauchst Du Hilfe?

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

Hi Felix also laut deiner Auflistung bin ich noch bei Schritt 1

Ich habe es nun gerade geschafft, dass meine Input's auf Knopfdruck in die DB geschrieben werden Hierbei habe ich gleich mal eine flinke Frage ... bewirkt "htmlentities" das selbe wie "htmlspecialchars", nämlich das alles in HTML verständlichen Text umgewandelt wird ?

Mein nächster Schritt wird jetzt das korrekte einfügen der Checkboxen, worüber hier bereits viel diskutiert worden ist

Nervig ist, dass das bei knapp 70 Feldern immer wahnsinnig viel Schreibarbeit ist. Leider bin ich (noch) nicht gut genug, um mir da eine Funktion aus den Fingern zu leiern

Nach Dem Checkboxtheater möchte ich Abfragen einbauen um Fehleingaben zu vermeiden bzw. wichtige Felder nicht leer zu lassen.

Soweit ich das bereits verstanden habe, brauch es hierfür unter php kein javascript mehr

Grüße

[Felix Riesterer]

Lieber PHP-Neuling,

bewirkt "htmlentities" das selbe wie "htmlspecialchars", nämlich das alles in HTML verständlichen Text umgewandelt wird ?

nein. htmlentities geht viel weiter als htmlspecialchars, indem es gleich alles, was in ASCII nicht abgebildet werden kann, in HTML-Entitäten umwandelt. htmlspecialchars beschränkt sich auf die kritischen Zeichen <, >, & und je nach zweitem Parameter auch noch " und '.

Mein nächster Schritt wird jetzt das korrekte einfügen der Checkboxen, worüber hier bereits viel diskutiert worden ist

Viel Erfolg!

Nervig ist, dass das bei knapp 70 Feldern immer wahnsinnig viel Schreibarbeit ist. Leider bin ich (noch) nicht gut genug, um mir da eine Funktion aus den Fingern zu leiern

Schleife! Du willst eine Schleife. Irgendwoher nimmst Du die Info, welche Spalten es gibt (z.B. aus der DB selbst) und gehst sie der Reihe nach durch. Oder Du analysierst das HTML-Formular, das Du als Vorlage erstellt hast.

Nach Dem Checkboxtheater möchte ich Abfragen einbauen um Fehleingaben zu vermeiden bzw. wichtige Felder nicht leer zu lassen.

Gut so!

Soweit ich das bereits verstanden habe, brauch es hierfür unter php kein javascript mehr

JavaScript wird nicht auf dem Server ausgeführt, wenn Du als serverseitige Sprache PHP einsetzt. Aber im Browser kann JavaScript bereits prüfen, was der Server auch prüft, um dem Benutzer schon vor dem Versenden entsprechende Rückmeldungen zu geben, die ihm dann der Server auch geben würde.

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo,

bewirkt "htmlentities" das selbe wie "htmlspecialchars", nämlich das alles in HTML verständlichen Text umgewandelt wird ?

nein, htmlspecialchars() maskiert nur die Zeichen, bei denen das nötig ist, weil sie in HTML eine spezielle Bedeutung haben (<, &, "). Im Gegensatz dazu verstümmelt htmlentities() eine Menge mehr Zeichen als nötig.

Nach Dem Checkboxtheater möchte ich Abfragen einbauen um Fehleingaben zu vermeiden bzw. wichtige Felder nicht leer zu lassen.

Soweit ich das bereits verstanden habe, brauch es hierfür unter php kein javascript mehr

Das kommt drauf an. Du kannst die Plausibilitätsprüfung komplett in PHP, also serverseitig machen - dann bedeutet aber jeder "Versuch" einen kompletten Roundtrip zum Server und wieder zurück.
Mit Javascript könntest du dagegen die Prüfung vorab schon clientseitig machen, was etwas komfortabler sein kann und Zeit und Bandbreite spart. Da Javascript aber deaktiviert sein oder manipuliert werden könnte, musst du die endgültige Prüfung serverseitig in jedem Fall trotzdem machen.

Live long and pros healthy,
 Martin

[dedlfix]

Tach!

Ich habe es nun gerade geschafft, dass meine Input's auf Knopfdruck in die DB geschrieben werden Hierbei habe ich gleich mal eine flinke Frage ... bewirkt "htmlentities" das selbe wie "htmlspecialchars", nämlich das alles in HTML verständlichen Text umgewandelt wird ?

Zum Nein haben die beiden anderen schon etwas geschrieben. Aber warum stellst du diese Frage beim Thema "in die DB schreiben"? Denn falls du darüber nachdenkst, welches von beiden für die Werte in der DB verwendet werden soll: keines. Auch keine andere Behandlung. In die DB gehören (von Ausnahmen abgesehen) Rohdaten. Erst wenn die Daten in einen konkreten Ausgabekontext geschrieben werden, müssen sie entsprechend dieses Kontexts behandelt werden, und nicht in einem irgendwann stattgefunden habendem vorherigen Schritt. Du wirst sonst die Übersicht verlieren, welche Daten bereits für welche Kontext aufbereitet sind und welche noch nicht. Und es stört gewaltig, wenn derart aufbereitete Daten in einen ganz anderen Kontext mit anderen Regeln gebracht werden sollen.

Für das Schreiben in die Datenbank kommt es darauf an, ob du Prepared Statements korrekt verwendest. Fall ja, gehen die Daten und das SQL-Statement getrennte Wege, und die Daten brauchen keine Behandlung. Nur wenn sie in ein SQL-Statement eingefügt werden, brauchen sie eine, dann aber eine für SQL-Statements, und nicht für HTML oder andere Kontexte.

dedlfix.

[Felix Riesterer]

Lieber PHP-Neuling,

<td>IrgendEinWert</td><td><input type="text" name="IrgendEinWert" value="<?php echo $Datensatz->IrgendEinWert; ?>"></td>

das wollen wir doch in ein vernünftiges Markup übertragen:

<label>
  IrgendEinWert
  <input type="text" name="IrgendEinWert" value="{$IrgendEinWert}">
</label>

Das <label> kann dann noch entweder in einen Listenpunkt oder einen Textabsatz eingebunden werden.

Wie sieht Dein Formular überhaupt aus?

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

.. okay. Vielleicht hab ich ja hier wieder was verpasst ... :-D

meine Form ist eine Tabelle, in der die inputs alle in td's gepackt sind

Ist das ... in irgendeiner Art und Weise ungünstig? Sind Tabellen uncool geworden ?

Und, was hat das mit der geschweiften Klammer auf sich? {$IrgendEinWert} Kann ich damit das aufrufen der Variable abkürzen oder ist das jetzt nur zur Darstellung ?

Grüße

[Der Martin]

Hi,

meine Form ist eine Tabelle, in der die inputs alle in td's gepackt sind

ibäh ...

Ist das ... in irgendeiner Art und Weise ungünstig? Sind Tabellen uncool geworden ?

Sie waren noch nie cool. Jedenfalls nicht als Mittel zum Anordnen von Inhalten. Das war ein Notbehelf zu Zeiten, als CSS (bzw. die CSS-Unterstützung der Browser) noch in den Kinderschuhen steckte. Ist also seit ein bis zwei Jahrzehnten überholt.

Live long and pros healthy,
 Martin

PS: Du plenkst. Ist aber mit etwas Disziplin heilbar. ;-)

[PHP-Neuling]

oh. naja bin Ü30, daher passt das schon :D

Okay die Designfrage kann ich ja später nochmal meinem eigenen selber-Ich stellen. bin froh wenn ich erstmal verstanden habe wie der Motor zu laufen hat, bevor ich die Karosse lackiere

Danke :)

[Der Martin]

Hallo,

oh. naja bin Ü30, daher passt das schon :D

Alter ist keine Entschuldigung. Ich bin Ü50 - na und? :-)

Okay die Designfrage kann ich ja später nochmal meinem eigenen selber-Ich stellen.

Würde ich nicht empfehlen. Design beginnt schon beim Konzept, nicht erst beim Lackieren.

bin froh wenn ich erstmal verstanden habe wie der Motor zu laufen hat, bevor ich die Karosse lackiere

Du meinst, du weißt wie der Motor zu laufen hat, schön. Und du willst vor dem Lackieren noch das Fahrgestell austauschen?

Live long and pros healthy,
 Martin

[PHP-Neuling]

Du meinst, du weißt wie der Motor zu laufen hat, schön. Und du willst vor dem Lackieren noch das Fahrgestell austauschen?

Live long and pros healthy,
 Martin

Nein, ich weiß es eben noch nicht. Deswegen mach ich mir da jetzt erstmal keine Gedanken zur Optik, um erst einmal mit dem System klar zu kommen. Sonst ist's nachher doch zu viel neues auf einmal und dann geht gar nichts mehr vorwärts ;)

[Gunnar Bittersmann]

@@Der Martin

Design beginnt schon beim Konzept

Was genau wäre der Unterschied zwischen Design und Konzept?

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hallo,

Design beginnt schon beim Konzept

Was genau wäre der Unterschied zwischen Design und Konzept?

Konzept ist sowas wie das Pflichtenheft: Was muss das Produkt können, welche Eigenschaften soll es haben? Welche Technologien kommen in Frage? Was darf es kosten?

Design ist dann der gestalterische Aspekt: Wie setze ich die Anforderungen im Einzelnen um? Welche Mittel und Methoden sind dafür sinnvoll?
Die Lackierung, um wieder den Bogen zum PHP-Neuling zu spannen, ist einer der letzten Aspekte dabei, sollte aber von Anfang an schon mit betrachtet werden - zum Beispiel, weil für eine Fiberglas-Karosserie ganz andere Lacke nötig sind als für Stahlblech.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

meine Form ist eine Tabelle, in der die inputs alle in td's gepackt sind

ibäh ...

Müffelt’s?

Ist das ... in irgendeiner Art und Weise ungünstig? Sind Tabellen uncool geworden ?

Sie waren noch nie cool.

Sie waren schon immer cool. 😜

Jedenfalls nicht als Mittel zum Anordnen von Inhalten.

Ah so. 😉

Das war ein Notbehelf zu Zeiten, als CSS (bzw. die CSS-Unterstützung der Browser) noch in den Kinderschuhen steckte.

Und zu Zeiten vor CSS. Ja Kinder, es gab eine Zeit vor CSS. Opa erzählt vom Krieg …

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hi,

ibäh ...

Müffelt’s?

ich hatte noch überlegt, ob ich das wieder raussuchen sollte, dann aber doch lieber bleiben lassen.

Das war ein Notbehelf zu Zeiten, als CSS (bzw. die CSS-Unterstützung der Browser) noch in den Kinderschuhen steckte.

Und zu Zeiten vor CSS. Ja Kinder, es gab eine Zeit vor CSS. Opa erzählt vom Krieg …

Es gab sogar eine Zeit vor HTML. 😎
Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Live long and pros healthy,
 Martin

[PHP-Neuling]

Nun ja .. Vielleicht wäre das hilfreich wenn ich kurz interpretiere, was meine "seite" eigentlich anstellen soll

Die Unternehmensführung möchte, dass alle unsere Unternehmenszweige (Aussenstellen, Töchter, etc pp) dokumentiert auf welche öffentlichen Ausschreibungen sie sich bewerben, und mit welchem Ergebnis bzw welchen Hindernissen und Hürden

Diese Hindernisse, Hürden und Ergebnisse machen aktuell rund 70 inputfelder aus. Davon etliche als Checkbox.

Um diese Flut von Informationen bereitstellen zu können habe ich die Tabelle gewählt. So kann ich die inputs nochmal Untergliedern, und alles ordentlich in Reihe unter- und nebeneinander darstellen

Wenn es für sowas eine bessere/modernere Art zur Darstellung gibt als die Tabelle, bin ich für alle möglichen Unmöglichkeiten offen. Bin noch dumm und unerfahren, da ist jede neue Erfahrung gut :)

Danke

[TS]

Hello,

Nun ja .. Vielleicht wäre das hilfreich wenn ich kurz interpretiere, was meine "seite" eigentlich anstellen soll

Die Unternehmensführung möchte, dass alle unsere Unternehmenszweige (Aussenstellen, Töchter, etc pp) dokumentiert auf welche öffentlichen Ausschreibungen sie sich bewerben, und mit welchem Ergebnis bzw welchen Hindernissen und Hürden

Diese Hindernisse, Hürden und Ergebnisse machen aktuell rund 70 inputfelder aus. Davon etliche als Checkbox.

Um diese Flut von Informationen bereitstellen zu können habe ich die Tabelle gewählt. So kann ich die inputs nochmal Untergliedern, und alles ordentlich in Reihe unter- und nebeneinander darstellen

Wenn es für sowas eine bessere/modernere Art zur Darstellung gibt als die Tabelle, bin ich für alle möglichen Unmöglichkeiten offen. Bin noch dumm und unerfahren, da ist jede neue Erfahrung gut :)

Und löst Du die möglichen Eigenschaften auch atomistisch auf, oder speicherst Du Du sie alle in einem einzigen Datensatz der Haupttabelle?

Glück Auf
Tom vom Berg

[PHP-Neuling]

alle Daten werden in einem Datensatz gespeichert

[Gunnar Bittersmann]

@@PHP-Neuling

Um diese Flut von Informationen bereitstellen zu können habe ich die Tabelle gewählt.

Wenn man eine Flut von Informationen hat, sollte man zunächst überlegen, wie man diese in für Nutzer bekömmliche Häppchen aufteilt.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[PHP-Neuling]

das denke ich habe ich über die Übersicht (Also diese furchtbare, 30 Jahre alte Tabelle) ganz gut hinbekommen Die Frage der Normalisierung der DB habe ich leider noch nicht für mich gewinnbringend beantworten können.

[TS]

Hello,

Hi,

ibäh ...

Müffelt’s?

ich hatte noch überlegt, ob ich das wieder raussuchen sollte, dann aber doch lieber bleiben lassen.

Das war ein Notbehelf zu Zeiten, als CSS (bzw. die CSS-Unterstützung der Browser) noch in den Kinderschuhen steckte.

Und zu Zeiten vor CSS. Ja Kinder, es gab eine Zeit vor CSS. Opa erzählt vom Krieg …

Es gab sogar eine Zeit vor HTML. 😎
Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Ja, damit habe ich immer die Magnetbänder und später die Disketten entwertet.

Und zu Zeiten von Jaquard und später Hollerith waren die Löcher sogar noch eckig. Aus den Lochkarten habe ich als Kind immer Häuschen für meine Modelleisenbahn gebaut.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Ja, damit habe ich immer die Magnetbänder und später die Disketten entwertet.

Ich habe damit immer Disketten aufgewertet: doppelseitig beschreibbar gemacht.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hallo,

Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Ja, damit habe ich immer die Magnetbänder und später die Disketten entwertet.

Ich habe damit immer Disketten aufgewertet: doppelseitig beschreibbar gemacht.

an die Zeiten kann ich mich auch noch erinnern ...

Live long and pros healthy,
 Martin

[TS]

Hello,

Hallo,

Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Ja, damit habe ich immer die Magnetbänder und später die Disketten entwertet.

Ich habe damit immer Disketten aufgewertet: doppelseitig beschreibbar gemacht.

an die Zeiten kann ich mich auch noch erinnern ...

Wir gehören eben inzwischen zur Großelterfraktion :-O

Ich habe sogar noch mit Magnetkernspeichern (256 Bytes!) experimentiert. Leider habe ich die Muster mal verliehen und nie zurückbekommen.

Da war Datentypensparsamkeit noch existenziell und es gab noch Halbbytes und BCD-Speicherung.

Glück Auf
Tom vom Berg

[TS]

Hello,

@@TS

Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Ja, damit habe ich immer die Magnetbänder und später die Disketten entwertet.

Ich habe damit immer Disketten aufgewertet: doppelseitig beschreibbar gemacht.

Da konnte man schon sehen, wie wichtig es ist, wo man das Bit hinzufügt oder entfernt;-)

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

das waren die billigen Disketten, die nur für die Datensicherung waren. Da war das Lochen unproblematisch. Wobei - einseitige Disketten waren vermutlich nur in der Anfangszeit solche, bei denen eine Seite die Tests nicht bestanden hat. Später hat man sich die Tests gespart und einfach aus Marketinggründen ein- und zweiseitige Disketten verkauft - mit gleichen Floppies drin. Würde ich drauf wetten. Bis dann irgendwann keiner mehr einseitige wollte. Und dann keiner mehr Disketten.

Rolf

[TS]

Hello,

Hallo TS,

das waren die billigen Disketten, die nur für die Datensicherung waren. Da war das Lochen unproblematisch. Wobei - einseitige Disketten waren vermutlich nur in der Anfangszeit solche, bei denen eine Seite die Tests nicht bestanden hat. Später hat man sich die Tests gespart und einfach aus Marketinggründen ein- und zweiseitige Disketten verkauft - mit gleichen Floppies drin. Würde ich drauf wetten. Bis dann irgendwann keiner mehr einseitige wollte. Und dann keiner mehr Disketten.

Würde mich doch mal interessieren, wer noch 5,25" und 3,5" Disketten liegen hat und die auch noch lesen kann.

Für BIOS-Updates benötige ich tatsächlich manchmal noch ein (externes) 3,5"-Laufwerk.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Würde mich doch mal interessieren, wer noch 5,25" und 3,5" Disketten liegen hat

Ein Kommilitone hat mir mal eine 8″-Diskette^[1][2] geschenkt. In irgendeiner Kiste muss die noch sein …

und die auch noch lesen kann.

Das Etikett könnte noch lesbar sein.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

---

1. So sieht ein Zollzeichen aus, ihr Typografignoranten. 😉 ↩︎

2. Und so kein Deppenleerzeichen. ↩︎

[Der Martin]

Hallo,

Würde mich doch mal interessieren, wer noch 5,25" und 3,5" Disketten liegen hat und die auch noch lesen kann.

ob noch lesbar ... hmm, keine Ahnung, habe sie schon einige Jahre nicht mehr verwendet. Aber ich habe noch Disketten in beiden Formaten, ein externes 3½"-Laufwerk (in Double-Speed-Ausführung!) mit USB, und je ein eingebautes 3½- und 5¼"-Laufwerk in einem alten PC.

Die Hoffnung, aus Nostalgie noch irgendwo ein 8"-Floppylaufwerk herzukriegen, habe ich inzwischen aufgegeben.

Für BIOS-Updates benötige ich tatsächlich manchmal noch ein (externes) 3,5"-Laufwerk.

Oh. Das müssen dann aber schon recht alte Rechner sein.

Live long and pros healthy,
 Martin

[TS]

Hello,

Hallo,

Würde mich doch mal interessieren, wer noch 5,25" und 3,5" Disketten liegen hat und die auch noch lesen kann.

ob noch lesbar ... hmm, keine Ahnung, habe sie schon einige Jahre nicht mehr verwendet. Aber ich habe noch Disketten in beiden Formaten, ein externes 3½"-Laufwerk (in Double-Speed-Ausführung!) mit USB, und je ein eingebautes 3½- und 5¼"-Laufwerk in einem alten PC.

Die Hoffnung, aus Nostalgie noch irgendwo ein 8"-Floppylaufwerk herzukriegen, habe ich inzwischen aufgegeben.

Für BIOS-Updates benötige ich tatsächlich manchmal noch ein (externes) 3,5"-Laufwerk.

Oh. Das müssen dann aber schon recht alte Rechner sein.

Meistens Telefonanlagen oder manchmal auch Laptops, bei denen die ACPI-Driver fürs neue OS fehlen.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Und es gab eine Zeit, in der das wichtigste Werkzeug eines Programmierers eine Lochzange war.

Ja, damit habe ich immer die Magnetbänder und später die Disketten entwertet.

Ich habe damit immer Disketten aufgewertet: doppelseitig beschreibbar gemacht.

Da konnte man schon sehen, wie wichtig es ist, wo man das Bit hinzufügt oder entfernt;-)

Stimmt, zwischen doppelseitig beschreibbar und gar nicht mehr beschreibbar lagen nur wenige Zentimeter.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[PHP-Neuling]

ich antworte mir jetzt mal selbst, da ich aufgrund der extremen Fülle hier nur noch schwer zurecht komme

Ich habe nun gedacht, dass ich's halbwegs verstanden habe wie ich checkboxen speichere. Aber das schien nur so gedacht .. So siehts aktuell aus

if (isset ($_POST['aktion']) and $_POST['aktion'] =='speichern') {
$VARIABLE1 = $_POST['iVariable1'] //das "i" habe ich mir als eindeutiges Kennzeichen für iNPUT Felder mit eingesetzt --> normaler type=text eintrag, funktioniert
$Variable11 = implode(',', $_POST['iVariable11']); //checkbox
...
$aktualisieren = $db->prepare("UPDATE Variable1 = '$iVariable1', ..., Variable11 = '$iVariable11' Where ID = $ID1
$aktualisieren->execute();
echo $db->affected_rows;

Wenn ich das so aber durchführe, läd die Seite neu, es wird garnichts gespeichert und die affected_rows zeigt -1 ohne die checkbox-variable funktioniert der code.

Hab ich das implode irgendwie falsch angewandt? Der name="" der checkboxen ist entsprechend name="iVariable11"

[dedlfix]

Tach!

$aktualisieren = $db->prepare("UPDATE Variable1 = '$iVariable1', ..., Variable11 = '$iVariable11' Where ID = $ID1
$aktualisieren->execute();
echo $db->affected_rows;

Das ist ungültige SQL-Syntax. UPDATE tablename SET feld=wert ...

Zudem beachtest du nicht den Kontextwechsel und fügst die Werte so ein, dass SQL-Injection möglich ist. Nutze die Möglichkeiten des Prepared Statements, das du ja sowieso schon einsetzt. Falls du mysqli nimmst, wechsle lieber zu PDO, das bedient sich einfacher. Da müssen die Werte nicht gebunden werden, sondern können einfach dem Execute übergeben werden.

dedlfix.

[PHP-Neuling]

hi, sorry, der quellcode war ungenau da nur kurz abgeschrieben um nicht das original im netz rumschwirren zu lassen. für den kontextwechsel nutze ich htmlspecialchars.

natürlich heisst es korrekter UPDATE table SET Variable11 ....

Der knackende Punkt aktuell ist das implode und die checkboxen

[dedlfix]

Tach!

für den kontextwechsel nutze ich htmlspecialchars.

Falscher Kontext, SQL ist nicht HTML. Jeder Kontext benötigt seine eigene Behandlung.

Der knackende Punkt aktuell ist das implode und die checkboxen

Dann ist das eine gute Gelegenheit, Debugging zu lernen. Stehen vor der Operation die erwarteten Werte in den beteiligten Variablen? Erzeugt die Operation das gewünschte Ergebnis? Im einfachsten Fall fügt man Kontrollausgaben mit echo ein. Das ist aber sehr ungenau, weil beim echo die Werte zu String konvertiert werden. Besser nimmt man var_dump(), das zeigt Wert und Typ an.

dedlfix.

[PHP-Neuling]

vollkommen richtig, meinte natürlich mysql_real_escape_string ... reicht langsam bei mir :-D

[PHP-Neuling]

vollkommen richtig, meinte natürlich mysql_real_escape_string ... reicht langsam bei mir :-D

jetzt kann ich meinen eigenen Beitrag nicht mehr bearbeiten Oo

Habe das nochmal umgearbeitet und arbeite jetzt mit dem korrekten prepare statement, um halbwegs sauber, zukunftsorientiert und gesichert die Datenbank zu bearbeiten

$aktualisieren = $db->prepare("UPDATE table SET VARIABLE1 = ?, VARIABLE2 =?, ..... WHERE ID = $ID1);
$aktualisieren->bind_param('ss..., $Variable1, $Variable2, ...);
$aktualisieren->execute();

Das ist übersichtlicher als der real_escape kram und sicher auch sinn der "prepare" funktion.

... ich muss unbedingt mal lernen wie ich schleifen aus den rows bauen kann

Weiterhin habe ich aber noch das Problem mit meinen Checkboxen, dem implode und dem speichern

[dedlfix]

Tach!

Weiterhin habe ich aber noch das Problem mit meinen Checkboxen, dem implode und dem speichern

Wie gesagt: Debugging. Schau dir an, was du dem implode gibst, und was du als Ergebnis bekommst.

dedlfix.

[PHP-Neuling]

BÄMM!

So als DoppelNullAgent freut man sich gleich doppelt so sehr wenn mal was klappt :)

Da ich für implode ein Array benötige, welches sich aber aufgrund meiner Struktur gar nicht zusammenfassen lässt, habe ich's mit einem IF probiert

if (isset($_POST['NameDerCheckBox'])) 
	{ $Variable11= 1;
	} else { 
		$Variable11= 0;
}

Und siehe da, es funktioniert :))))))))))

Das muss ich jetzt zwar für jede Checkbox bauen, aber zumindest geht das erstmal

[Rolf B]

Hallo PHP-Neuling,

nein, du könntest vielmehr eine Funktion schreiben.

function getCheckboxValue($name) {
   if (isset($_POST[$name])) 
 	    return 1;
   else
      return 0;
}

$variable11 = getCheckboxValue('checkbox1');
$variable12 = getCheckboxValue('checkbox2');
$variable13 = getCheckboxValue('checkbox3');
$variable14 = getCheckboxValue('checkbox4');
$variable15 = getCheckboxValue('checkbox5');

PHP liest erst den ganzen Code durch und führt ihn danach aus, d.h. die function kann auch gern am Ende stehen.

Wenn Du den ternären ?: Operator kennst und verstehst, kannst Du die Checkboxen auch so einlesen:

$variable11 = isset($_POST['checkbox1']) ? 1 : 0;
$variable12 = isset($_POST['checkbox2']) ? 1 : 0;
$variable13 = isset($_POST['checkbox3']) ? 1 : 0;
$variable14 = isset($_POST['checkbox4']) ? 1 : 0;

Rolf

[PHP-Neuling]

cool, danke Rolf (+'n darf ich leider noch nicht)

Ich werde mir das ternärzeugs mal zu gemüte ziehen :)

[PHP-Neuling]

okay ich habs verstanden und für supercool befunden Das macht aus 4 übersichtlichen codezeilen, eine einzige übersichtliche Codezeile

Vielen vielen Dank :)

[TS]

Hello,

okay ich habs verstanden und für supercool befunden Das macht aus 4 übersichtlichen codezeilen, eine einzige übersichtliche Codezeile

Das ist mMn in der Praxis gehupft, wie gesprungen. Die Trinitätsschreibweise führt im ersten Schritt nämlich oft zu sehr langen Zeilen. Da muss man dann im Sinne der Lesbarkeit und ggf. "Druckbarkeit" (hierzu zähle ich auch HTML und PDF, ...) die Zeile wieder -irgendwo- umbrechen und muss Gehirnschmalz darauf verschwenden, an welchen Stellen dies erlaubt ist.

Am Ende hat man dann doch wieder drei Zeilen, die man dann später nicht mehr unbedingt als zusammemgehörig erkennt.

Code "codiert" zu notieren ist keine gute Idee!

Der (zeitliche) Abstand zum Projekt darf die Verständlichkeit nicht mindern. Für jede weitere "Codierung" aka Kurzschreibweise muss man dann erfahrungsgemäß eine Kommentarzeile mehr spendieren.
Was hat man dadurch gewonnen?

Schreibfaulheit rächt sich meistens genau zu der Zeit, an der man gerade keine davon hat.

Glück Auf
Tom vom Berg

[PHP-Neuling]

hi okay, danke für deine Meinung, zunächst mal hat das mit Schreibfaulheit nichts am Hut. Zunächst hatte ich alle (über 30) Checkboxen bereits mit dem IF Statement geschrieben. Dies zerriss aber optisch den Quellcode enorm, da die Statements nun einmal in der Variablenliste standen.

Die Arbeit hatte ich also schon gemacht, und hab mir nun durch das Ändern noch viel mehr Arbeit gemacht.

Die ternäre Schreibweise ist aber ein Einzeiler, und fügt sich bei der Masse daher super ein. Notwendig war Ein // Kommentar, nachdem dann alle betreffenden Zuweisungen stattfinden. Somit sollte ich auch in 7 Monaten noch Wissen, was ich da gemacht habe :)

Und zu guter Letzt zählt für mich immer wieder der Punkt ganz groß: Wieder was gelernt

:)

Aber trotzdem bin ich sehr dankbar, dass du immer kritisch rein haust, weil das zum nachdenken und überlegen über die eigenen (kommenden) Vorlieben anregt. Den ein oder anderen Gedankengang hätte ich sonst gar nicht

Bleibt gesund

[Der Martin]

Moin,

Da muss man dann im Sinne der Lesbarkeit und ggf. "Druckbarkeit" (hierzu zähle ich auch HTML und PDF, ...) die Zeile wieder -irgendwo- umbrechen und muss Gehirnschmalz darauf verschwenden, an welchen Stellen dies erlaubt ist.

nur in Sprachen wie etwa Javascript, wo das Weglassen des abschließenden Semikolons erlaubt ist. Bei etwas strengerer Syntax (PHP, C) bleibt das Statement eindeutig, egal an welcher Stelle man einen Umbruch einfügt^[1].

Am Ende hat man dann doch wieder drei Zeilen, die man dann später nicht mehr unbedingt als zusammemgehörig erkennt.

Im Fall des ternären Operators kann man das aber sehr leicht hinbiegen, indem man so trennt, dass die zweite und dritte Zeile mit dem Fragezeichen bzw. dem Doppelpunkt beginnen (und eingerückt sind).

Code "codiert" zu notieren ist keine gute Idee!

Völlig richtig - aber da sind wir wieder beim Knackpunkt: "Gut lesbar" ist individuell unterschiedlich. Für mich sind beispielsweise Coding Styles eine Katastrophe, bei denen öffnende geschweifte Klammen am Zeilenende stehen. Da übersehe ich sie regelmäßig.

Der (zeitliche) Abstand zum Projekt darf die Verständlichkeit nicht mindern. Für jede weitere "Codierung" aka Kurzschreibweise muss man dann erfahrungsgemäß eine Kommentarzeile mehr spendieren.

Nein. Eine kurze, kompakte Schreibweise sollte so gestaltet sein, dass sie nicht nur das Schreiben, sondern auch das Lesen und Verstehen erleichtert. Unabhängig davon ist eine großzügige Kommentierung des Codes immer eine gute Idee. Und bitte: Schreibt vor allem das in den Kommentar, was nicht aus dem Code selbst schon offensichtlich ist.

Schreibfaulheit rächt sich meistens genau zu der Zeit, an der man gerade keine davon hat.

Sehe ich nicht unbedingt so. Schreibfaulheit kann auch heißen, sich für häufig wiederkehrende Ausdrücke eine Funktion oder ein Makro zu schreiben. Das kommt meistens auch der Verständlichkeit zugute.

Live long and pros healthy,
 Martin

---

1. Natürlich nicht innerhalb eines Tokens, etwa eines Bezeichners oder einer Zahl. ↩︎

[dedlfix]

Tach!

Völlig richtig - aber da sind wir wieder beim Knackpunkt: "Gut lesbar" ist individuell unterschiedlich. Für mich sind beispielsweise Coding Styles eine Katastrophe, bei denen öffnende geschweifte Klammen am Zeilenende stehen. Da übersehe ich sie regelmäßig.

Liest du den Code anhand der Klammern oder nicht doch eigentlich anhand der Einrückungen?

Dass die {}-Klammern im Prinzip überflüssig sind, merkt man, wenn man mal etwas Python programmiert. Die Lesbarkeit hängt für mich nicht an den Klammerpositionen, sondern an der Zeilenlänge und den Einrückungen.

block 
{
    Lorem ipsum dolor;
    sit amet consectetur adipiscing elit;
    sed do eiusmod tempor;
incididunt ut labore et dolore magna aliqua;
Ut enim ad minim veniam;
}

Mit den Klammern kann man nur recht einfach einen Formatierungsfehler erkennen, was bei Python nur anhand der Logik ginge.

dedlfix.

[Der Martin]

Hallo,

Für mich sind beispielsweise Coding Styles eine Katastrophe, bei denen öffnende geschweifte Klammen am Zeilenende stehen. Da übersehe ich sie regelmäßig.

Liest du den Code anhand der Klammern oder nicht doch eigentlich anhand der Einrückungen?

eigentlich beides, und wenn's divergiert, stutze ich unwillkürlich. Mir wurde schon oft fremder C-Quellcode vor die Füße gekippt, bei dem Einrückungen durch eine wilde Mischung von Tabs und Spaces nur noch wie Kraut und Rüben aussahen. Deswegen habe ich mir über die Jahre angewöhnt, nicht so sehr auf Einrückung zu achten, sondern mich auch an der Klammerstruktur zu orientieren.

Dass die {}-Klammern im Prinzip überflüssig sind, merkt man, wenn man mal etwas Python programmiert.

Ich weiß, aber das fühlt sich für mich noch sehr fremd und unbehaglich an.

block 
{
    Lorem ipsum dolor;
    sit amet consectetur adipiscing elit;
    sed do eiusmod tempor;
incididunt ut labore et dolore magna aliqua;
Ut enim ad minim veniam;
}

An dem Beispiel fallen mir tatsächlich erst die prominent gesetzten Klammern auf, und dann erst, dass die Einrückung nicht konsistent dazu ist.

Live long and pros healthy,
 Martin

[dedlfix]

Tach!

okay ich habs verstanden und für supercool befunden Das macht aus 4 übersichtlichen codezeilen, eine einzige übersichtliche Codezeile

Das ist mMn in der Praxis gehupft, wie gesprungen. Die Trinitätsschreibweise führt im ersten Schritt nämlich oft zu sehr langen Zeilen.

Ich verstehe dein Anliegen, aber daran ist nicht der conditionale Operator schuld. Wenn man sehr lange Zeilen hat, sollte man eher darüber nachdenken, kürzere Terme zu erstellen, beispielsweise durch den Einsatz von Funktionen.

Es ist einfacher zu erkennen, dass nur eine Variable gesetzt werden soll, wenn es nur eine Variablenzuweisung gibt, statt zwei Zuwesungen an dieselbe Variable in unterschiedlichen Blöcken.

In Sprachen, in denen jeder Block einen eigenen Scope darstellt, ist zudem if-else nachteilig, weil die Variable zusätzlich außerhalb deklariert werden muss, damit sie nach dem if-else noch existiert. Beispiel Javascript, auch ohne {}-Klammern bilden sich da zwei Blöcke:

let foo;
if (bedingung)
    foo = 42;
else
    foo = 23; 

console.log(foo);

Selbst wenn sich der Wert von foo nicht mehr ändert, muss man let statt const nehmen. Mit dem conditionalen Operator gibt es keine separate Deklaration, und man kann let oder const nehmen, so wie man es fachlich braucht.

const foo = bedingung ? 42 : 23;

Da muss man dann im Sinne der Lesbarkeit und ggf. "Druckbarkeit" (hierzu zähle ich auch HTML und PDF, ...) die Zeile wieder -irgendwo- umbrechen und muss Gehirnschmalz darauf verschwenden, an welchen Stellen dies erlaubt ist.

Letzteres halte ich nur bei Sprachen mit optionalem Anweisungsbegrenzer (Javascripts Semikolon) für bedingt problematisch.

Am Ende hat man dann doch wieder drei Zeilen, die man dann später nicht mehr unbedingt als zusammemgehörig erkennt.

Das Problem der einfachen Lesbarkeit löst sich nicht wirklich, wenn man viel Code nur am selben Platz in anderer Form notiert. Wenn die Erzeugung der Werte sehr aufwendig ist, stört das generell den Lesefluss. Da hilft Code auszulagern besser.

Der (zeitliche) Abstand zum Projekt darf die Verständlichkeit nicht mindern. Für jede weitere "Codierung" aka Kurzschreibweise muss man dann erfahrungsgemäß eine Kommentarzeile mehr spendieren.

Das kann ich so nicht erkennen. Du würdest damit die Syntax kommentieren. Um Syntax zu erlernen, gibt es die Tutorials und die Dokumentation der Programmiersprache. Wenn es einen Erklärungsbedarf gibt, dann liegt das sicherlich nicht an der Syntax.

Schreibfaulheit rächt sich meistens genau zu der Zeit, an der man gerade keine davon hat.

Das Problem sortiere ich bei if-else vs. ?: nicht unter Schreibfaulheit ein, sondern als generelles Problem, seinen Code erfassbar zu schreiben.

dedlfix.

[MudGuard]

Hi,

conditionale Operator

Danke!

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo Rolf,

nein, du könntest vielmehr eine Funktion schreiben.

für mehrfach wiederkehrende, gleichartige Aufgaben und Abläufe ist das wohl die beste Lösung.

function getCheckboxValue($name) {
   if (isset($_POST[$name])) 
 	    return 1;
   else
      return 0;
}

$variable11 = getCheckboxValue('checkbox1');
$variable12 = getCheckboxValue('checkbox2');
$variable13 = getCheckboxValue('checkbox3');
$variable14 = getCheckboxValue('checkbox4');
$variable15 = getCheckboxValue('checkbox5');

Und wenn man die Formularelemente auch noch günstig benennt, so dass PHP die Werte als Array bekommt, kann man bequem mit einer Schleife darüber iterieren.

Wenn Du den ternären ?: Operator kennst und verstehst

Der ist doch hier prädestiniert. Wenn du ihn nicht erwähnt hättest, dann hätte ich ihn jetzt vorgeschlagen.

Live long and pros healthy,
 Martin

[TS]

Hello,

Und wenn man die Formularelemente auch noch günstig benennt, so dass PHP die Werte als Array bekommt, kann man bequem mit einer Schleife darüber iterieren.

Zu diesem Zweck sollte man aber nicht über das POST-Array iterieren, sondern über das Kontrollarray (das z. B. in der Session wartet) und dessen Elemente mit dem POST-Array abgleichen.

Wenn man beim Abgleich die gefundenen Elemente aus dem POST-Array löscht (unset()), bleiben dort nur die unerwünschten übrig. Sollte es welche geben, ist der POST gefaked.

Und gleiches gilt auch, wenn es im Kontrollarray ein Element gibt, das im POST-Array fehlt, außer Radios und Checkboxes, versteht sich.

Endsprechend schlau sollte man daher die Arrays aufbauen/die Namen für die Elemente wählen.

Glück Auf
Tom vom Berg

[Der Martin]

Hallo Tom,

Und wenn man die Formularelemente auch noch günstig benennt, so dass PHP die Werte als Array bekommt, kann man bequem mit einer Schleife darüber iterieren.

Zu diesem Zweck sollte man aber nicht über das POST-Array iterieren

natürlich nicht stur über $_POST in seiner ganzen Pracht, sondern nur über bekannte Gruppen. In einem Bestellformular für eine Pizza mit 5 wählbaren Zutaten würde ich die Checkboxen beispielsweise mit topping[0] bis topping[4] benamsen und dann mit 0..4 über $_POST['topping'][$i] herfallen und die isset-Abfragen machen.

sondern über das Kontrollarray (das z. B. in der Session wartet) und dessen Elemente mit dem POST-Array abgleichen.

Das kann man natürlich auch, obwohl mir das im Moment etwas zu kompliziert erscheint.

Wenn man beim Abgleich die gefundenen Elemente aus dem POST-Array löscht (unset()), bleiben dort nur die unerwünschten übrig. Sollte es welche geben, ist der POST gefaked.

Was ich in den meisten Fällen nicht schlimm fände; ich würde unerwartete zusätzliche Parameter einfach ignorieren. Oder möchtest du dann die Bearbeitung abbrechen und eine Antwort "Böser Betrüger! Tu das nie wieder!" senden? 😀

Live long and pros healthy,
 Martin

[TS]

Hello,

Hallo Tom,

Und wenn man die Formularelemente auch noch günstig benennt, so dass PHP die Werte als Array bekommt, kann man bequem mit einer Schleife darüber iterieren.

Zu diesem Zweck sollte man aber nicht über das POST-Array iterieren

natürlich nicht stur über $_POST in seiner ganzen Pracht, sondern nur über bekannte Gruppen. In einem Bestellformular für eine Pizza mit 5 wählbaren Zutaten würde ich die Checkboxen beispielsweise mit topping[0] bis topping[4] benamsen und dann mit 0..4 über $_POST['topping'][$i] herfallen und die isset-Abfragen machen.

sondern über das Kontrollarray (das z. B. in der Session wartet) und dessen Elemente mit dem POST-Array abgleichen.

Das kann man natürlich auch, obwohl mir das im Moment etwas zu kompliziert erscheint.

Wenn man beim Abgleich die gefundenen Elemente aus dem POST-Array löscht (unset()), bleiben dort nur die unerwünschten übrig. Sollte es welche geben, ist der POST gefaked.

Was ich in den meisten Fällen nicht schlimm fände; ich würde unerwartete zusätzliche Parameter einfach ignorieren. Oder möchtest du dann die Bearbeitung abbrechen und eine Antwort "Böser Betrüger! Tu das nie wieder!" senden? 😀

• Ich würde zu einem HTTP-Response Code 406 unter Beifügen der Meldung "es ist ein Fehler aufgetreten, bitte Anfrage wiederholen" und ggf. dem (soweit zulässig) vorausgefüllten Formular reagieren {1}

• im Application Log würde ich den Vermerk "wrong post params" mit IP, Uhrzeit und Name des Moduls/Skripts hinterlassen, damit Fail2ban sich darum kümmern kann.

Das hat erstmal nichts mit unplausibel ausgefüllten Dialogelementen zu tun. Diesen Fall muss man extra betrachten.

Der User (Bot?) muss von den Hintergrundmaßnahmen darüberhinaus nichts mitbekommen.

BTW:
Ich plädiere für das Wiki an dieser Stelle übrigens dafür, sich nicht ellenlang über die "richtige" Formulargestaltung mit Labels und sonstigen durchaus an anderer Stelle wichtigen Dingen auseinanderzusetzen, sondern eher auf die PHP-relevanten Verfahren einzugehen.

Glück Auf
Tom vom Berg

[TS]

Hello,

Thread von @robertroth abgetrennt als eigene Fragestellung

Glück Auf
Tom vom Berg

[Waltraut von der Vogelweide]

function getCheckboxValue($name) {
   if (isset($_POST[$name])) 
 	    return 1;
   else
      return 0;
}

$variable11 = getCheckboxValue('checkbox1');

Wenn Du den ternären ?: Operator kennst und verstehst, kannst Du die Checkboxen auch so einlesen:

$variable11 = isset($_POST['checkbox1']) ? 1 : 0;

Eigentlich ist die ganze Abfragerei überflüssig. Die Zeile

$variable11 = isset($_POST['checkbox1']);

reicht vollkommen.

Die Zuweisung einer Zahl ist nur nötig, falls diese Zahl später Grundlage irgendeiner Berechnung sein soll. Falls aber nur Sachen in der Form if ($variable11) folgen (oder schlimmer: if ($variable11 == 1)), dann reicht ein Bool'scher Wert.

[TS]

Hello,

Da ich für implode ein Array benötige, welches sich aber aufgrund meiner Struktur gar nicht zusammenfassen lässt, habe ich's mit einem IF probiert

if (isset($_POST['NameDerCheckBox'])) 
	{ $Variable11= 1;
	} else { 
		$Variable11= 0;
}

Und siehe da, es funktioniert :))))))))))

Das muss ich jetzt zwar für jede Checkbox bauen, aber zumindest geht das erstmal

Das ist im Prinzip der richtige Weg.
Ich erinnere aber nochmal an meinen Punkt 6 des Postings ganz am Amfang.

Wenn Du dann beim Edit (UPDATE) angekommen bist:
Es könnte nämlich sonst passieren, dass Dir jemand einen manipulierten Postrequest sendet, oder der durch technischen Fehler entsteht. Und schwupps, sind alle Checkboxen wieder zurückgesetzt.

Prüfe also als erstes immer. ob alle Pflichtparameter gepostet wurden, aber auch keiner zusätzlich!

Glück Auf
Tom vom Berg

[PHP-Neuling]

Servus und Hallo, da bin ich wieder 😀

Ich konnte nun tatsächlich herausfinden, wie ich meine Columns in ein array packe um diese dann auszugeben. Dass vereinfacht die SQL Befehle ungemein, aber (...)

$feldliste = array();
$tabellen = "SHOW COLUMNS FROM TABLE";
$result = mysqli_query($db,$tabellen);
while($qow = mysqli_fetch_array($result)){
		$feldliste[] = $qow['Field']." = ?, " ;
}
$AnzahlFelder = count ($feldliste);
//echo ($feldliste[$AnzahlFelder]);
for ($x = 1; $x < $AnzahlFelder; $x++) {
		echo rtrim($feldliste[$x],",");
	}

wie man im "while" sieht hänge ich an die einzelnen strings (also die cols) jeweils noch " = ?, " an, um den korrekten Kontext für UPDATE Befehle usw geben zu können. Das funktioniert auch hervorragend. Der erste Eintrag wird entfernt, da COL1 die "ID" enthält.

Nur muss nun beim letzten ausgelesenen Eintrag das "," verschwinden, da der UPDATE Befehl sonst fehlerhaft endet

UPDATE TABLE SET VAR1 = ?,..., VAR65 = ?, WHERE ID = $ID1;

Das letzte Kommate muss also abgeschnitten werden, was ich über die Schleife und RTRIM versucht habe. Aber das Schwein RTRIM schneidet mir das Komma nicht weg :-/

Hat da jemand einen Tipp für mich ? Also ... noch einen ... ;)

Grüße

---

Direkt nach dem SChreiben fiels mir selber auf ... In der Schleife das letzte Zeichen abzuschneiden ist eh absolut sinnfrei, bitte also ignorieren . 🤦

Da wäre es wohl eher notwendig, die einträge nacheinander in eine variable anzuhängen

[dedlfix]

Tach!

Das letzte Kommate muss also abgeschnitten werden, was ich über die Schleife und RTRIM versucht habe. Aber das Schwein RTRIM schneidet mir das Komma nicht weg :-/

Debugging. Genau nachvollziehen, was für Daten man hat, die man bearbeiten möchte, ist zwar mühsam, aber der beste Schlüssel zum Erfolg für das Verstehen des Problems.

Hat da jemand einen Tipp für mich ? Also ... noch einen ... ;)

Besser fährt man, wenn man die Einzelteile in einem Array sammelt und dieses am Ende implodiert, mit Komma als Glue-Parameter.

dedlfix.

[PHP-Neuling]

hi,

Danke !

Da bekomme ich jetzt leider gar keine Ausgabe gezeigt. Wahrscheinlich wieder irgendein Schusselfehler drin, den ich einfach nicht finde

for ($x = 1; $x < $AnzahlFelder; $x++) {
		echo implode(" = ?, ",$feldliste[$x]);
	}

[dedlfix]

Tach!

Da bekomme ich jetzt leider gar keine Ausgabe gezeigt. Wahrscheinlich wieder irgendein Schusselfehler drin, den ich einfach nicht finde

for ($x = 1; $x < $AnzahlFelder; $x++) {
		echo implode(" = ?, ",$feldliste[$x]);
	}

So geht das nicht zu kombinieren. Das =? brauchst du für jedes Element, das , hingegen zwischen den Elementen. Du musst jedes Element mit =? versehen und zu einem temporären Array hinzufügen. Das Array wird am Ende implodiert.

dedlfix.

[Rolf B]

Hallo dedlfix,

klar geht das. Die Schleife zum Anhängen von "= ?" muss nicht sein. Man muss außer dem Kleber nur ein bisschen Kitt ans Ende schmieren.

Rolf

[Rolf B]

Hallo PHP-Neuling,

der Schusselfehler heißt, loszulegen ohne das Handbuch genau anzuschauen.

https://www.php.net/manual/de/function.implode.php

Dort zeigt das Beispiel von Omar auch, wie Du implode ergänzen kannst, wenn mehr zu tun ist als nur gleichartigen Kleber zwischen die Teile zu schmieren.

Rolf

[PHP-Neuling]

okay das Problem war wohl das array im implode. wieder denkfehler .. naja wird schon irgendwann :)

$AnzahlFelder = count ($feldliste);
echo $AnzahlFelder;
for ($x = 1; $x < $AnzahlFelder; $x++) {
		$Feldsatz[] = $feldliste[$x];
	}
echo implode(" = ?, ",$Feldsatz);

So hier klappt es jetzt. Das Array $Feldsatz enthält jetzt die Daten die ich brauche, zumindest fast. Denn nun fehlt natürlich am letzten Eintrag das " = ? "

Ich sehe mir auch das nochmal genauer an. Mir gehen langsam die Ideen für Variablennamen aus :D

Danke danke danke danke danke, ihr seit super 😀

[Rolf B]

Hallo PHP-Neuling,

Mir gehen langsam die Ideen für Variablennamen aus :D

Wenn man seinen Code in Funktionen gliedert, kann man Variablennamen wiederverwenden (weil sie nur innerhalb der Funktion sichtbar sind).

Das am Schluss fehlende "= ?" bekommst Du sicherlich noch drangepünktelt 😉

Rolf

[PHP-Neuling]

yes, made it :)

$ColSet = implode(" = ?, ",$Feldsatz); $ColSet = $ColSet . " = ?";

Wieder eine neue variable .... :D

Aber so langsam wird's :)

[Rolf B]

Hallo PHP-Neuling,

du kannst ja auch ein paar Variablen einsparen. Aber ob Du es dann noch verstehst?

$result = mysqli_query($db, "SHOW COLUMNS FROM TABLE");
if ($result !== FALSE) 
{
   $colSet = implode("= ?, ", 
                     array_column(mysqli_fetch_all($result, MYSQLI_ASSOC),
                                  'Field'))
            . " = ?";
}
else
{
   // Fehler beim Lesen des Colset
}

Gar nicht so schlimm wie es aussieht 😉

• das SQL Statement muss nicht in eine Variable, das kann man direkt übergeben
• $result brauchen wir, weil die Query fehlschlagen kann und dann FALSE liefert. Das muss man abfragen und das fehlte bei Dir bisher noch.
• mysql_query liefert ein mysqli_result Objekt und das kann außer einem Einzelzeilen-Fetch auch einen Fetch aller Rows in einem Aufruf mit mysqli_fetch_all. Dem muss man nur sagen wie die Zeilen aussehen sollen. Da Du über Feldnamen zugreifen willst, ist es MYSQLI_ASSOC. Vorher hast DU fetch_array verwendet, der hat MYSQLI_BOTH als Default. fetch_all hat MYSQLI_NUM als Default, darum muss man angeben dass man Namen will.
• Das Ergebnis des mysqli_fetch_all ist ein Array aus den ermittelten Zeilen. Das jage ich durch den Spaltenprojektor array_column. Der isoliert aus einem Array von Arrays eine einzelne Spalte. Hier: Field.

// vorher: 
$allRows = [ 0 => [ 'Marke' => 'Audi'    , 'Modell' => 'A4' ],
             1 => [ 'Marke' => 'BMW'     , 'Modell' => '320' ],
             2 => [ 'Marke' => 'Mercedes', 'Modell' => 'A180' ],
             3 => [ 'Marke' => 'VW'      , 'Modell' => 'Golf' ] ];
$marken = array_column($allRows, 'Marke');
// Ergebnis:
   [ 0 => 'Audi', 1 => 'BMW', 2 => 'Mercedes', 3 => 'VW' ];

Und dieses Ergebnisarray wird nun mit '=?,' als Kleber implodiert und durch '=?' ergänzt.

Variablen? Nicht so viele. Die meisten Arbeitsdaten leben nur kurz auf dem Stack. Nachteil: Wenn was schiefgeht, kannst Du die Schritte nicht einzeln überprüfen. D.h. es ist durchaus nützlich, mit vielen Variablen anzufangen. Und solchen Code in Funktionen zu isolieren. Tablename rein, column Set raus.

Rolf

[PHP-Neuling]

hi zusammen, schön, dass ihr hier so fleißig an posten seit. :-P

Nun, ich habe da schon wieder eine Frage ... 🤦

Da ich nun eine Lösung für das Auslesen der Felder und das damit verbundene einsetzen des arrays für den UPDATE Befehl gefunden hatte, dachte ich, warum mach'ste das nicht auch für die Variablen im bind_param?

gesagt getan, funktioniert nicht :-/

Es sähe jetzt wie folgt aus

	$aktualisieren = $db->prepare("UPDATE TABLE SET $ColSet WHERE ID = $ID1");

Das ColSet enthält nach wie vor die Namen der DB Felder. Der Befehl funktioniert

Nun wollte ich mir auch das hier einfacher machen

$aktualisieren->bind_param('sssssssssssssssssissssssssssiiiiiiiiiiiiiiiiiiisiiisisisssssssss', $VarUpd);

Ich habe 64 Variablen. Diese habe ich vorher in ein Array $VarUpd gepackt

wenn ich diesen Befehl ins Echo schmeisse, kommt auch alles korrekt raus. Haue ich das Array $VarUpd aber ins bind_param, bleibt die Seite beim Ausführen weiß´(das ist auch son schei** Unding) und entsprechend wird auch nichts gespeichert

Kopiere ich die Variablen nun alle händisch rein, statt das Array zu nutzen, funktioniert das

Wird die Variable nicht ausgewertet beim Befehl?

Mein Logfile vom IIS sagt leider nichts dazu, kein Fehler

So wird das $VarUpd gebaut

$UpdateVariablen = array(
"Var1",
"Var2",
...
);
foreach ($UpdateVariablen as $value) {
	$VarAktualisieren[] = '$' . $value;

}

$VarUpd = implode(", ",$VarAktualisieren);

Grüße

[Felix Riesterer]

Lieber PHP-Neuling,

Du willst einen Datensatz updaten, der 60+ spalten hat. Vielleicht hilft Dir meine Vorgehensweise ein bisschen?

$query = array(
  'sql' => 'UPDATE `tabellenname` SET'.PHP_EOL,
  'params' => array()
);

foreach ($datensatz as $key => $value) {
  $query['sql'] .= sprintf(' `%1$s`=:%1$s,'.PHP_EOL, $key);
  $query['params'][':'.$key] = $value;
}

// letztes Komma entfernen (Zeilenende erhalten)
$query['sql'] = preg_replace(
  '~(?s),([\r\n\t]*)$~',
  '$1',
  $query['sql']
);

$query['sql'] .= 'WHERE `primärindex`=:primaerindex'.PHP_EOL;
$query['params'][':primaerindex'] = 'wasweisdennich';

// debug($query) zum prüfen...?

$db->prepare($query['sql']);
$db->execute($query['params']);

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

boah, und ich dachte so langsam hab ich's verstanden. Hab selbst jetzt noch kleine Scripte hinbekommen, für's sortieren, select Felder usw. War schon fast stolz

Dann kommt Felix, mit so 'nem Ding, das bei mir mehr Kommentar- als Codezeilen hätte :'D

Ich google mal durch, was die ganzen Funktionen zu bedeuten haben 😀

Aber, für's eigene Verständnis, warum funktioniert das nicht so, wie ich das probiert habe? Alle meine Variablen stehen in der einen Variable $VarUpd. Wieso zieht der UPDATE Befehl die nicht da raus ?

Grüße

[dedlfix]

Tach!

Haue ich das Array $VarUpd aber ins bind_param, bleibt die Seite beim Ausführen weiß´(das ist auch son schei** Unding) und entsprechend wird auch nichts gespeichert

Ist das ein für die Entwicklung vorgesehenes System oder entwickelst du auf dem Produktivsystem? Es kann sein, dass das System so eingestellt ist, dass es keine Fehlermeldungen in das HTML-Resultat ausgibt. So ist das auch sinnvoll in produktiven Umgebungen, dass Anwender keine Details zu sehen bekommen, mit denen sie bestenfalls nichts und im ungünstigen Fall Unfug anstellen können. Schau in der phpinfo()-Ausgabe nach, wie display_errors und display_statup_errors eingestellt ist, sowie error_reporting. In dem Fall sollte dir der Administrator Zugriff auf das Errorlog gewähren, so dass du trotzdem die Fehlermeldungen anschauen kannst.

dedlfix.

[PHP-Neuling]

danke dedlfix,

ja, so ist das eingestellt auf dem Produktivsystem. Bislang konnte ich (prä-PHP-Ära) im IIS Log einsehen, was für FEhler aufgetreten sind. Nun steht dort aber nichts mehr zu den Details drin. lediglich 304, 500 oder ähnliches

Das jetzt aber die Seite einfach weiß bleibt, ist Echt mist ;)

Grüße

[dedlfix]

Tach!

ja, so ist das eingestellt auf dem Produktivsystem. Bislang konnte ich (prä-PHP-Ära) im IIS Log einsehen, was für FEhler aufgetreten sind. Nun steht dort aber nichts mehr zu den Details drin. lediglich 304, 500 oder ähnliches

Dann schau nochmal in die phpinfo()-Ausgabe, wo Fehlermeldungen hingeschrieben werden. Siehe Konfigurationswerte für das Error Handling, insbesondere log_errors und error_log.

Das jetzt aber die Seite einfach weiß bleibt, ist Echt mist ;)

Wie gesagt, das ist gut so, damit keine internen Details veröffentlicht werden. Wenn es sich nicht gerade um einen Startup-Fehler handelt (zum Beispiel Syntaxfehler), bei dem PHP bereits vor Ausführen deines Scripts scheitert, kannst du auch am Anfang des Scripts das error_reporting und display_errors so einstellen, dass du mehr Informationen ausgegeben bekommst. Alternativ hilft auch eine .user.ini-Datei.

dedlfix.

[PHP-Neuling]

den pfad kann ich sehen über die phpinfo. dort habe ich aber keinen Zugriff Habe das wieder in der Zentrale angefragt, um wenigstens etwas debuggen zu können

Danke dir dedl :)

[Rolf B]

Hallo PHP-Neuling,

wenn Du auf einem Produktivsystem entwickelst, dann sprich mal viel lieber die Bereitstellung eines Entwicklungssystems an. Entwickeln in PROD geht gar nicht, spätestens dann nicht wenn eine erste Version live ist.

Rolf

[PHP-Neuling]

Hi Rolf,

da hast du natürlich vollkommen recht. Aber dieses Thema wurde bereits des öfteren abgeschlagen.

Auf längere Sicht werde ich mir selbst mal ein Entwicklungssystem aufbauen, aber dafür fehlt mir noch die Technik.

[Julius]

Hallo PHP-Neuling,

Auf längere Sicht werde ich mir selbst mal ein Entwicklungssystem aufbauen, aber dafür fehlt mir noch die Technik.

Da du höchstwahrscheinlich Windows nutzt, dürfte dafür die einfachste Lösung die Installation von XAMPP sein. Da hast du Apache als Webserver, PHP und MySQL^[1] mit phpMyAdmin. Konfigurationsänderungen und Zugriff auf die Log-Dateien sind dann kein Thema.

Für den Fall, dass nur PHP selbst benötigt wird, bringt PHP auch einen einfach zu benutzenden eingebauten Webserver mit. Den nutze ich zum Entwickeln, für das Drumherum wie Datenbanken muss man sich dann halt ggf. selber kümmern.

Gruß
Julius

---

1. Eigentlich MariaDB, aber das ist von der Anwendung her nicht weiter wichtig. ↩︎

[Rolf B]

Hallo Julius,

das kann man machen - ich würde aber erstmal prüfen was beim Arbeitgeber des OP gehostet wird. Es könnte ja auch ein IIS sein - und den hat Windows gleich eingebaut, muss man nur als Feature aktivieren. Bei DB-Servern kann man auch auf dem Unternehmensserver eine Test-DB beantragen und sich darauf Owner-Rechte geben lassen.

Rolf

[Tabellenkalk]

Hallo,

Es könnte ja auch ein IIS sein - und den hat Windows gleich eingebaut, muss man nur als Feature aktivieren.

Jedes Windows, oder nur bestimmte Versionen? Welche?

Gruß
Kalk

[Tabellenkalk]

Hallo,

Jedes Windows, oder nur bestimmte Versionen? Welche?

OK, mit dem Stichwort „Internetinformationsdienste“ im richtigen Einstellungsdialog wird man fündig…

Gruß
Kalk

[PHP-Neuling]

hi tatsächlich nutzen wir einen IIS, Statt phpmyadmin muss/darf/soll ich die MySQL Workbench nutzen

da muss man sich erst dran gewöhnen, aber so langsam komme ich damit gut zurecht

[Raktenphilosoph]

Statt phpmyadmin muss/darf/soll ich die MySQL Workbench nutzen

Mit deucht, dass derjenige, welcher das so festgelegt hat, im Rahmen des von ihm bestimmbaren sehr klug gehandelt hat.

[PHP-Neuling]

ach, Rakete ... :D

Zu Beginn war ich überhaupt nicht deiner Meinung. Mit der Bench klar zu kommen war wirklich nicht einfach, gerade nicht wenn man sonst nur access kennt und das ein oder andere mal phpmyadmin gesehen hat

Mittlerweile aber kann ich, wie gesagt, gar nicht mehr meckern. Im Gegenteil, lernt man die Datenbankbefehle viel besser in der Bench, da man ständig damit berührt wird

[Rolf B]

Hallo PHP-Neuling,

okay - dann könntest Du Dir, wenn Du hinreichend Rechte auf deinem Arbeitsplatz-PC hast, dort den IIS aktivieren, über "Windows-Features aktivieren oder deaktivieren".

Die .NET und ASP.NET Features brauchst Du für PHP nicht, Websockets auch nicht unbedingt, Kompression ist auch optional.

Im IIS Manager stellst Du dann auf Computer-Ebene PHP als FastCGI-Anwendung ein und fügst der Default Web Seite einen FastCGI Handler hinzu. Details kannst Du bekommen wenn klar ist, ob Du das willst und darfst.

Rolf

[Gunnar Bittersmann]

@@PHP-Neuling

Mir gehen langsam die Ideen für Variablennamen aus :D

Da muss man nicht besonders ideenreich sein. Man fängt mit a an, dann b, c, … Wenn man bei z angekommen ist, macht man mit aa, ab, … weiter.

Vorteil: Man nimmt dem Minifier die Arbeit ab.

SCNR.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello,

hi,

Danke !

Da bekomme ich jetzt leider gar keine Ausgabe gezeigt. Wahrscheinlich wieder irgendein Schusselfehler drin, den ich einfach nicht finde

for ($x = 1; $x < $AnzahlFelder; $x++) {
		echo implode(" = ?, ",$feldliste[$x]);
	}

Unabhängig vom Fehler (siehe Dedlfix) ist es bei PHP besser, das foreach ()-Konstrukt zu benutzen. Sonst müsstest Du der Ordnung halber nämlich bei jedem Iterationsschritt prüfen, ob der angesprochene numerische Index vorhanden ist (je nach Herkunft des Arrays).

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber TS,

Unabhängig vom Fehler (siehe Dedlfix) ist es bei PHP besser, das foreach ()-Konstrukt zu benutzen. Sonst müsstest Du der Ordnung halber nämlich bei jedem Iterationsschritt prüfen, ob der angesprochene numerische Index vorhanden ist (je nach Herkunft des Arrays).

er will aber das erste Array-Element auslassen. Daher kann ich schon nachvollziehen, warum er eine for-Schleife gewählt hat. Um euch beiden aber gerecht zu werden schlage ich folgendes Konstrukt vor:

foreach ($feldliste as $key => $value) {
  /* wenn $key den Wert 0 hat,
   * wirkt das hier wie false,
   * womit das erste Element ausgelassen wird
   */
  if ($key) {
    // tu was
  }
}

Liebe Grüße

Felix Riesterer

[Gunnar Bittersmann]

@@Felix Riesterer

er will aber das erste Array-Element auslassen.

Will er das? Oder weiß er nicht, dass Arrayindizes bei 0 anfangen zu zählen?

Wer immer sich das ausgedacht hat, bekommt einen besonderen Platz in der Hölle.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Felix Riesterer]

Lieber Gunnar,

Will er das?

ja, das will er, weil im Index 0 der primary key steht (da COL1 die "ID" enthält), den er beim Schreiben nicht festlegen will, sondern dem auto_increment-Mechanismus überlassen möchte.

Oder weiß er nicht, dass Arrayindizes bei 0 anfangen zu zählen?

Das ist bestimmt nicht das Problem.

Wer immer sich das ausgedacht hat, bekommt einen besonderen Platz in der Hölle.

Ist das nicht reine Mathematik?

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo miteinander,

Oder weiß er nicht, dass Arrayindizes bei 0 anfangen zu zählen?

Wer immer sich das ausgedacht hat, bekommt einen besonderen Platz in der Hölle.

Ist das nicht reine Mathematik?

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

Live long and pros healthy,
 Martin

[Felix Riesterer]

Lieber Martin,

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?

der Ursprungspunkt hat die Koordinaten (0|0). Auch da fängt man mit der Null zu zählen an.

Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

Es ist die Frage, was man zählt und was der Zählindex ist. Das ist nicht dasselbe.

Liebe Grüße

Felix Riesterer

[TS]

Hello,

Oder weiß er nicht, dass Arrayindizes bei 0 anfangen zu > > Ist das nicht reine Mathematik?

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

Da fehlt jetzt aber mindestens ein Smiley.

Glück Auf
Tom vom Berg

[Der Martin]

Hallo,

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

Da fehlt jetzt aber mindestens ein Smiley.

wozu? Das würde suggerieren, dass diese ernst gemeinte Aussage einen humoristisch-ironischen Aspekt hätte. Hat sie aber nicht (dass im Originaltext ein "man" fehlt, wollen wir mal außer Acht lassen).

Live long and pros healthy,
 Martin

[TS]

Hello,

Hallo,

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

Das ist außerdem falsch. Man zählt nicht ab Null, sondern man indiziert ab Null. Das ist genau der Denkfehler, dem Viele auf den Leim gehen.

Da fehlt jetzt aber mindestens ein Smiley.

wozu? Das würde suggerieren, dass diese ernst gemeinte Aussage einen humoristisch-ironischen Aspekt hätte. Hat sie aber nicht (dass im Originaltext ein "man" fehlt, wollen wir mal außer Acht lassen).

Als mathematisch verbildetem Menschen macht die Aussage "Null ist eine natürliche Zahl" (Du suggerierst das so) eben steife Nackenhaare. Und das in einer Zeit, wo der Barbershop geschlossen hat ;-)

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Das ist außerdem falsch. Man zählt nicht ab Null, sondern man indiziert ab Null. Das ist genau der Denkfehler, dem Viele auf den Leim gehen.

Der Denkfehler war, an der Stelle einen Unterschied zu machen.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello,

@@TS

Das ist außerdem falsch. Man zählt nicht ab Null, sondern man indiziert ab Null. Das ist genau der Denkfehler, dem Viele auf den Leim gehen.

Der Denkfehler war, an der Stelle einen Unterschied zu machen.

Achso: wenn das Element mit dem Index 0 vorhanden ist, habe ich also 0 Elemente?

Und wid passt deine hiesige Aussage zu deiner anderen? Du verwirrst mich!

Hoffentlich bin ich nid auf ein Programm von Fif angewiesen :-p

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@TS

Das ist außerdem falsch. Man zählt nicht ab Null, sondern man indiziert ab Null. Das ist genau der Denkfehler, dem Viele auf den Leim gehen.

Der Denkfehler war, an der Stelle einen Unterschied zu machen.

Achso: wenn das Element mit dem Index 0 vorhanden ist, habe ich also 0 Elemente?

Nein. Es sollte kein Element mit dem Index 0 vorhanden sein. Weil es keinen Index 0 geben sollte.

Wenn das Element mit dem Index 1 vorhanden ist, hast du also 1 Element.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello,

@@TS

Das ist außerdem falsch. Man zählt nicht ab Null, sondern man indiziert ab Null. Das ist genau der Denkfehler, dem Viele auf den Leim gehen.

Der Denkfehler war, an der Stelle einen Unterschied zu machen.

Achso: wenn das Element mit dem Index 0 vorhanden ist, habe ich also 0 Elemente?

Nein. Es sollte kein Element mit dem Index 0 vorhanden sein. Weil es keinen Index 0 geben sollte.

Wenn das Element mit dem Index 1 vorhanden ist, hast du also 1 Element.

Bei Datenbanken ist das sogar meistens so ;-)

Glück Auf
Tom vom Berg

[Der Martin]

Hi,

Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

Das ist außerdem falsch. Man zählt nicht ab Null, sondern man indiziert ab Null. Das ist genau der Denkfehler, dem Viele auf den Leim gehen.

einerseits ist das richtig; andererseits zählt man auch ab Null: Was ist, wenn du die Anzahl von Elementen angeben willst, und *nichts da ist? Genau, der Zählwert (die Anzahl) ist Null.

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Als mathematisch verbildetem Menschen macht die Aussage "Null ist eine natürliche Zahl" (Du suggerierst das so) eben steife Nackenhaare.

Warum? Ich finde das selbstverständlich. Die heutige Mathematik wäre ohne die Null nicht denkbar.

Und das in einer Zeit, wo der Barbershop geschlossen hat ;-)

Naja. Ich hab's vor einer Woche tatsächlich geschafft, bei amazon eine preiswerte und sofort lieferbare Haarschneidemaschine zu erwischen. Bei der ersten Anwendung habe ich mich etwas verstümmelt: Wenn man den Scherkopf einmal zum Reinigen abnimmt und dann wieder aufsetzt, rastet er nicht in der Stellung ein, die er vorher hatte - sondern auf kürzester Schnittlänge 2mm! Jetzt weiß ich das auch. :-)
Inzwischen sind die viel zu kahlen Stellen schon wieder einigermaßen nachgewachsen.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Haarschneidemaschine

Spoilern oder nicht spoilern, das ist hier die Frage.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hallo Gunnar,

Haarschneidemaschine

Spoilern oder nicht spoilern, das ist hier die Frage.

ich weiß nicht, was du damit sagen möchtest.
Bilder will ich jedenfalls nicht veröffentlichen.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Bilder will ich jedenfalls nicht veröffentlichen.

Es ging hier nicht um dich.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Raketenkröner]

schon wieder einigermaßen nachgewachsen.

Ich dachte auch ein paar Jahre lang. Hm. Kurze Haare!

Dank der neuen Freundin Corona bin ich, rein frisurentechnisch bestrachtet, wieder auf dem besten Weg zum vorherigen Zustand.

Ich schätze, die Bilder der Europäer mit Coronalappen vor der Kauleiste und Coronafrisuren über dem Verschwörungstheorienspeicher werden jahrzehntelang in einem der Sender des ZDF wiederholt. (In die Endlosschleife zwischen "Geburtstrag, Heirat und Ableben im Bunker", "Panzer" und "Stalins Verbrechen" geklebt.) Also, falls es da überhaupt einen Mitarbeiter gibt, der die Anlagen bedienen kann.

[Der Martin]

n'Abend,

schon wieder einigermaßen nachgewachsen.

Ich dachte auch ein paar Jahre lang. Hm. Kurze Haare!

Dank der neuen Freundin Corona bin ich, rein frisurentechnisch bestrachtet, wieder auf dem besten Weg zum vorherigen Zustand.

mein Vermieter hat mir vor ein paar Tagen die Nebenkostenabrechnung zugeschickt (unterm Strich 10.80EU$ Rückerstattung). Witzig fand ich aber sein "PS": Ich fühle mich wieder wie 16. Das Benzin kann ich vom Taschengeld bezahlen, ich gehe nicht zum Frisör und habe dauernd Hausarrest.

Ich schätze, die Bilder der Europäer mit Coronalappen vor der Kauleiste und Coronafrisuren über dem Verschwörungstheorienspeicher werden jahrzehntelang in einem der Sender des ZDF wiederholt.

Was nicht überraschend wäre, weil eine Krise in dem Ausmaß und mit der Tragweite bisher beispiellos ist.

Btw: Angesichts der allgemeinen Gesichtsmaskenpflicht ab nächste Woche habe ich es tatsächlich geschafft, in der Apotheke im Ort noch sowas zu kriegen (Doppelpack für 3EU$). Eben mal probehalber angezogen frage ich mich: Wie kann ich als Brillenträger eigentlich verhindern, dass bei jedem Ausatmen die Brille beschlägt?

Live long and pros healthy,
 Martin

[Raketenkröner]

Wie kann ich als Brillenträger eigentlich verhindern, dass bei jedem Ausatmen die Brille beschlägt?

• Brille abnehmen
• Schauen, ob die Coronatarnvorrichtung (in dem Zustand können die Viren Dich rein theorethisch zwar anfallen, aber nicht erkennen!) einen Drahtbügel hat, der sich anpassen lässt, dass zwischen Nase, Wange und Tuch kein Spalt bleibt.

[Der Martin]

Hallo,

Wie kann ich als Brillenträger eigentlich verhindern, dass bei jedem Ausatmen die Brille beschlägt?

• Brille abnehmen

negativ. Dann kann ich auf 2m Entfernung nicht mehr Freund und Feind unterscheiden.

• Schauen, ob die Coronatarnvorrichtung (in dem Zustand können die Viren Dich rein theorethisch zwar anfallen, aber nicht erkennen!) einen Drahtbügel hat, der sich anpassen lässt, dass zwischen Nase, Wange und Tuch kein Spalt bleibt.

Negativ. Ist bei den Papiermasken, die ich in der Apotheke bekommen habe, nicht der Fall.

Live long and pros healthy,
 Martin

[Tabellenkalk]

Hallo,

negativ. Dann kann ich auf 2m Entfernung nicht mehr Freund und Feind unterscheiden.

Auf 2m Entfernung kann ich das Coronavirus auch mit Brille nicht erkennen...

Gruß
Kalk

[Raketenmedizinalprophet]

negativ. Dann kann ich auf 2m Entfernung nicht mehr Freund und Feind unterscheiden.

Auf 2m Entfernung kann ich das Coronavirus auch mit Brille nicht erkennen...

Kommt das nicht sehr auf den mit verkauften Stimmungsaufheller (und dessen Gebrauch) an?

[Raketenhumordezimierer]

Negativ. Ist bei den Papiermasken, die ich in der Apotheke bekommen habe, nicht der Fall.

Aha. Die 11 Millionen Ordnungsstrafenschutzmasken, welche ein Andreas Scheuer persönlich m Flughafen abgeholt hat, gehen jetzt nicht per Sonderzuteilung an die 55.000 „systemrelevanten“ Erben und Spitzenhöschenträgerbeamte sondern via Apotheke an den Plebs…

[Der Martin]

Hallo,

Negativ. Ist bei den Papiermasken, die ich in der Apotheke bekommen habe, nicht der Fall.

Aha. Die 11 Millionen Ordnungsstrafenschutzmasken, welche ein Andreas Scheuer persönlich m Flughafen abgeholt hat

ich habe ein paar Minuten nachgedacht, woher mir der Name Andreas Scheuer bekannt vorkam. Es wollte mir nicht einfallen. Dann habe ich den verlinkten Artikel gelesen. Ach ja, der Verkehrsminister. Anders als sein Amtsvorgänger Dobrindt ist der einfach noch nicht ausreichend mit blöden Bemerkungen und Entscheidungen aufgefallen.

gehen jetzt nicht per Sonderzuteilung an die 55.000 „systemrelevanten“ Erben und Spitzenhöschenträgerbeamte sondern via Apotheke an den Plebs…

Scheint so ... Für irgendwas muss das minderwertige Zeug ja noch gut sein.

Live long and pros healthy,
 Martin

[Raketenhumordezimierer]

Anders als sein Amtsvorgänger Dobrindt ist der einfach noch nicht ausreichend mit blöden Bemerkungen und Entscheidungen aufgefallen.

Da musste ich nachdenken. Das „noch“ in „noch nicht ausreichend“ gibt hier wohl den Ausschlag: Er ist ja trotz seiner blöden Bemerkungen und Entscheidungen tatsächlich noch im Amt.

Wahrscheinlich, weil wegen der Abstandsregeln kein neuer Minister vereidigt werden kann und die Juristen sich streiten, ob man den Amtseid mit Mundschutz ablegen kann - bevor man den nicht erfüllt.

[TS]

Hello,

Anders als sein Amtsvorgänger Dobrindt ist der einfach noch nicht ausreichend mit blöden Bemerkungen und Entscheidungen aufgefallen.

Da musste ich nachdenken. Das „noch“ in „noch nicht ausreichend“ gibt hier wohl den Ausschlag: Er ist ja trotz seiner blöden Bemerkungen und Entscheidungen tatsächlich noch im Amt.

Wahrscheinlich, weil wegen der Abstandsregeln kein neuer Minister vereidigt werden kann und die Juristen sich streiten, ob man den Amtseid mit Mundschutz ablegen kann - bevor man den nicht erfüllt.

Hat er den denn überhaupt schon vollzogen? ;-p

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@Der Martin

ich habe ein paar Minuten nachgedacht, woher mir der Name Andreas Scheuer bekannt vorkam. Es wollte mir nicht einfallen. Dann habe ich den verlinkten Artikel gelesen. Ach ja, der Verkehrsminister. Anders als sein Amtsvorgänger Dobrindt ist der einfach noch nicht ausreichend mit blöden Bemerkungen und Entscheidungen aufgefallen.

Hä??

Abermillionen von unseren Geldern in die PKW-Maut zu versenken war nicht ausreichend blöd?

Wenn man 1 Dobrindt als Maß für Inkompetenz ansetzt, liegt der Scheuer bei mindestens 100 Dobrindt.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello,

ich habe ein paar Minuten nachgedacht, woher mir der Name Andreas Scheuer bekannt vorkam. Es wollte mir nicht einfallen. Dann habe ich den verlinkten Artikel gelesen. Ach ja, der Verkehrsminister. Anders als sein Amtsvorgänger Dobrindt ist der einfach noch nicht ausreichend mit blöden Bemerkungen und Entscheidungen aufgefallen.

Hä??

Abermillionen von unseren Geldern in die PKW-Maut zu versenken war nicht ausreichend blöd?

Wenn man 1 Dobrindt als Maß für Inkompetenz ansetzt, liegt der Scheuer bei mindestens 100 Dobrindt.

Wird da ab Null oder ab Eins gezählt?

Glück Auf
Tom vom Berg

[Der Martin]

Moin,

ich habe ein paar Minuten nachgedacht, woher mir der Name Andreas Scheuer bekannt vorkam. Es wollte mir nicht einfallen. Dann habe ich den verlinkten Artikel gelesen. Ach ja, der Verkehrsminister. Anders als sein Amtsvorgänger Dobrindt ist der einfach noch nicht ausreichend mit blöden Bemerkungen und Entscheidungen aufgefallen.

Hä??

Abermillionen von unseren Geldern in die PKW-Maut zu versenken war nicht ausreichend blöd?

Moooment - war das nicht noch Dobrindts Erbe? Die PKW-Maut habe ich dem bisher in die Schuhe geschoben.

Hmm, der Scheuer ist ja schon zwei Jahre im Amt. Ich hätte jetzt gefühlsmäßig eher auf zwei Monate getippt. Na gut, dann habe ich anscheinend nicht mitbekommen, dass der Vorturner beim Verkehrsmysterium gewechselt hat.
Wozu auch, hat sich ja doch nichts geändert ...

Wenn man 1 Dobrindt als Maß für Inkompetenz ansetzt, liegt der Scheuer bei mindestens 100 Dobrindt.

Naja. Ich hätte den Wechselkurs auf nahezu 1:1 geschätzt.

Live long and pros healthy,
 Martin

[TS]

Hello,

Hmm, der Scheuer ist ja schon zwei Jahre im Amt. Ich hätte jetzt gefühlsmäßig eher auf zwei Monate getippt.

Sonst dürfte der doch noch nicht Roller fahren ;-p

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Abermillionen von unseren Geldern in die PKW-Maut zu versenken war nicht ausreichend blöd?

Anscheinend nicht. Wie blöd es auch war, was er in der Vergangenheit gemacht hat, der Scheuer schafft es, da noch einen draufzusetzen.

Wenn man 1 Dobrindt als Maß für Inkompetenz ansetzt, liegt der Scheuer bei mindestens 100 Dobrindt.

Ich erhöhe auf 1000.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[1unitedpower]

Als mathematisch verbildetem Menschen macht die Aussage "Null ist eine natürliche Zahl" (Du suggerierst das so) eben steife Nackenhaare.

Warum sollte es? Es gibt Definitionen der natürlichen Zahlen, die die Null einschließen, und welche die sie ausschließen. Beide Varianten sind weit verbreitet.

[Gunnar Bittersmann]

@@Der Martin

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

0, 1, 2, 3 – Willst du mir sagen, da wäre drei Lichter?

🔆 🔆 🔆 🔆

“There are four lights!” (Chain of Command)

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hallo,

@@Der Martin

ich frage mich dann oft: Ist die Null nicht die natürlichste Zahl überhaupt?
Da wundere ich mich eher, dass nicht in viel mehr Bereichen ab Null zählt.

0, 1, 2, 3 – Willst du mir sagen, da wäre drei Lichter?

natürlich - die Aufzählung beginnt ja mit 0, also kein Licht.

Live long and pros healthy,
 Martin

[TS]

Hello,

[...] Oder weiß er nicht, dass Arrayindizes bei 0 anfangen zu zählen?

Wer immer sich das ausgedacht hat, bekommt einen besonderen Platz in der Hölle.

Das ist historisch gewachsen. Als "Arrays" noch Arrays waren, also geschlossene Datenstrukturen gleichartiger Elemente im Speicher, da war das der Displacementindex (* Elementgröße) im Speicher. Elemente konnte man also direkt durch ihren Index und die Elementgröße adressieren.

Dass PHP daraus nun "verknüpfte Hashtables mit angeschlossenen Datenbereichen" daraus macht, ist zwar für die Praxis ganz hilfreich, hat im Hintergrund aber eine Menge Overhead zur Folge.

Glück Auf
Tom vom Berg

[Mitleser]

Dass PHP daraus nun "verknüpfte Hashtables mit angeschlossenen Datenbereichen" daraus macht, ist zwar für die Praxis ganz hilfreich, hat im Hintergrund aber eine Menge Overhead zur Folge.

Bleibt die Frage nach der Relevanz für die Praxis. Hast Du das mal nachvollziehbar gemessen?

[TS]

Hello,

Dass PHP daraus nun "verknüpfte Hashtables mit angeschlossenen Datenbereichen" daraus macht, ist zwar für die Praxis ganz hilfreich, hat im Hintergrund aber eine Menge Overhead zur Folge.

Bleibt die Frage nach der Relevanz für die Praxis. Hast Du das mal nachvollziehbar gemessen?

Dazu müsste man das System mal auf einen alten 8086 packen. :-)

Aber auch auf einem Raspi merkt man den Unterschied schon deutlich.
Gemessen habe ich das aber noch nicht. Und man sollte auch direktgestreute Strukturen nicht einfach mit Bäumen bzw. verketteten Hashtables (Listen) vergleichen. Das sind zwei Welten.

Glück Auf
Tom vom Berg

[Mitleser]

Dass PHP daraus nun "verknüpfte Hashtables mit angeschlossenen Datenbereichen" daraus macht, ist zwar für die Praxis ganz hilfreich, hat im Hintergrund aber eine Menge Overhead zur Folge.

Bleibt die Frage nach der Relevanz für die Praxis. Hast Du das mal nachvollziehbar gemessen?

Dazu müsste man das System mal auf einen alten 8086 packen. :-)

Hahah.

Aber auch auf einem Raspi merkt man den Unterschied schon deutlich.
Gemessen habe ich das aber noch nicht.

Ohne ein nachvollziehbares Messzenario bleibt es bei einer Mutmaßung. Punkt.

Theoretischer Overhead erzeigt sich in der Praxis oft als irrelevant. Wenn Du jetzt bei der Programmierung von hardwarenahen Treibern bist: mag sein. Aber die Frage nach der Praxisrelevanz der hier fraglichen Webentwicklung ist das Thema.

Du bleibst in der Bringschuld 😉

[TS]

Hello,

Theoretischer Overhead erzeigt sich in der Praxis oft als irrelevant. Wenn Du jetzt bei der Programmierung von hardwarenahen Treibern bist: mag sein. Aber die Frage nach der Praxisrelevanz der hier fraglichen Webentwicklung ist das Thema.

Dass gegenüber einem klassischen Array bei den in PHP genutzten Strukturen zusätzliche Maßnahmen notwendig sind, sollte Dir als Fachfrau/mann klar sein. Schau doch einfach mal in den Quellcode, wenn Du es genau wissen willst. Und zeig uns das dann bitte auch.

Du bleibst in der Bringschuld 😉

Dazu müsstest Du erst einmal erklären, wofür?
Was ist denn deine Wunschliste?

Glück Auf
Tom vom Berg

[Mitleser]

Du bleibst in der Bringschuld 😉

Dazu müsstest Du erst einmal erklären, wofür?
Was ist denn deine Wunschliste?

Datenstruktur mit z.B. 1000 Einträgen. Hardcodiert oder als SQL-Result. Egal. Dazu eine Messung der Verarbeitungsgeschwindigkeit. Praxisrelevant eben ;-)

[TS]

Hello,

Du bleibst in der Bringschuld 😉

Dazu müsstest Du erst einmal erklären, wofür?
Was ist denn deine Wunschliste?

Datenstruktur mit z.B. 1000 Einträgen. Hardcodiert oder als SQL-Result. Egal. Dazu eine Messung der Verarbeitungsgeschwindigkeit. Praxisrelevant eben ;-)

Ok. Damit es nicht nutzlos ist, könnte ich ja mal meine Minimum/Maximum-Ermittlung aus den Wetterdaten dazu benutzen, wenn Dir das als Beispiel reicht.

Die PHP-Array-Version wird nämlich inzwischen arg langsam.

Mal sehen, wann ich dazu komme. Ich vergesse es aber nicht!

Glück Auf
Tom vom Berg

[TS]

Hello,

Hello,

Du bleibst in der Bringschuld 😉

Dazu müsstest Du erst einmal erklären, wofür?
Was ist denn deine Wunschliste?

Datenstruktur mit z.B. 1000 Einträgen. Hardcodiert oder als SQL-Result. Egal. Dazu eine Messung der Verarbeitungsgeschwindigkeit. Praxisrelevant eben ;-)

Ok. Damit es nicht nutzlos ist, könnte ich ja mal meine Minimum/Maximum-Ermittlung aus den Wetterdaten dazu benutzen, wenn Dir das als Beispiel reicht.

Die PHP-Array-Version wird nämlich inzwischen arg langsam.

Mal sehen, wann ich dazu komme. Ich vergesse es aber nicht!

In der Array-Version habe ich nun beteits einigd Umbauten vorgenommen, um einen zumindest ähnlichen Ausgangszustand für den Vergleich erreichen zu können. Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht. Es scheint mit hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen.

Für meine Min/Max-Lösung werde ich das also nicht behalten, da meine erste Lösung auch toleranter war - da war keine Sortierung der Messdaten erforderlich.

Wie man nun eine weitgehend statische Struktur für die klassische Array-Variante in PHP nachbilden kann, weiß ich noch nicht. Es gibt da nur ein großes Stringfeld, das man als Array missbrauchen kann. Leider sind dafür auch wieder einige Stringoperationen pro Element notwendig, die ihrerseits wieder dynamische Speicherzuordnungen verwenden.

Einen fairen Vergleich zwischen statischer und dynamischer Datenhaltung kann es in PHP daher nicht geben.

Aber die Hoffnung stirbt schließlich zum Schluss.

Glück Auf
Tom vom Berg

[1unitedpower]

Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht.

Dann optimierst du möglicherweise an der falschen Stelle. Es gibt eine Faustregel die bessagt, dass ein Programm geschätzte 90% der Laufzeit in 10% des Codes verbringt. Es hilft also in der Regel recht wenig auf Verdacht zu optimieren, weil man dann mit hoher Wahrscheinlichkeit nur sehr kleine Potenziale ausschöpfen kann. Es ist viel effektiver auf Sicht zu fahren, und erstmal die Engpässe zu ermitteln und sich eine Übersicht der Lage zu verschaffen. Dafür gibt es extra Werkzeuge. xdebug hat bspw. auch einen Profiler integriert, damit kann man eine detaillierte Aufzeichnung des Laufzeitverhaltens erstellen. Betrachten und auswerten kann man die Aufzeichnungen dann mit KCachegrind. Wenn du dann den Engpass gefunden hast, dann weißt du auch, wo hohes Optimierungspotenzial liegt und kannst dann gezielt optimieren.

Es scheint mit hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen.

Meinst du copy-on-write? Das ist eine Perforamnce-Optimierung, sie macht Code in der eher Regel schneller als langsamer.

[TS]

Hello,

Die vermeintlichen Optimierungen haben aber bisher nur sehr wenig Vorteil gebracht.

Dann optimierst du möglicherweise an der falschen Stelle. Es gibt eine Faustregel die bessagt, dass ein Programm geschätzte 90% der Laufzeit in 10% des Codes verbringt. Es hilft also in der Regel recht wenig auf Verdacht zu optimieren, weil man dann mit hoher Wahrscheinlichkeit nur sehr kleine Potenziale ausschöpfen kann. Es ist viel effektiver auf Sicht zu fahren, und erstmal die Engpässe zu ermitteln und sich eine Übersicht der Lage zu verschaffen. Dafür gibt es extra Werkzeuge. xdebug hat bspw. auch einen Profiler integriert, damit kann man eine detaillierte Aufzeichnung des Laufzeitverhaltens erstellen. Betrachten und auswerten kann man die Aufzeichnungen dann mit KCachegrind. Wenn du dann den Engpass gefunden hast, dann weißt du auch, wo hohes Optimierungspotenzial liegt und kannst dann gezielt optimieren.

Vielen Dank für deine Unterstützung. Die verantwortliche Stelle habe ich schon gefunden und dort auch eingegriffen.

Es liegt hauptsächlich am Schreibzugriff - "copy-on-write" in den PHP-Arrays. Danke für die Erinnerungsstütze bezüglich der Bezeichnung.

Es scheint mir hauptsächlich an den Schreiboperationen zu liegen. Das "write on access" (hab die Bezeichnung leider vergessen) scheint da besonders zu bremsen.

Meinst du copy-on-write? Das ist eine Perforamnce-Optimierung, sie macht Code in der eher Regel schneller als langsamer.

Das stimmt, solange man eben nicht schreibend (ändernd) zugreift. In meinem Versuchsbeispiel sieht man das auch ganz deutlich. Der Aufbau der Grafikseite aus denselben z. Zt. ca. 60.000 Datensätzen geht in Nullkommanix. Die Berechnung der Min/Max-Werte und deren textliche Ausgabe dauert aber nach der

• alten Methode (Ausführungszeit: 5.1807448863983sec)
• nach der geänderten Methode(Ausführungszeit: 4.7937939167023sec)

Die alte Methode hat den Vorteil, dass die Datei nicht sortiert sein muss. Die neue arbeitet mit klassischem Gruppenwechsel. Beide laden zunächst die Datei mit file(). Das funktioniert überraschenderweise allerdings auch in Nullkommanix. Die grafischen Anzeigen nutzten auch file().

Wenn ich mehr getestet habe, schiebe ich die Codes noch hinterher.

Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt.

Und noch eine Bemerkung zum Schluss: ich wollte hier gar nichts "optimieren", bin nur gebeten worden, einen Unterschied zu ermitteln zwischen PHP-Arrays und klassischen statischen Arrays. Da es die in PHP eigentlich gar nicht offen zugänglich gibt für den Anwendungsprogrammierer, muss ich mir eben eine Krücke ausdenken.

Das Problem wird sein, dass ein String (Als classic-Array-Ersatz) aus 60.000 Datensätzen auch nicht in ein Datensegment passt und PHP da im Hintergrund ohnehin schon wieder basteln muss.

Alldings wird meine Ausgabevarable mit $out .= ... ja auch in allen Fällen in nahezu Nullzeit gefüllt und wieder gelesen Richtung Std-Out.

Glück Auf
Tom vom Berg

[Der Martin]

Hallo,

Es liegt hauptsächlich am Schreibzugriff - "copy-on-write" in den PHP-Arrays. Danke für die Erinnerungsstütze bezüglich der Bezeichnung.

was nicht wirklich überraschend ist: Der Kopiervorgang braucht etwas Zeit. Nicht viel, aber bei jedem ersten Schreiben auf ein Arrayelement ein bisschen.

Die Berechnung der Min/Max-Werte und deren textliche Ausgabe dauert aber nach der

• alten Methode (Ausführungszeit: 5.1807448863983sec)
• nach der geänderten Methode(Ausführungszeit: 4.7937939167023sec)

Also nahezu gleich lang. Hey, das sind nicht einmal 10% Unterschied, wird also einem durchschnittlichen Nutzer nicht auffallen.

Beide laden zunächst die Datei mit file(). Das funktioniert überraschenderweise allerdings auch in Nullkommanix.

Auch das finde ich nicht überraschend. Die PHP-Funktion file() ist in (mutmaßlich) sehr effizient geschriebenem C realisiert.

Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt.

Ich auch. Gespannt bin ich auch, ob sie dann wirklich praxistauglich ist, oder eher nur ein Proof of Concept.

Das Problem wird sein, dass ein String (Als classic-Array-Ersatz) aus 60.000 Datensätzen auch nicht in ein Datensegment passt und PHP da im Hintergrund ohnehin schon wieder basteln muss.

Nein. Denk dran, dass wir heute 32- oder 64-bit-Systeme haben. Die 64k-Segmentgrenzen von damals sind heute bedeutungslos. Heute kann eine Software mal eben so 48MB Speicherinhalt linear direkt adressieren (nur um eine Hausnummer zu nennen).

Alldings wird meine Ausgabevarable mit $out .= ... ja auch in allen Fällen in nahezu Nullzeit gefüllt und wieder gelesen Richtung Std-Out.

Was willst du damit andeuten?

Live long and pros healthy,
 Martin

[TS]

Hello,

Es liegt hauptsächlich am Schreibzugriff - "copy-on-write" in den PHP-Arrays. Danke für die Erinnerungsstütze bezüglich der Bezeichnung.

was nicht wirklich überraschend ist: Der Kopiervorgang braucht etwas Zeit. Nicht viel, aber bei jedem ersten Schreiben auf ein Arrayelement ein bisschen.

Klar, eben dynamische Speicherverwaltung mit all ihren indirekten Zugriffen.

Die Berechnung der Min/Max-Werte und deren textliche Ausgabe dauert aber nach der

• alten Methode (Ausführungszeit: 5.1807448863983sec)
• nach der geänderten Methode(Ausführungszeit: 4.7937939167023sec)

Das ist nur ein Indiz und der Umbau war auch nur notwendig, damit später für den eigentlichen Vergleich zumindest ähnliche Rahmenbedingungen möglich sind.

Also nahezu gleich lang. Hey, das sind nicht einmal 10% Unterschied, wird also einem durchschnittlichen Nutzer nicht auffallen.

Beide laden zunächst die Datei mit file(). Das funktioniert überraschenderweise allerdings auch in Nullkommanix.

Auch das finde ich nicht überraschend. Die PHP-Funktion file() ist in (mutmaßlich) sehr effizient geschriebenem C realisiert.

Gespannt bin ich auf die Stringvariante, die dem klassischen statischen Array dann am nächsten kommt.

Ich auch. Gespannt bin ich auch, ob sie dann wirklich praxistauglich ist, oder eher nur ein Proof of Concept.

Dass sie praxistauglich sein soll, habe ich nie behauptet. Allerdings wäre es vielleicht bei ausreichendem Unterschied ein Argument für die Einführung von statischen Speicherstrukturen in PHP.

Das Problem wird sein, dass ein String (Als classic-Array-Ersatz) aus 60.000 Datensätzen auch nicht in ein Datensegment passt und PHP da im Hintergrund ohnehin schon wieder basteln muss.

Nein. Denk dran, dass wir heute 32- oder 64-bit-Systeme haben. Die 64k-Segmentgrenzen von damals sind heute bedeutungslos. Heute kann eine Software mal eben so 48MB Speicherinhalt linear direkt adressieren (nur um eine Hausnummer zu nennen).

Das beruhigt mich.

Alldings wird meine Ausgabevarable mit $out .= ... ja auch in allen Fällen in nahezu Nullzeit gefüllt und wieder gelesen Richtung Std-Out.

Was willst du damit andeuten?

Das war deine Aussage zur Speichergrenze in meinen Worten, nur als Vermutung ausgedrückt ;-)

BTW: wenn ich meine Versuchslösung optimieren wollte, würde ich mit Caching arbeiten. Da sich die alten Werte im Messdatenpool schließlich nicht mehr ändern, kann man die Berechnungen getrost in kleineren Portionen (Teildateien, z. B. eine pro Woche) cachen und die dann nach Bedarf wieder zusammenkleben. Aber das war nicht die Aufgabe dieses Teilthreads.

Glück Auf
Tom vom Berg

[Mitleser]

Ich muss mal Folgendes (vielleicht) aus dem Zusammenhang reißen:

wenn ich meine Versuchslösung optimieren wollte, würde ich mit Caching arbeiten. Da sich die alten Werte im Messdatenpool schließlich nicht mehr ändern, kann man die Berechnungen getrost in kleineren Portionen (Teildateien, z. B. eine pro Woche) cachen und die dann nach Bedarf wieder zusammenkleben

Caching auf der Platte, in einer DB, Memcached...? Ja, kann sinnvoll sein.

Aber bei der Nummer mit dem Cache im Code / Hauptspeicher bin ich skeptisch. Das mag vor 20 Jahren noch sinnvoll gewesen sein. Heute eher nicht mehr so sehr. Die Compiler/Interpreter machen da mittlerweile verdammt gute Arbeit. Klar, man kann auch gegen die Wand coden, aber das war früher nicht anders.

Wie gesagt, hardwarenahe Sachen ausgenommen.

[Rolf B]

Hallo Mitleser,

was soll er denn da bringen? Eine PHP Implementierung mit 0 als Basisindex, und eine andere mit 1? Das wäre wohl etwas aufwändig...

Im gleichen PHP ein Array[1..1000] mit einem Array [0..999] zu vergleichen ist wohl witzlos. Wenn überhaupt, geht es ja um den Implementierungsunterschied von 0-basierenden und 1-basierenden Arrays. Und ja, natürlich, das 1-basierende Array braucht bei jeder Offset-Berechnung ein "-1", welches selbst zu 8086 Zeiten bereits kaum ins Gewicht gefallen sein dürfte (DEC AX).

Das stammt aus den Zeiten wo jedes Instruktionsbyte und jeder Ausführungstakt noch richtig teuer waren - aus den 60er Jahren. C war als Erbe von BCPL 0-basierend, im Gegensatz zu den damaligen "richtigen" Sprachen wie COBOL, PL/1 oder Fortran, die fix oder zumindest per Default 1-basierend waren.

Das ist eben der Unterschied, ob eine Sprache problemorientiert oder systemorientiert designed ist.

Ok, ja, PHP ist problemorientiert. Aber anders, als der Begriff das eigentlich meint...

Rolf

[TS]

Hello,

Ok, ja, PHP ist problemorientiert. Aber anders, als der Begriff das eigentlich meint...

Meinst Du damit etwa, dass PHP mehr Probleme bereitet, als es zu beseitigen hilft?

☆tztz☆

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@PHP-Neuling

Nachfrage in neuen Thread verschoben.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!