ASP --doPostBack

[p10tyr]

Sorry to inundate you with issues from legacy systems, but as you can see they are still in use.

The problem off course is the daft way ASP triggers post backs, from "a" links or other types. Obviously that is out of HTML specification now a days... but bad smells can linger around for a long time :( So when I click save it shows nag screen instead of saving as expected.

Fires this garbage... (which I don't know how to amend and don't want to waste my life trying to find out too, since it gets injected by ASP somewhere.)

and sadly NEVER reaches this code :(

I intiliase the plugin with this, on form, ASP only ever has 1 form, which you cant rely on the id being the same, ever.

<script type="text/javascript">
        $(document).ready(function () {
            $('form').areYouSure({ 'message': 'You have un-saved changes.' });
        });
</script>

I will try to find a fix and publish it here, just in case it seems viable to push upstream.

Thanks

[p10tyr]

The best workaround i have now is simply adding this to every singe save button.

   OnClientClick="$('form').removeClass('dirty');"

Remove dirty on all one forms sigh. If I find a way to use one place to manage all the buttons I will comment

[p10tyr]

Well I learned about "duck punching" or better known as monkey patching thanks to a few blog posts. I am not sure hot to incorporate this into a plugin? But my solution for __doPostBack hell is to add this , pretty interesting looking code. Basically closed and does not pollute the namespace, and works well. Looks a bit like jquery pluygin :)

Just to be sure this needs to be right after the orignal __doPostBack or just ponk it in a document.ready somehwere. Now all ASP invoked post backs works fine.

(function (w) {
  var old__doPostback = __doPostBack;

   w.__doPostBack = function (eventTarget, eventArgument) {
        $('form').removeClass('dirty'); 
         // Call the original function, parameters included.
         old__doPostback.apply(this, [eventTarget], [eventArgument]);
      }
})(window || {});

[codedance]

I think your solution is the correct one - alias the method and override it's behaviour. As you pointed out, it's "legacy" and I don't think this should be in the core code, but instead should be a documented workaround.

I think referencing this issue would be the best way to document. I've done this for a number of other cases such as integration with selected 3rd party form widgets.

Thoughts?

[p10tyr]

Yea sounds good. If somebody else can find it later that would be great.

Thanks.

On Tuesday, September 16, 2014, Chris Dance notifications@github.com wrote:

I think your solution is the correct one - alias the method and override it's behaviour. As you pointed out, it's "legacy" and I don't think this should be in the core code, but instead should be a documented workaround.

I think referencing this issue would be the best way to document. I've done this for a number of other cases such as integration with selected 3rd party form widgets.

Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/codedance/jquery.AreYouSure/issues/61#issuecomment-55712055 .

With regards, Piotr Kula - Kula Solutions LTD

https://www.piotrkula.com/