Validieren | Absenden einer Form verhindern?

  • Finden kann ich gerade auch nix.
    Sieh mal nach, ob bei dem, was Du per Ajax zurückbekommst, das hier wenigsten mit dabei ist:
    (in etwa)
    {"login":true,"error":""}
    Das wäre nämlich das Array (json_encode´d)


    Mit den includes (config ect) kommt immer darauf an was darin passiert.
    Wenn es zB nur 10 Zeilen sind, dann wäre es ja keine Ressourcenverschwendung.


    Das mit dem switch sollte funktionieren.

  • Ähm, muss das denn mit dem json dann per console.log ausgegeben werden, also so?


    oder muss das bei data so mit rein, also data: {"login":true,"error":""}, ich denke mal nicht oder? :D
    Naja, bei dem console.log kriege ich ausgegeben:

    Code
    Object { login: true, error: "" }



    Zu den Einstellungen:

    Mehr als 15 Einstellungen sind es auf gar keinen Fall aber ist es nicht trotzdem eher unnötig die einer Seite mitzugeben, die dafür nie Verwendung hat?
    Vielleicht füge ich demnächst auch noch ein paar Einstellungen hinzu und dann wären es schon knapp 20, lohnt sich das also, das so zu machen?


    Man müsste dann aber ja noch überprüfen, um welche Seite es sich dann wirklich handelt, damit man dann ja im Backend nicht die index Datei mitliefert, korrekt?


    Achja und wo hatte ich kein break?
    Oder müsste da hinter das include bei if($site == 'backend') include ... ein break hinter?
    Eigentlich dürfte der doch nicht in den else Zweig reinspringen?

  • Also hier mal wie ich das JQ schreiben würde..
    Ich frage mich wo die Daten die in das Form eingegeben wurden an's PHP übergeben werden (der Parameter 'data' fahlt? oO )
    Naja wie auch immer:

  • Ich habe das jetzt mal so abgeändert, wie du es geschrieben hast aber es ändert sich nichts.


    Werden die Daten dann auch nicht durch die Felder automatisch mitgegeben oder muss man das auch extra machen? Den PHP Teil poste ich jetzt aber hier nicht noch einmal, denn kann man ja auch schließlich ein wenig weiter oben finden. Es hat sich ja auch zudem nichts daran geändert.


    Heißt das denn dann, das ajax da gar nicht reinkommt? Die Daten werden doch dann auch mit dem Form Submit übergeben oder liege ich da jetzt mal wirklich komplett falschß Ich würde die Sachen ja dann weiterhin gerne einfach mit $_POST["User"] testen.

  • Also könnte ich dann mit serializeArray() wie gewohnt auf die Felder zugreifen? Ich will ja, das er dann auch hier reinhüpft:


    Ich habe das jetzt jedenfalls mit dem serializeArray hinzugefügt und auch mal wie du ein $('body').append(data); gemacht aber dabei wird die bei mir meine ganze HTML Seite dupliziert und an die HTML Seite oder an meinen anderen Bereich angehangen. Derzeit scheint data mit meiner Seite gefüllt zu sein, anstatt mit den Daten wie login und error ....

  • Ja ganau, kannst ganz normal damit arbeiten..


    Hä, also das ist komisch. Kannst du mal dein php script zeigen?


    Also ich würde die 'login.php' datei so aufbauen:

    Code
    Daten validieren
            |
    Fehler speichern
        |         |
    AJAX Param    Normaler Aufruf
          |               |
      echo JSON       header() weiterleitung
  • So habe ich das ganze ja auch gemacht. ;)
    Ich hatte den PHP Teil zwar schon auf der letzten Seite mit eingebracht aber ist ja auch egal, dann muss man auch nicht immer eine Seite nebenbei aufhaben, also hier:


    Bitte das mit dem md5 ignorieren, das ändere ich sobald das mit dem JS Teil funktioniert. Ich muss mich da dann auch erst einmal noch ein wenig einlesen.
    Könnte sich auch noch einmal jemand meinen Beitrag (21) anschauen. Da hatte ich ja noch eine Frage wegen der Einstellungsdatei und dem Überprüfen der aktuellen Seite. ;)

  • Hier kannst du dich einlesen.. Tutorial Einfache Datenbank basierte Benutzerverwaltung (Login/Logout/Registrierung)


    Mach doch mal kein .append() und schau in die Konsole was du denn zurückbekommst von deinem script beim AJAX Request.
    Ich denke es liegt hier ran

    PHP: 108
    header("Location: index.php?site=backend");


    Und schreibe vorallem allgemein so: (Dann passieren solche Fehler nicht..)

  • Ja, die Seite kenne ich schon und du und cotton habt ja auch schon einmal auf einen anderen Thread verwiesen, allerdings ein wenig weiter vorne aber trotzdem danke, werde ich mir auf jeden Fall anschauen, vor allem da mich das Thema "Sicherheit" auch sehr interessiert.


    Übrigens hat es so leider auch nicht funktioniert aber ich habe mal einfach so hinter dem else von isset($_POST["Login"]) ein echo gesetzt und wie es scheint läuft der ajax Request da gar nicht erst rein aber in die Session kommt er seltsamerweise rein?


    Daraufhin habe ich dann mal ein or isset($_GET["ajaxLogin"]) hinzugefügt und jetzt funktioniert es auch und bei den Rückgabedaten steht dann:

    Code
    "Rückgabedaten:"
    "{"login":true,"error":""}"


    und bei einer falschen Eingabe:

    Code
    "Rückgabedaten:" 
    "{"login":false,"error":"Der Benutzername oder das Passwort ist oder sind falsch!"}"


    aber wieso kennt er da den Login Button nicht? Zwar funktioniert es jetzt so aber das würde ich schon gerne wissen. ;)


    Normalerweise sollte man ja auch nicht extra 4 mal prüfen müssen, ob der ajaxLogin auch wirklich gesetzt ist. Ich hatte ja auch hinter jedem header und hinter jedem json echo ein exit aber das dann immer die komplette Seite als Rückgabe da war kam mir schon komisch vor und es lag wie gesagt an dem isset($_POST["Login"]). Der else Zweig ist ja nur:

    HTML
    $smarty->display('templates/backend-login.tpl');


    und dadurch wird dann halt die ganze Form ausgegeben.
    Jetzt fehlt auch eigentlich nur noch das mit der Weiterleitung. Bei js ist funktioniert das ja mit window.location.replace("url ...") oder? Da braucht man dann aber kein exit oder so? Er scheint aber irgendwie auch noch nicht in diesen Zweig mit dem if(data && data["login"] usw) reinzulaufen.


    Ich habe nämlich auch mal ein console.log in den Teil mit dem

    JavaScript
    if(data && data["login"] usw)


    geschrieben aber da kommt dann nichts in der Konsole.
    Daraufhin habe ich das auch mal unter dem console.log(data) eingefügt:

    JavaScript
    var test = data["login"];
    var test2 = data["login"] === true;
    
    console.log("1: " + test + " 2: " + test2);


    und dann steht bei mir in der Konsole insgesamt das hier:

    Code
    "Rückgabedaten:"
    "{"login":false,"error":"Der Benutzername oder das Passwort ist oder sind falsch!"}"
    "1: undefined 2: false"


    oder bei richtiger Eingabe:

    Code
    "Rückgabedaten:"
    "{"login":true,"error":""}"
    "1: undefined 2: false"


    Also stimmt ja irgendwas mit diesem Vergleich nicht. Wie kann etwas überhaupt undefined und false sein o.O? Müsste das dann nicht jeweils eher beides undefined sein?


    Achja, ist das mit nicht auch bei dem else so falsch? Müsste das nicht so sein, also mit jeweils einer geschweiften Klammer weniger? JS meckert zwar nicht rum aber müsste das nicht so wie hier sein oder liege ich da jetzt falsch?

  • Es gibt auch kein 'data["login"]', du bekommst ein JSON String zurück, den musst du mit $.parseJSON zu einem Objekt machen und kannst dann via objectVarName.login auf den Wert von login zugreifen


    Dieses Konstrukt 'else if' gibt es nicht in JS. Du kannst höchstens ein 'if' in dein 'else' stecken, du machst hier genau die Eigenschaft zu nutze, die erlaubt auch ohne klammern zu schreiben.. da gehören theoretisch eine klammer nach dem 'else' und eine nach dem 'if' hin..


    Wieso schreibst du eigentlich immer die öffnenden Klammern in eine extra Zeile? Das pusht den Code voll unnötig in die Länge..? ^^


  • Mhm, die Javascript Syntax ist halt noch nicht so meins aber danke für den Hinweis.


    Jetzt funktioniert das ganze auch übrigens (endlich ;)), danke für die Hilfe.
    Das mit dem $("#footer").before(data.error); habe ich auch sowieso jetzt mal geändert. Ich habe dafür jetzt einen extra div dafür angelegt, wo dann die ganzen Meldung angezeigt werden. Zudem hätte man auch sonst das Problem, das sich die Meldung stapeln.


    Zu der Sache mit den Klammern. Ich setze diese immer auf eine neue Zeile, weil ich mit Java bzw. C# angefangen bin und da war das ja auch mehr oder weniger eine Konvention, wobei das natürlich auch nicht jeder Entwickler oder jedes Team so gemacht hat / macht. Bei C/C++ und JS sehe ich das auch viel öfter, das die Klammern auf die selbe Zeile gesetzt werden aber letzendlich ist es doch eh nur wichtig, das man konsistent bleibt, bzw. das Team das an einem Projekt arbeitet auch diese Konsistenz beibehält. Zeile sparen hin oder her.


    Jetzt bleibt eigentlich nur noch das mit dem Beitrag 22, danke noch einmal. :thumbup:

  • Dieses Konstrukt 'else if' gibt es nicht in JS.


    Sehr wohl gibt es dieses Konstrukt, es ist das Äquivalent zu PHP's elseif und findet Anwendung in beispielsweise C, C#, C++, Java und anderen Programmiersprachen.


    Die Funktionalität lässt sich hier feststellen: Codepen:gbVPGz


    Ergibt sich auch daraus, dass die Klammern { } optional sind, wenn nur ein Befehl folgt, also in diesem Fall if als ein Befehl nach else.


    Umbrüche vor Befehlsblöcken sind halt Geschmackssache. Ich finde das ist auch immer abhängig von der Sprache. In C#, C++ und Java arbeite ich gerne mit Absätzen vor der Klammer, in Javascript eher weniger, in Zukunft aber wohl wieder mehr denn ich finde das absolut förderlich für die Lesbarkeit; Wenn ich den Beginn und das Ende eines Blockes in der selben Spalte habe, kann ich die Klasse/Funktion/Kontrollstruktur wesentlich schneller von anderen abgrenzen, als wenn die beiden in verschiedenen Spalten stehen.


    Es bleibt Geschmackssache, dem Interpreter wäre es auch recht wenn alles in einer Zeile stünde und Befehle nur durch das Semikolon getrennt würden. Für die Lesbarkeit und die Präsentation im Forum sind beide Wege (Mit oder ohne Umbruch vor der {-Klammer) geeignet. Code in die Länge ziehen ist doch kein Problem, wenn man die Dinge wunderbar voneinander unterscheiden kann.


    Oder ist @wolf's Monitor zu klein? :D

  • Also gut, wie schon gesagt ist es doch einfach die Möglichkeit ohne klammern zu arbeiten deswegen ein elseif zu 'simulieren' aber es ist (zumindest interpretiert) eine else klammer und darin ein if? -seh ich das richtig? :D
    Das es funktioniert ahbe ich nicht angezweifelt oO


    Und ja Basi, mein Bildschirm ist zu klein und außerdem sind das immerhin x Zeilen weniger Code die geparst oder übertragen werden müssen.. stimmts? ^^ (ich möchte nicht sagen das die paar bytes das laden der Website krass verlangsamen aber kleinfieh macht eben doch Mist :D )

  • Dieses Konstrukt 'else if' gibt es nicht in JS.


    Nach dieser Aussage ging ich davon aus, du meintest es funktioniere nicht. :D


    Es ist genau anders herum, "else if" simuliert nicht "elseif" sondern "elseif" simuliert "else if", das Keyword "elseif" habe ich bisher nur bei PHP angetroffen.
    Und ja, natürlich ist es (wie bereits erwähnt) nur die Kurzform ohne Klammer:


    Dies...

    JavaScript
    if(Bedingung){
        // Code
    }
    else {
        if(Bedingung2){
            // Anderer Code
        }
    }


    ...entspricht dem:

    JavaScript
    if(Bedingung){
        // Code
    }
    else 
        if(Bedingung2){
            // Anderer Code
        }


    Bei der Dateigröße liegt es im Sonderfall Web-Entwicklung eigentlich nur an der Übertragung zum Nutzer, dass man an ihr spart. Dafür gibt es allerdings auch Software die vorab unwichtige Leerzeichen und -zeilen entfernt. Einem Interpreter ist das Wurst, der erkennt nicht Zeilen sondern Befehle. (Was nicht bedeutet das eine Zeile mehr die selbe Zeit beansprucht wie eine weniger, das ist aber lächerlich gering :rolleyes: )

  • Ich habe das nun ein mal etwas ausprobiert und das Ergebnis schockiert mich auf eine Art und Weise die ich nicht für möglich hielt :huh:


    Ich habe eine Variable 10.000 mal hochzählen lassen:



    Im ersten Fall habe ich die Befehle direkt hintereinander geschrieben (abgesehen von einem Leerzeichen):


    JavaScript
    i += 1; i += 1; i += 1; [...]


    Im zweiten Fall habe ich auf jeden Befehl 4 Leerzeilen folgen lassen, somit kam ich auf insgesamt 50.000 Zeilen:



    Das Ergebnis ist deutlich anders als erwartet ausgefallen. Die Variante mit je 4 Leerzeilen ist im Durchschnitt satte 24% schneller als der dicke Einzeiler, welcher mit 52% kleinerer Dateigröße jedoch besser bei der Übertragung abschneidet:


    Code
    +--------------+-------------------------------------------------------------------------------+---------+----------+
     | no. of lines |                             10 iterations, result in seconds                  | average | filesize |
     +--------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+---------+----------+
     |       50.000 | 0.021 | 0.025 | 0.022 | 0.023 | 0.026 | 0.020 | 0.020 | 0.024 | 0.022 | 0.024 | ø 0,022 | 166  KB  | 
     +--------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+---------+----------+
     |            1 | 0.030 | 0.031 | 0.026 | 0.032 | 0.024 | 0.030 | 0.026 | 0.029 | 0.030 | 0.031 | ø 0,029 | 78.1 KB  |
     +--------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+---------+----------+
  • Das ist (sehr) interessant, wo doch JS code oft minimized wird.
    Stellt sich mir die Frage: passiert das bei "allen" Browsern?
    denke mal, dass beim parsen Zeilenweise vorgegangen wird. Also pro Zeile eine ~"Einheit".
    Und bei eine riesen Zeile wird die "Einheit" dementsprechend riesig und schwerfällig.

  • Ja an so etwas ähnliches habe ich auch gedacht. Interessant zu erwähnen ist übrigens auch Folgendes:


    Ich habe aus Neugier den Code in eine Schleife verpackt und 20 Iterationen gemessen, die erste dauerte immer entsprechend der Tabelle 2 Beiträge höher, die restlichen 19 waren immer um die 0,001 Sekunden, also offenbar gecached.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!