Page methods: why I prefer them to be static...
In my previous post, I've presented an alternative to using the old page instance methods that existed on previous releases of the CTP. Since I'm always late, i didn't realize that there was already a heated debate on the community and hadn't even noticed that Rick Stralh had a post where he complains about several things in the new release of the AJAX extensions. One of the things he wants back is instance page methods.
Though i really didn't enjoy the old instance page methods, i'll try to perform an honest and independent analysis on instance vs static page methods. If you're reading this, you need to know that i'm not affiliated with Microsoft in any way nor have been in the past. So, I'm not really defending them, but only giving my opinion on this subject (instance vs static page methods).
For a long time, I used to think that instance page methods had another advantage: you could update the view state of the page from within an instance page method call. If this was true, it would be its greatest advantage since without it, you couldn't really update the view state without using an UpdatePanel and getting its HTML back (as you must recall, UpdatePanel always returned its HTML in previous releases of the platform, which isn't normally needed when you're using instance page methods).
Unfortunately, I was wrong about this. I've run a simple test with an ancient ATLAS project and I've confirmed that the view state isn't really updated during an instance page method. In other words, you can change the view state of the page on the server side, during an instance page method call, but that info isn't sent back to the client side. Due to that, the hidden view state field isn't updated and when you get the next partial/full postback or perform the next instance page method call, you'll have the same old values that existed before the instance page method call you've just made. As I said, I've just reached this conclusion by running an old ATLAS app and using fiddler to see what the page is getting back from the server (I really can't be sure if this was the behavior present on the previous July CTP, though I think it was).
The biggest disadvantage I see with page methods is that a method call results in sending all the existing form fields back to the server. For instance, let me give an example (which is really an extreme example of how things can be bad). Suppose you have 100 textboxes (sorry Garbin, you've influenced the number of controls:) ) and you need to get the values of 3 of them to perform some calculations on the server side. Using the old instance page method means that the page will be sending the values of the 100 textboxes + the other controls maitained inside the web form (for instance, suppose that you're using viewstate...yes, you'll get that field sent back to the server too). Remember: you just needed the values of 3 textboxes. Unfortunately, that doesn't matter when you use the old page methods since the client really need to send eveything back in order for you to use the controls during the remote instance page method call.
But no totally useless, though, since they solve a problem which existed on the previous releases: how could you write a method on the server side and invoke it from the client without developing a web service? the new static page methods solve this problem and let you perform a remote method call without having to develop web services. The new static page method are also more performant since they don't automatically pack all the form fields when you perform a remote call (which is logical, since the server method is static after all).
So, the new static methods are useful if you're not into writing web services to perform remote server method calls.
So, in order to get everyone happy, I'm proposing some fixes for the next release. For starters, we should be able to call static and instance page methods from the client side (you already know that I won't be calling instance methods, but I'm sure that others will). Instance page methods would work as they did in previous releases and static methods would work as they do now. To support this, the team would have to include a new client class (like they did in previous releases) which would help gathering the data during the remote method call.
They'd probably had to add two global variables to the page: one would let you perform the static method calls and the other would let you perform the instance method calls. Nothing too fancy, I think... Allowing both kinds of calls would let everyone happy (including me :)) and i think that it might just be doable!