Frage

Ich habe ein Formular eine Liste der Eingabefelder enthält, die der Benutzer mit Preisen (Zahlen) auffüllt. Ich habe ihre CSS-Klassen auf „erforderlich“ und „Zahl“, so dass die jQuery Validierung Plugin sie entsprechend validiert. All das funktioniert sehr gut. Die Fehler werden angezeigt, wenn jedes Feld ist entweder keine Zahl oder der Wert fehlt etc.

Die gesamte Form ist tatsächlich in einem nyroModal (jQuery-Plugin) Modell Popup-Fenster. Aber das sollte keine Rolle spielen, es ist nur eine ASPX Webformular unabhängig. Innerhalb dass habe ich auch verwendet, ein Update und legte alles hinein, denn meine Form im Wesentlichen ein 2-Stufen-Prozess. Es gibt einige grundlegende Schritte der Benutzer auf der ersten ‚Seite‘ des Formulars ausfüllen müssen. Wenn das bestätigt und arbeitet, ich habe gerade verstecken / einige Elemente innerhalb der Update zeigen dem Benutzer die nächste ‚Seite‘ des Formulars zu zeigen, die die Eingangspreis Textbox alle Felder wie oben beschrieben ist.

ich einen Image als Triggerpunkt bin mit dem Formular für die Validierung. Standardmäßig, wenn Sie nur ein Image den Weg verlassen es ist, wird .Net ein Postback, AJAX Postbacks in meinem Fall abfeuern, weil es ist alles in einem Update passiert. Die wiederum erwünscht ist. Ich habe nicht ein hässlichen vollen Postbacks aus offensichtlichen Gründen will.

Nach vielen Lesen, brauchte ich einen Weg zu .Net Pagerequestmanagern in Javascript zu befestigen, so dass ich abfangen konnte, wenn .Net ein Postback tun wollte, basierend auf, wenn jQuery das Formular erfolgreich oder nicht validiert hatte. Also meine Logik sagt: In der Standardeinstellung nicht Postbacks erlauben, aber wenn jQuery das Formular erfolgreich validiert, eine Variable, die besagen, dass Postbacks ist jetzt erlaubt, dann das nächste Mal ein Postbacks zu passieren versucht, wird es gehen. Und deshalb Erfolg für den Benutzer angezeigt werden.

Dies ist eine Art alles recht gut funktioniert, aber es gibt ein letztes Problem.

Die Validate-jQuery Validierung Plugin ({Erfolg}) Option scheint falsch zu feuern nach der Validierung auf jedem einzelnen Feld erfolgreich ist, nicht die gesamte Form. D. h wenn ich eine Zahl in einem der Preiseingabefelder, dieser Erfolg Option meine cancelPostback eingeben Variable auf false wird ausgelöst, und gesetzt, was wiederum bedeutet, dass die Form jetzt einreicht, obwohl es nicht validiert worden ist, nur weil ein Feld war gültig. Ich würde dieses Validate erwartet ({Erfolg}) Option, um nur Feuer, sobald das gesamte Formular validiert wurde.

Habe ich das falsch interpretiert, und in der Tat seine tun, was seine sein soll? Wenn ja, wie kann ich einfach nur meine cancelPostback Variable auf true gesetzt, wenn das gesamte Formular validiert?

Dankhaufen für jede Einsicht oder leitet.

Mein jQuery-Code die Validierung und auch abfangen des .Net Postbackereignisses zu implementieren, ist wie folgt:

<script type="text/javascript">
    // By default, don't allow Postback until we've successfully validated our form on the client-side.
    var cancelPostback=true;

    // Every single time the page loads, including every single AJAX partial postback
    function pageLoad()
    {
        // Reset the value to say that "We don't allow Postbacks at this stage"..
        cancelPostback=true;

        // Attach client-side validation to the main form
        $("#<%= form1.ClientID %>").validate({ success: function() { alert('validation succeeded!'); cancelPostback = false; } });

        // Grab a reference to the Page Request Manager
        var prm = Sys.WebForms.PageRequestManager.getInstance();
        prm.add_initializeRequest(onEachRequest);

        alert("Page Load");
    }

    // Our own custom method to be attached to each new/future page request..
    function onEachRequest(sender, args)
    {
        alert("About to cancel? " + cancelPostback);
        // Check to see if we need to Cancel this Postback based on Conditional Logic within this page..
        args.set_cancel(cancelPostback);
    }
</script>
War es hilfreich?

Lösung

