Invoke Javascript method after partial postback ?

Howdy All,

This might be an easy one but I don't seem to be able to figure it out.

Basically I have an update panel which contains a button that causes the partial postback. After the postback I'd like it to call a Javascript method.

I tried looking to set it on an atlas object and I even tried some hacks like putting a literal control in the Update Panel and setting the text to <script language=""Javascript"">testFunction();</script>" but still no cigar.

Any help would be greatly appreciated.

Try registering your script on the server-side, during the partial post. The script you register will be executed when the response is received from the partial postback.

Page.ClientScript.RegisterStartupScript

-Tony

in my callback function i havestring js = "alert('s');"; Page.ClientScript.RegisterStartupScript(GetType(), "key", js);It doesn't fire

casaubon:

in my callback function i have string js = "alert('s');"; Page.ClientScript.RegisterStartupScript(GetType(), "key", js); It doesn't fire

You need to wrap your js in <script type="text/javascript"> </script>, or use the overloaded RegisterStartupScript specifying "true" for the last parameter.

Hope this helps,

-Tony

Invoke JavaScript method after partial post back

  Hi,

 Im trying to invoke a javascript method after a partial update has occured from an update panel. I found some code for which i beleive works for an old version, but it doesn't work for the released version.

 Does anyone know how i can invoke a javascript method after post back?

1 function afterPostback()2 {10 }1112 function PageRequestManagerPropertyChanged(sender, args)13 {14if (args.get_propertyName() =="inPostBack")15 {16if (!$object("_PageRequestManager").get_inPostBack())17 afterPostback();18 }19 }2021 function pageLoad()22 {23 $object("_PageRequestManager").propertyChanged.add(PageRequestManagerPropertyChanged);24 }
 

You can handle _endRequest to do that. Try something like this:

var prm = Sys.WebForms.PageRequestManager.getInstance();prm.add_endRequest(afterPostback);function afterPostback(sender, args){}

Note: This code has to be placed below the ScriptManager control.

Brilliant, that works a treat.

Thanks

Is a "partial postback" really partial?

Hi,

I've inherited a large project and am now in charge of adding AJAX support to it, in order to make it seem more responsive to the users, and to avoid having to perform a complete postback every time the users want to navigate to a different control.

However, my first experiences with using AJAX.NET seem to be a bit disheartening. I added a simple UpdatePanel to the form, as well as a button and a textbox inside of it. The button has a server-side call to update the textbox with DateTime.Now.ToLongTimeString(). Now, whenever I call it, it takes at least 4 seconds to perform a round trip to the server and back with the time. This is unacceptable for our purposes, so I looked into the cause. Our pages are, to put it politely, freaking huge. For the 4-second one, the page is over 100k. So I did some testing, and it appears that on an ajax-postback, the entire page is being posted back to the webserver, constructed, and updated, and finally the relevant pieces (mainly the contents of the update panel) are sent back to be updated.

On the web I've seen many references to so-called "partial postbacks", which I took to mean that the AJAX call is only going to send the contents of the update panel back to the webserver, and not the entire page. Am I incorrect thinking this? In other words: is the entire web page always going to be sent back to the server, even with AJAX calls, or am I missing something important here?

Thanks for your time.

Hi

What you are getting is the default behaviour. What happened in ASP.NET AJAX is that page is posted back to the server and all the page events are rendered as such as in normal postback.

What happens actually, when you put the controls inside Update Panel, only the portion of the data that is inside Update Panel renders back to the server but the complete life cycle of the page behaves normally as normal postback.

So if you want the real power of AJAX, you have to sync with View State and all other stuff.

Hope that helps you..

Bye

Ron,

Your issue there could be ViewState size. Even if the page sends and receives only the data relevant to the UpdatePanel to refresh, ViewState is still transmitted and the complete page life cycle occurs.

Just turn trace on and check you ViewState size. If it's huge, try to find the controls that may have it disabled. If you manage to reduce it's size, your AJAX page will be "faster".

Also, something that really helped me to reduce "page size" and, therefore, AJAX "speed", was to enable IIS dynamic compression.

Cheers,

Juan

Yeah, compression helps, also make sure that your running in compilation mode='release' (in debug the scripts are 3x or more larger). Also, if there's no way to tighten up your viewstate, thne it might be worth it to look at other refresh techniques (more js heavy, less plug-n-play) like PageMethods or Webservices. Those will reduce the traffic to only that which is necessary.

I have found that using update panels and MS ajax will be quite a change in how you philisophically go and layout a page. This is something you will find out over the time you are working on your app. For instance, I had the same type of problem you did with viewstate and page size. I found that I had a gigantic drop down list that was filling up my viewstate and gridviews with lots and lots of records in them. My solution was to get rid of the dropdownlist by using a quick search repeater with a select button on each record. This, in a world with full postbacks would be cumbersome, but with updatepanels becomes quite easy. Second, I have gone the route of creating interfaces similar to regular applications like outlook with a record browse on the left and context on the right. The outer page with browsing is a page and the record is a page that gets popped in an iframe. This allows for a quickie javascript double click to open the record in its own window and a single click to open the record in the context window.

