views:

84

answers:

1

I'm maintaining an ASP.NET Web application that was originally created by an outsourcing firm but is now in-house. I've noticed that the previous Developers added several Javascript functions to the Master Page that seem to handle postback events. Here's a code sample -

    var isPostBackEvent=false;

    function ValidatePostBack()
    {
        isPostBackEvent=true;
    }

    function SetPageModified()
    {
        setContainerFieldValueById('ctl00_','pageModified', trueString());
    }

And here's an example of how these functions are called in the code -

<asp:Button ID="btnSave" runat="server" Text="Save Record" Font-Names="Verdana" Width="115px" OnClientClick="ValidatePostBack();" Font-Size="9pt"/>

As far as I can tell, the functions do the following:

  • SetPageModified: Adds a flag to a web server control that indicates whether the entire webpage has been modified by the user.

  • ValidatePostBack: Adds a flag to a web server control indicating whether a postback event has occurred.

I'm trying to figure out two things -

  • Why someone would add these types of events when they could just as easily be handled using .NET Postback events instead?

  • And whether or not these Javascript Postback events interfere with any .NET Postback events?

A: 

Well, for the first point it's entirely possible that the original developers simply didn't understand the postback / server event model that well when they wrote the code originally - I've seen plenty of cases in my travels where people re-invented parts of the ASP.NET framework because they didn't know how to do it out-of-the-box.

Even if they did learn more as they went along, they probably would have left the code intact anyway, because getting rid of it would probably break something else, and so on.

Why not just get rid of the code and see what breaks? If the house of cards comes down, revert your local changes, no harm done. There may still be broken windows though, so be careful, but it can't hurt to play around in your own sandbox.

The postback mechanism is only likely to screw up when you overwrite client event handlers for existing elements, such as OnSubmit for server-bound forms, or if you screw around with the hidden field values of __EVENTTARGET and __EVENTARGUMENT during form submission. Just adding extra client event handlers to buttons won't break the postback mechanism.

Without seeing the complete code I can't tell you much more though.

Sam
Thanks for your suggestion. I finally removed the Javascript Postback code after a modification to the Document window finally broke the Javascript Postback event handling.
Spacehamster