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).
Before going on, I should also mention that i didn't really use the old instance page methods and I think I won't be using the new static page methods either (though I really prefer the latter approach). Let's start by the speaking about the strenghts of the old instance page methods. In my opinion, there was one big obvious advantage: you could do all your work from the server side without having to write any Javascript code on the client to get the values you needed. For instance, if you had to get the values of 2 or 3 controls and then perform some calculations on it and return something back to the client, you could simply write your sever method with C# (or other .NET language) and annotate it with the WebMethodAttribute and you were ready to go.
This is a great, specially if you don't want to bother with the details associated with Javascript. Yes, you still need to call the method from the client (by using the global PageMethods object), but you no longer need to get the values of the controls in the client side and pass them as parameters to the server method since you'll be doing that (getting the values of the controls) on the server side, using the traditional server side approach (control.property).
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.
Since you can't really change the view state of the page, the only thing page methods are letting you do is making sure that you don't leave the confort of writing C# code on the server side where things are more coherent than in the client side. Now think about a performace point of view: are really page methods that great? shouldn't you be using Javascript and perform a simple web method call in order to get your result back? think about it...using the instance page method is easier and really confortable...but is it really performant? I'd say no and I'd even go further and say that most things (if not really all the things) that currently are being done with it could be done through web methods calls... that's why I didn't like the old instance page methods: you can build them easilly, but you're paying a huge price when you use them.
Now enter the new static page methods. If you've been using the old instance page methods, you already know that the new static methods are useless for you since you don't get any context associated with the method call (ie, you're no longer able to use the controls on the server side). Reusing the previous 100 TextBoxes example, you will need to get the values of the 3 Textboxes through Javascript in order to perform the remote page method call. I concede to the old instance page method users when they say that having a page method without context is almost useless.
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.
Many say that not including the old instance page method calls means that AJAX extensions have less features than in previous releases. Well, that is a fact, but at least you've got one less thing to shoot yourself in the foot. On the other hand, I must say that having the old instance page methods really helped many to write remote method calls without using Javascript code and that there are lots of guys which really don't care about performance and just want to quickly build AJAX pages (not my view of how things should work, but everyone is entitled to think and act as they like).
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!