ASP.Net + jQuery + plugin jQuery + validation UpdatePanel + nyroModal - succès de tir sur chaque champ!

Question

J'ai un formulaire contenant une liste de champs d'entrée que l'utilisateur Remplit avec des prix (chiffres). J'ai mis leurs classes CSS à « nécessaire » et « numéro » de sorte que le plugin de validation jQuery les valide en conséquence. Tout ce qui fonctionne parfaitement bien. Les erreurs sont affichées lorsque chaque champ est soit pas un nombre ou la valeur est manquante etc.

Cette forme entière est en fait dans une fenêtre pop-up modèle nyroModal (plugin jQuery). Mais cela ne devrait pas d'importance, son juste un formulaire Web .aspx quel que soit. Dans ce cadre, je l'ai aussi utilisé un UpdatePanel et tout mettre dedans, parce que ma forme est essentiellement un processus étape 2. Il y a quelques étapes de base, l'utilisateur doit remplir sur la première page »du formulaire. Quand cela fonctionne et valide, je viens de masquer / afficher certains éléments dans le UpdatePanel pour montrer à l'utilisateur la « page » suivante de la forme, qui est tous les champs d'entrée de zone de texte de prix tel que décrit ci-dessus.

J'utilise un ImageButton comme point de déclenchement pour valider le formulaire. Par défaut, si vous laissez juste un ImageButton la façon dont il est, .Net se déclenche au large postback, postback AJAX dans mon cas, parce que sa se passe tout à l'intérieur d'un UpdatePanel. Ce qui encore une fois, est souhaitée. Je ne veux pas un postback complet laid pour des raisons évidentes.

Après beaucoup de lecture, il me fallait un moyen de joindre à PageRequestManager de .Net en javascript pour que je puisse intercepter quand .Net voulait faire un postback, sur la base si jQuery avait validé avec succès la forme ou non. Donc, ma logique dit: Par défaut, ne laissez pas postbacks, mais quand jQuery valide avec succès la forme, définir une variable qui dit que postbacks sont désormais autorisés, la prochaine fois postback essaie de se produire, il passera par. Et donc afficher le succès à l'utilisateur.

est une sorte de tout travail raisonnablement bien, mais il y a un dernier problème.

L'option de validation du plugin validation jQuery ({succès}) semble tirer à tort après validation est réussie sur chaque champ, et non la totalité du formulaire. C'est à dire. si j'entre un numéro dans une des champs de saisie des prix, cette option de succès feu et mettre ma variable cancelPostback false, ce qui signifie que la forme présente maintenant, même si elle n'a pas été validé, juste parce qu'un champ était valide. Je me serais attendu à ce validate ({succès}) option que le feu une fois que la totalité du formulaire a été validé.

Ai-je tort interprété ce, et en fait son faire ce que son supposé être? Si oui, comment puis-je configurer simplement ma variable cancelPostback true seulement lorsque le formulaire est validé ENTIÈRE?

tas de Merci pour toute idée ou tête haute.

Mon code jQuery pour mettre en œuvre la validation et intercepter également l'événement postback .Net est la suivante:

<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>

Answer 1

Je suggère regarder les options submitHandler et invalidHandler. L'un ou l'autre doit travailler pour ce que vous voulez. La meilleure façon, je pense, serait de permettre postbacks par défaut et définir la cancelPostback true dans le invalidHandler. Sinon, vous pouvez écrire votre propre submitHandler qui appelle __doPostBack directement et remplace la présentation par le ImageButton.

Answer 2

J'ai eu des problèmes avec votre solution car tous les navigateurs sauf pour IE ont tiré la fonction « onEachRequest » AVANT la fonction submitHandler () de validateur jQuery. Je suis venu avec une solution plus élégante qui annule simplement le postback si la validation échoue, plutôt que de compter sur une variable prédéfinie.

  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());
    }
  }

Answer 3

Merci tas tvanfosson pour l'aide rapide.

Mise à jour Ok:

Je suivais de plus en plus de liens et finalement trouvé la documentation de « succès ». La documentation de sa propre page d'accueil du plug-in est terrible et omet de nombreuses fonctionnalités clés :) Mais sur la page officielle jQuery son « meilleur ». L'option « succès » est censé tirer à chaque fois un champ individuel est validé avec succès. Alors, qui travaillait à la conception et j'ai été à tort en supposant qu'elle ne se déclenche que lorsque la forme entière était valide.

J'ai essayé votre idée invalidHandler. J'ai adoré cette idée. Une question que je me suis heurté était que, avant le code invalidHandler de postback du ImageButton serait encore toujours le feu en premier, il commencerait l'affichage arrière irait. Ainsi, le postback irait encore à venir, après cela, invalidHandler désactiverait futurs postbacks, ils ont tiré dans le mauvais ordre, malheureusement. Mais à part cela, il a montré tout autre signe d'être la solution parfaite.

Je suis ensuite allé dans l'autre sens à essayer la voie de submitHandler, à savoir l'inverse. Encore une fois, cela a souffert de quelques problèmes d'ordre, parce que le postback serait à nouveau le feu d'abord, mais être bloqué, submitHandler permettrait alors à l'avenir postbacks, mais il était déjà trop tard, donc ce postback a été manquée. Il faudrait à nouveau cliquer sur le bouton deux fois pour qu'il aille.

Alors la solution semi-kludgey finale, ce n'est pas trop mal pour être honnête, était:

J'ai changé cette ligne:             // Fixer la validation côté client au formulaire principal             . $ ( "# <% = Form1.ClientID%>") valider ({submitHandler: function () {PreventPostback = false; __doPostBack ( 'UpdatePanel1', '');}});

qui, comme vous pouvez le voir, la variable première bascule PreventPostback, mais se déclenche au large d'une nouvelle postback manuellement, parce que la première postback aurait déjà été bloqué et est mort au large. Donc, cet appel manuel __doPostBack assure qu'un nouveau postback se décocha en respectant la nouvelle valeur de PreventPostback.

J'ai enlevé les méthodes d'événements derrière les ImageButtons, et fait une nouvelle méthode dans le code côté serveur appelé « DoPostBackLogic () » qui est appelé uniquement lorsque la page est réaffecté, que je sais doit avoir été de cette logique de validation , parce que c'est le seul postback qui peut se produire sur ma forme. Puis tout de la peau / show / enregistrer la logique qui se passe là-dedans pour moi. Ce qui signifie que quand je fais appel manuellement le __doPostBack, je peux simplement utiliser l'ID de l'UpdatePanel sans se soucier de mimer un

etc ImageButton particulier.

De cette façon, il fonctionne parfaitement. Postbacks sont désactivées par défaut, et lorsque le formulaire est valide, postbacks sont alors autorisés, mais un postback est alors déclenché manuellement afin que la nouvelle valeur prend effet.

C'est donc essentiellement votre deuxième solution, grâce encore une fois pour l'écoute et le partage! :)