EventValidation can be your friend or foe depending on if you're struggling with it or not. Probably everyone who have done some Ajax above "Hello World" have seen the "ArgumentException: Invalid postback or callback argument" error below.
So what is the EventValidation?Imagine you have a website where you have a DropDownList which contains "action items" for patients in a hospital. Now if you're in the role of "doctor" you can prescribe drugs, so the "Prescribe drugs" action item would be existing in the DropDownList. If you are in the role of "Nurse" you'd have "Give prescribed medicines". And if you are in the "Close Relative" group you'd be able to choose "Show empathy". Then you have a button next to the DropDownList which "executes" the chosen action.
Normally you'd populate the DropDownList according to who is logged into the system and only show the "Action Items" the currently logged on user should have access to, then you'd have a switch in the OnSelectedIndexChanged Event Handler where you chose between giving more drugs, prescribing more drugs or give the patient a hug. And most developers would for such a solution think that "since Close Relatives never gets the 'Prescribe Drugs' action item into their DropDownList, we don't need to verify if the user belongs to a role which can legally do the chosen ActionItem".
BIG MISTAKE!Everyone capable of downloading FireBug can change the values of items in the DOM, EASY! Here comes EventValidation into the picture.
EventValidation creates a "salt value" from "all" (actually more like most) controls on your page, and if someone have done serious changes like adding up another value for a DropDownList during or before creating a postback/callback to the server then you will get an exception telling you roughly; "Invalid postback or callback argument. Event validation is enabled using..."
I assume the above sample of "letting relatives to patients go berserk with drugs" is a pretty good reason to understand why EventValidation is your FRIEND in fact and NOT your ENEMY... ;)
"Then came Ajax"...Crap! When we finally had this relatively understandable and had started to get the hang of it it all of a sudden turned into a problem. Look at the code below;
Try out the above code (or similar logic) in ANY Ajax Library, including our
Gaia Ajax Widgets and if you click the Ajax button twice without changing the DropDownList selected value you'll understand pretty soon why EventValidation can "turn" on you and become your worst enemy.
What is happening here is that in an Ajax Callback you're changing the value of a "non-Ajax control". This has the implications of changing your EventValidation "salt" while NOT being able to change the Controls on the page which are the basis for creating the salt. Then when you get to the server with a SelectedValue of; "value1", EventValidation will raise an exception since "value1" is not anymore a valid value of the DropDownList.
No matter what solutions you try including ASP.NET Ajax with UpdatePanels, Ajax.NET with PageMethods or Gaia Ajax Widgets it will still fissle. UNLESS you also have some solution for changing the actual ListItems of the DropDownList. In Gaia this is dead simple. Just stop using ASP.NET Controls and exchange them with Gaia controls and it will work.
At the moment there's another problem in Gaia which we have sorted out now, but in the current release this problem exists. This problem is that Gaia won't serialize non-Gaia Control Values. This will throw the EventValidation exception if you use for instance ASP.NET DropDownLists in your solution at all. The reason is that since we don't serialize non-Gaia controls the "value" of the DropDownList will be non-existent! This creates all sorts of weird problems, especially when combining Gaia with SharePoint or DotNetNuke where you cannot change all the controls on the page to Gaia controls since there are some native controls from the CMS system which must be there. Though as I said, we have fixed this problem and in our Glory Release which comes out the 15th of May this bugs is fixed. But the above code will unless you fix it still throw an exception. Now at least you know why! ;)
I hope that this has cleared up some misunderstanding in regards to the EventValidation, and I also hope that it has helped you understand the implications of turning it OFF. If you turn it off then at least examine the risks before you end up letting random relatives go berserk with your drugs ;)