Another big help is managing your refreshes. You will find that using the 'updatemode="conditional"' setting in your update panels will also help to speed up the page. When an updatepanel is left without the conditional mark it postsback on each partial postback. Sometimes the implementation of this can be a bit tricky because you have to call the updatepanel.update() method in codebehind, but the benefit is definately worth the hassle.

Finally, shrinking down what you have in your updatepanels will definately help you keep your page moving quickly. If your entire page with huge drop down lists, etc.. works off one gridview this will be troublesome. When you can put your updatepanel around one textbox, then an updatepanel around the update button, you will be well on your way to super fast processing.

Remember that a partial postback posts back anything within the update panel and, therefore, the more you have in the updatepanel, the more that needs to be sent back to the browser.

Great thoughts, and advice. I'll echo the fact that it's a real balancing act, though. Too much granularity in your updates and you lose scalability. Too little and you kill your bandwidth and users suffer. Good page design can go along way to help you keep the balance.

Is a ScriptManager required in every page?

Hi there,

Is there a way to avoid adding a ScriptManager control to every page, just to set the EnablePartialRendering to true? Maybe the partial rendering setting can be configured in Web.Config or somewhere else.

Thanks,

-BentonAgreed. It would be nice to only have to add the ScriptManager in 1 place
instead of every page. I can also understand the other side which says that
by having the ScriptManager in each page, you only add it where it is
needed. However, having it by default if I create an "Atlas" web project
would be a great thing.

Wally

wrote in message news:1201622@.66.129.67.203...
> Hi there,
>
> Is there a way to avoid adding a ScriptManager control to every page, just
> to set the EnablePartialRendering to true? Maybe the partial rendering
> setting can be configured in Web.Config or somewhere else.
>
> Thanks,
>
> -Benton
>

Its not that simple. ScriptManager does a whole lot more than provide a way to enable partial rendering. It orchestrates the entire process by hooking into the page lifecycle in very interesting ways. It also provides a way to define script and script references (typically these are per page, and the config mechanism for per-page settings via location tags is in my opinion really ugly and non-designable).

Scriptmanager also provides APIs used at runtime to make it possible to generate the desired rendering. See my post:http://www.nikhilk.net/AtlasScriptManager.aspx.

The lifecycle bits and APIs could theoretically be implementated via a base AtlasPage class... but this is much more heavy handed approach than adding a control - surely you don't want to have to rebase all your existing page classes from a new base (esp. hard without multiple inheritance)

Hope that explains the current design. I agree if all it did was provide that property, a config option would be just as fine (though in an ideal world you'd want all that on the <pages> section, and in the Page directive, which cannot be done until System.Web is rev'd)

What about putting it in a Master Page..

A.

I've never been able to use Atlas in Masterpages, so I don't know if that will work at this time.

I have the same problem... Do you think it′s an individual configuration problem or it′s an ATLAS problem itself?
Hi,

could you give some examples of the issues you are having with MasterPages?

Is it necessary to run the Asp.Net Ajax Installation Wizard

I have an issue where my web project works well locally with AJAX, Update Panels and Partial Rendering. Everything is kosher.

As soon as I copy my project to a staging server, any page that uses Validators that become enabled through Partial Rendering seem to have issues. The validators cause script errors on some pages, while on others, they are not visible.

The only difference between my local environment (that I can think of) that may affect this is that I ran the AJAX installation on my local workstation while on the Test Server I just copied the Ajax DLLs into the bin folder.

So does anyone know this may be my problem? Is it necessary to run the full install of ASP.Net AJAX for everything to work well? If not then I may need to resort to custom Javascript for client validation which I'd rather avoid since I can't run the install on the server.

no, but you will need to include the AJAX DLLs in your BIN folder then.

Thanks for your reply! It's good that all I need are the dll's since that's all I have access to do. But that now raises the question of why is it all good locally and not remotely on my test server.

Oh well.. I guess I have 2 options:
(1) Javascript for validation
(2) No partial-rendering.. postbacks and use FakeAjax transitions to make nice ajax-like UI.

alcsharp:

Thanks for your reply! It's good that all I need are the dll's since that's all I have access to do. But that now raises the question of why is it all good locally and not remotely on my test server.

Locally the Ajax DLLs are in the GAC, since you used the Installation Wizard. On the server they aren't there, so you need to explicitly include them.

Oh, and I'm betting you are missing a DLL...
What did you include?

I only included System.Web.Extensions.dll. Since I'm not using the Control Toolkit at all I didn't add it.