With AJAX, Using method="GET" instead of the default "POST" - possible?

Guys,

We are trying to use GET instead of POST to reduce the size of the packets sent to the server with each partial postback.

1) How do I do this? I tried specifying method="get" inside the form declaration, didn't work.

2) is this a stupid idea? Our viewstate can go to 8 kb or so. Does GET always tack on the view state to the

URL string?

Thanks !

http://kochukeralam.com

hello.

well, if i recall correctly, the only way you have to do that is to handle the client initializeRequest or beginrequest client event. for instance, if you choose to handle the beginrequest event, the method will receive a referece to the current webrequest object that is being used to make the call (again, we're talking about client objects, which means writing js). that object has a property called httpVerb which you can set to specify the type of call you're making

and yes, i'd probably stick with the post method...

The way a partial postback works, you NEED the ViewState in order to create an instance of the Page, run through its life cycle, and generate the HTML that needs to be returned to the PageRequestManager. So, even if you retooled it to use GET, you'd need to send the ViewState on the QueryString anyway (which would be difficult in the ~2k max you have to work with there).

You're right to be conscious of the ViewState size though. A better solution would be to look into changing where the ViewState is persisted at. Check this out: http://weblogs.asp.net/scottgu/archive/2006/06/18/PageStatePersister-Extensibility-with-ASP.NET-2.0.aspx

hello. hum, i'm not sure if i'm following. if I'm not mistaken, you can disable viewstate and the page should keep working without any problems...

Sure, if the page is designed to not rely on the ViewState (which is always a good option), then it's not needed for any type of request.

However, I believe the original poster was thinking if he could simply switch to a GET, then he could avoid sending the ViewState back to the server for partial postbacks. That wouldn't work, unless ViewState was persisted on the server side somehow (which would make GET and POST equally performant anyway).

hello again.

oh,. i see...then you're absolutely right.

WYSIWYG-editor saying that a ScriptManager is not present when it is; throws an exception

Hey Guys,

I'm new to the AJAX Toolkit, so pardon me if my problem seems a bit dumb.

As you can see in this image, I have a ScriptManager on the page, so I don't have a hot clue of what's really causing the problem. My HTML is all valid, and I can actually run the page through the built-in server and it works just fine.

Anyone have any ideas?

I'm not so sure but I think this could be caused by a wrong reference to the library that ajax uses (the Web.Extentions).

Try to remove the scriptmanager and just drag a new ScriptManager from the ToolBox to the top of the webpage. Then save the page, close it, and reopen it. Normally the design-view should render normally now.

I hope this helps!

Greets,
Wim

xml script syntax

hello guys.

today i'm taking a closer look at the xml script syntax and i have a few doubts about it.

1. i've just noticed that the page element has the following:

what's the purpose of the namespace? well, i'm not a xml expert, but it looks like the namespace is associated with a prefix that isn't used anywhere else...

2. it looks like the profile service can be "xml-scripted" but the same doesn't happen with the authentication service. is there any reason for this behavior? well, i guess that i can allways create a new action so that i could call its methods from xml-script to handle the click event of a button...ah, forgot about question 3:

3. in the action how are we supposed to declare the parameters? for instance, let's suppose that i'm calling a method that receives 2 parameters and their calues come from the text property of 2 textboxes?

The first question is not very clear. Seems that some text is lost because it was not encoded. But one of the purpose of namespace is when you make an object xml-script accessible, you call Sys.TypeDescriptor.addType method

Sys.TypeDescriptor.addType('script', 'application', Sys._Application);The first parameter takes the namespace prefix. I believ the Atlas parsing routines are currently ignoring the script namespace prefix.

In general javascript classes that implement Sys.ITypeDescriptorProvider class are XML Scriptable. AuthenticationService class doesnot implement this interface and is supposed to be a lightweight class. That's why it is not XML-Scriptable. But you can get away by implementing using serviceMethod in the XML-Script.

Hello Rama.

well, that makes sense, though i think that the xml written should use the prefix (ie, it should be
regarding the usage of serviceMethod, yes, i think i could do that...

XMLHttpExecutor

Hi guys,

I have noticed the following code in the abort function of the Sys.Net.XMLHttpExecutor class:

var a=this._webRequest._get_eventHandlerList().getHandler("completed");
if(a)
a(this,Sys.EventArgs.Empty)

The documentation states that the completed event of the WebRequestManager is raised when the request is completed, timed out or aborted.

Maybe the code should be:

a._webRequest.completed(Sys.EventArgs.Empty);

like in the case when the request is completed or timed out.

Is thig a bug or a feature?

Bogdan

The executor sets the Web request state to aborted. This means that the XMLHttpExecutor Class instance's started Property and aborted Property methods both return true.
Next the WebRequestManager Class instance calls the completed event handler on the associated request object.
After the abort method is called, the state of the response returned by the executor's methods is undefined.
You can call the abort method multiple times. However, the second and subsequent calls are not processed. The completed event handler is raised only once.
You get an exception if you call the abort method before you call the executeRequest Method method.

The unique document?about?Sys.Net.XMLHttpExecutor we can use is from?here?-?http://ajax.asp.net/docs/ClientReference/Sys.Net/XmlHttpExecutorClass/default.aspx
Try to take a look at it and get some ideas from it.

Thank you for your response! Perhaps I didn't make it clear enough .. I agree on what you said about the abort method and what happens if it is called multiple times but my concerns are related to the completedRequest event of the WebRequestManager that is no longer raised in this case.

When a request is timed out the _onTimeout event handler is called and thus the WebRequest's completed event is called:

this._onTimeout=function(){
if(!a._responseAvailable){
a._clearTimer();
a._timedOut=true;
a._xmlHttpRequest.onreadystatechange=Function.emptyMethod;
a._xmlHttpRequest.abort();
a._webRequest.completed(Sys.EventArgs.Empty);
a._xmlHttpRequest=null
}
}

By Calling the completed method of the underlying WebRequest the completedRequest event of the WebRequestManager and also the completed event of the WebRequest are raised and all the registered event handlers notified.

Likewise in the XMLHttpExecutor class when the request completes the same completed method of the WebRequest is invoked:

this._onReadyStateChange=function(){
if(a._xmlHttpRequest.readyState===4){
a._clearTimer();
a._responseAvailable=true;
a._webRequest.completed(Sys.EventArgs.Empty);
if(a._xmlHttpRequest!=null){
a._xmlHttpRequest.onreadystatechange=Function.emptyMethod;
a._xmlHttpRequest=null
}
}
};

Like in the first case the completedRequest event is also raised.

When the request is aborted the completedRequest is not raised any more :

abort:function(){
if(this._aborted||this._responseAvailable||this._timedOut)
return;
this._aborted=true;
this._clearTimer();
if(this._xmlHttpRequest&&!this._responseAvailable){
this._xmlHttpRequest.onreadystatechange=Function.emptyMethod;
this._xmlHttpRequest.abort();
this._xmlHttpRequest=null;
var a=this._webRequest._get_eventHandlerList().getHandler("completed");
if(a)
a(this,Sys.EventArgs.Empty)
}
}
};

What do you think about the above mentioned? Do they represent the correct behavior?

Thanks in advance,

Bogdan

Phew !!

Check out this post:

http://forums.asp.net/thread/1537056.aspx

They have finally realized the bug.. Probably it'll be fixed in the RTM release..

Bogdan