nicht angemeldet
Moin Sven,
- Das JS gehört zumindest in den Kopf der Seite, idealiter in eine eigene .js Datei
Nein, Javascript ist überall in der Seite erlaubt - entscheidend ist nur, dass zum Zeitpunkt der Codeausführung die beabsichtigten Seitenelemente schon existieren (also z.B. nicht erst später im Quelltext stehen und so beim Seitenladen noch nicht verfügbar wären).
In der dargestellten Situation ist alles geladen und wartet auf Benutzerinteraktion - da ist die Position des Javascripts absolut irrelevant.
von nicht erlaubt habe ich auch nichts gesagt. Und auch nicht, dass deswegen das Script nicht funktioniert. Meiner Meinung nach bieten ausgelagerte Script aber den klaren Vorteil schnellerer, kontollierterer updates. Außerdem befinden wir uns doch im Zeitalter der Trennung von Inhalten einerseits sowie Formatierungen und Funktionalitäten andererseits. Damit stehe ich auch nicht alleine da (var ich += Peter-Paul Koch)
- »» if (isset($_POST['update'])) {
Das ist PHP Code und hat in einer JS Funktion nichts zu suchen (es sei denn innerhalb von <?php ?>, aber auch das nur, wenn an der Stelle serverseitig Daten ausgegeben oder verarbeitet werden sollen (hier nicht der Fall)Das ist offenbar der zentrale Denkfehler von Chris.
Völlige Zustimmung. Wäre ihm vielleicht nicht passiert, hätte er eine .js Datei vor sich gehabt. Vieleicht aber doch ;-)
- Mehrere submits nix gut. Deine Funktion wird bei Click auf beide ausgeführt. Dein Formular wird bei Click auf den normalen submit aber niemals abgeschickt (wenn das Script funktionieren würde, wegen return false)
Jedes Formular darf so viele Submit-Buttons haben, wie in den Browser passen. Das ist nicht das Problem. Entscheidend ist, dass man berücksichtigt, dass nur der geklickte Button ans name=value-Paar mit den Formulardaten mitgeschickt wird.
Enter Taste? Name/ value Paare? Siehe unten...
Auf Javascript-Seite hingegen gibts noch keine Formulardaten. Wenn man da den "richtigen" Button isolieren will, empfiehlt sich, das mit onclick direkt im Button zu tun - eventuell angereichert mit einer weiteren Verarbeitung im onsubmit. In diesem Fall aber würde es vollkommen ausreichen, das Click-Event des einen Buttons durch "return false" abzubrechen, um den Submit-Vorgang zu unterbrechen.
Genau das hab ich ihm doch vorgeschlagen(?). return false reicht aber wohl nicht, wenn der eine button ganz normal absenden soll und der andere mit dem confirm Zwischenschritt (so hab ich ihn verstanden)?
Lösung: Nimm anstatt des zweiten submits einen <button></button>, kannst du ja genauso aussehen lassen wie den anderen submit.
Diese Idee ändert nichts am javascriptseitigen Verhalten der Schaltflächen - aber (und das ist gravierend) es werden die Unzulänglichkeiten des IE mit diesem Formularelement eingebaut. Der IE sendet das Falsche in den Formulardaten, er baut ALLE Buttons in die Daten ein, nicht nur den geklickten, er sendet den HTML-Inhalt innerhalb von <button>, nicht den definierten value, etc... Deshalb ist von <button> zum jetzigen Stand der Technik nur abzuraten.
Mit den Unzulänglichkeiten hast du natürlich Recht, aber wenn der zweite button lediglich das confirm aufrufen soll und serverseitig keine name/value Paare für submit unterschieden bzw. verarbeitet werden (konnte ich in der Frage nicht erkennen), ist es doch irrelevant, was übergeben wird. Und Thema mehrere submits/ Enter Taste: Hab's jetzt nicht nochmal nachgelesen: Übergeben IEs bei mehreren submits nicht gar kein name/value Paar und der FF nimmt immer den ersten submit, den er findet? Kann ich -auch falls doch eine serverseitige Verarbeitung stattfinden soll- jetzt keinen riesigen Vorteil entdecken.
Das geht auch ohne <button>...
Stimmt :)
Gruß
Antipitch