Ich würde vorschlagen, an den submitHandler und invalidHandler Optionen. Der eine oder andere sollte arbeiten, was Sie wollen. Der beste Weg, glaube ich, wäre Postbacks standardmäßig zu ermöglichen und die cancelPostback auf true in dem invalidHandler gesetzt. Alternativ können Sie Ihre eigenen submitHandler schreiben, die __doPostBack direkt aufruft und ersetzt die Vorlage über das Image.

Andere Tipps

hatte ich Probleme mit Ihrer Lösung, da alle Browser außer für IE die feuerten „onEachRequest“ Funktion vor dem submitHandler () Funktion des jQuery-Validator. Ich kam mit einer eleganteren Lösung, die einfach das Postback abgebrochen, wenn die Validierung fehlschlägt, anstatt sich auf eine voreingestellte Variable zu verlassen.

  Sys.Application.add_init(function() {
    var prm = Sys.WebForms.PageRequestManager.getInstance();
    prm.add_initializeRequest(onEachRequest);
  }); 

  function onEachRequest(sender, args) {
    if (args.get_postBackElement().id == <%= [YourSubmitButton].ClientID %>) {
      args.set_cancel(!$('#aspnetForm').valid());
    }
  }

Dank Haufen tvanfosson für die schnelle Hilfe.

Ok Update:

folgte ich mehr und mehr Links und fand schließlich in der Dokumentation „Erfolg“. Die Dokumentation auf der eigenen Homepage des Plugins ist schrecklich und lässt viele der wichtigsten Features :) Aber auf der offiziellen jQuery Seite seiner „besser“. Der „Erfolg“ Option ist gemeint, jedes einzelne Mal, wenn ein einzelnes Feld Feuer erfolgreich validiert. So dass durch Design zu arbeiten und ich wurde zu Unrecht davon aus, es würde nur ausgelöst, wenn die gesamte Form gültig war.

Ich habe versucht, Ihre invalidHandler Idee. Ich war begeistert von dieser Idee. Ein Problem, ich kam gegen war, dass das Image des Postbacks würde immer noch zuerst abfeuern, so dass es anfangen würde Entsendung zurück, bevor der invalidHandler Code laufen würde. So ist die Postbacks noch weiter gehen würde, dann danach, würde invalidHandler Zukunft Postbacks deaktivieren, wurden sie leider in der falschen Reihenfolge zu schießen. Aber abgesehen davon, zeigte, dass es alle anderen Zeichen die perfekte Lösung zu sein.

Ich ging dann in die andere Richtung die submitHandler Weise, das heißt die inverse versuchen. Auch litt dies von einigen, um Probleme, weil wieder die Postbacks erste Feuer würde, aber blockiert werden, dann würde submitHandler Zukunft Postbacks erlauben, aber es war schon zu spät, so wurde dieser Postbacks verpasst. Sie müßten die Taste erneut zweimal klicken, um es zu gehen zu erhalten.

So die letzten Halb kludgey Lösung, das ist nicht so schlimm, ehrlich zu sein, war:

Ich änderte diese Zeile:             // Attach clientseitigen Validierung der Hauptform             . $ ( "# <% = Form1.ClientID%>") validieren ({submitHandler: function () {PreventPostback = false; __doPostBack ( 'UpdatePanel1', '');}});

Welche wie Sie sehen können, zunächst die PreventPostback Variable schaltet, aber dann feuert manuell einen neuen Postbacks, da die ersten Postbacks bereits gesperrt worden wären und abgestorben. So dieses Handbuch __doPostBack Aufruf stellt sicher, dass eine neue Postbacks wird den neuen Wert von PreventPostback respektieren feuert.

Ich entfernte die Ereignismethoden hinter der ImageButtons und machte eine neue Methode in dem Server-Seite Code namens „DoPostBackLogic ()“, die nur aufgerufen, wenn die Seite zurück gebucht wird, das weiß ich aus dieser Validierungslogik gewesen sein muss , denn das ist die einzige Postbacks ist, die auf meiner Form geschehen kann. Dann werden alle der hide / show / speichern Logik für mich da drin passiert. Was bedeutet, wenn ich manuell die __doPostBack nenne, habe ich einfach die ID des Update verwenden können und sich keine Sorgen über einen bestimmten Image etc nachahmt.

So ist es perfekt funktioniert. Postbacks sind standardmäßig deaktiviert, und wenn das Formular gültig ist, sind Postbacks dann erlaubt, aber ein Postbacks wird dann manuell ausgelöst, so dass der neue Wert wirksam wird.

Also das im Wesentlichen Ihre zweite Lösung ist, noch einmal vielen Dank für das Hören und teilen! :)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top