Walkthrough: Creating a Basic ASP.NET AJAX-enabled Web Part

The issue with publishing sites is on publishing master pages. They define the webpartmanager outside the form tag.

I don't known why it was defined that way, but moving the webpartmanager inside the form tag solves this problem.

I come up with this when comparing default.master and publishing master pages

Hello everybody!

We are facing strange problem when using SPCalendarView in custom aspx form. Calendar does not cause any single postback. When we have followed this walkthrough, our calendar started to partially work, but it was throwing javascript exceptions in function from step 4. There was semicollon missing, so we have fixed it and after this calendar stopped working again... 
Does anybody have any idea what can be wrong?

Simply go to your master page, in the head section, place all the title tag on the same line.

Wrong
<title>
My Title
</title>

Good
<title>My Title</title>

That's it!

---------> Thanks stephaneperron! That works with my problem. - James Zheng

---------> That's it, thanks Stephane ! I'm still not sure why this is happening though. It's like clicking the AJAX control causes the page title control to be 'read' in a different way, also reading the returns in that bit of code. We had

<titleid="idTitle">
<asp:ContentPlaceHolderID="PlaceHolderPageTitle"runat="server"/>
</title>

which resulted in two blocks being shown as the page title.
Changing this to <titleid="idTitle"><asp:ContentPlaceHolderID="PlaceHolderPageTitle"runat="server"/></title>
in the masterpage fixed the page title issue immediately.

- Pascal van Alphen

Hi'

This example works only for the first time. After adding webpart to a page enter any string in textbox and click the button, first time it works but if i try again it doesn't seems to work. Any clue?

Srinivas

Hi you try this piece of code...


#region KAPILAJAXFixingFormAction
private void KAPILAJAXFixingFormAction()
{
if (this.Page.Form != null)
{
string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];
if (formOnSubmitAtt == "return _spFormOnSubmitWrapper();")
{
this.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";
}
}
ScriptManager.RegisterStartupScript(this, typeof(<put the class name here>), "UpdatePanelFixup", "_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;", true);
}
#endregion KAPILAJAXFixingFormAction

So I used the same type of architecture as listed here. However, whenever I click the method that performs the ajax call the page title gets changed to illegiable characters. Any idea why this would happen?



This issue is with publishing portal sites.

Publishing->Publishing Portal(site template) and above code works fine with Publishing->Collaboration Portal(site template).

The script in this example will only register once event if you have multiple instances of the same web part. Because ScriptManager will not register scripts with same key value more than once.

More more info and example, you can read from

http://www.jamestsai.net/Blog/post/How-To-Create-AJAX-enabled-SharePoint-Web-Part-with-UpdatePanel-and-UpdateProgress-in-10-minutes.aspx

As mentioned above, this example does not work if more than one copy of a web-part using the same technique is on the same page b/c they all try to register a script manager.

That seems a bit limiting to only have one Ajax WebPart per page.

Is there an official Microsoft example with a recommended pattern for creating a Ajax enable web-part that can be used more than once on a page?

Brock

I encountered an issue when I tried to add webparts of differing types into the same web part page - the result was a stack overflow causing IE to abruptly terminate.

The problem arises when the script defined in the EnsurePanelFix method above, is inserted more than once into a page. The execution of the first script block is harmless. The execution of any subsequent block however, eventually results in a stack overflow. The reason is that the subsequent assignment to RestoreToOriginalFormActionCore is from the newly defined RestoreToOriginalFormAction (defined in the frist script block), and not the original RestoreToOriginalFormAction method.

In the subsequent execution of the script block, RestoreToOriginalFormActionCore and RestoreToOriginalFormAction are made equivalent, so the RestoreToOriginalFormAction method becomes infinately recursive.

     var RestoreToOriginalFormActionCore = 
       RestoreToOriginalFormAction;
     RestoreToOriginalFormAction = function()
     {

       if (_spOriginalFormAction != null)
       {
         RestoreToOriginalFormActionCore();

There are a number of ways around this, (that I can think of) but none of them are ideal. The first is to ensure that only one script block is inserted into the page, no matter how many types of your web parts are added to the page. This is done by modifying the call to RegisterStartUpScript. I found that it is the combination of the type parameter and key parameter together that determines whether the script is inserted. So I just created a base web part (MyBasePart), and used that type as the type parameter. typeof(object) also worked; I assume you can use any type that you want.

ScriptManager.RegisterStartupScript(this, typeof(MyBasePart), "UpdatePanelFixup",fixupScript, true);

Well this works if you publish all of the webparts that go into the page, but there will be issues if you also want to use web parts published by others, because depending on what type/key they used, you might still end up with more than one script block in your page. So the solution that I'm using for the time being is to define RestoreToOriginalFormAction based on what it is originally. (But this will break if the definition of RestoreToOriginalFormAction in WSS changes)

String fixupScript = @"
   if (typeof(_spBodyOnLoadFunctionNames) !== 'undefined'){
      _spBodyOnLoadFunctionNames.push(""_initFormActionAjax"");
      function _initFormActionAjax() {
         if (_spEscapedFormAction == document.forms[0].action){
            document.forms[0]._initialAction = 
            document.forms[0].action;
         }
      }

      RestoreToOriginalFormAction = function() {
         if (_spOriginalFormAction != null) {
            if (_spEscapedFormAction==document.forms[0].action){
               document.forms[0].action=_spOriginalFormAction;
            }
            _spOriginalFormAction=null;
            _spEscapedFormAction=null;

  
            document.forms[0]._initialAction = document.forms[0].action;
         }
      };

  
   }";

I used the VS script debugger to find the original definition of RestoreToOriginalFormAction and incorporated it into the above code block. The new definition simply adds one line at the end:

document.forms[0]._initialAction = document.forms[0].action;

I removed the call to RestoreToOriginalFormActionCore. This is important because if a third party web part appears in the page after yours and again redefines the RestoreToOriginalFormAction method, there is still no possibility for recursion. i.e. RestoreToOriginalFormAction will become:

     RestoreToOriginalFormAction = function()
     {
       if (_spOriginalFormAction != null)
       {
         RestoreToOriginalFormActionCore();
         document.forms[0]._initialAction = 
         document.forms[0].action;
       }
     }";

But RestoreToOriginalFormActionCore is our function, which is not recursive. The only side effect is that

document.forms[0]._initialAction = document.forms[0].action;

will be called twice in succession, but that should be harmless.

Naturally, all bets are off if you want to use your web parts with more than one web part from elsewhere.

***********

The other way to work around this problem is to use a Page property – ClientScript. The ClientScript property gets a ClientScriptManager object to manage, register, and add script to a web page. This is to keep the original script as it is.

The ClientScript returns a ClientScriptManager object, and the object exposes a method, IsClientScriptBlockRegistered() that we use to make sure whether the same script block has already been registered into the web page or not.

This keeps the script block presented in this walkthrough as it is. Below is the sample code:

string scriptKey = "UpdatePanelFixup";

if (!Page.ClientScript.IsClientScriptBlockRegistered( scriptKey ))

ScriptManager.RegisterStartupScript( this, typeof( SayHelloWebPart ), scriptKey, fixupScript, true );


Hope it helps!

- James Zheng

Still having postback problems with this web part.

I am still getting the post backs and you also forgot to Render the controls as follows

protected override void RenderWebPart(HtmlTextWriter output)
{
this.EnsureChildControls();

displayName.RenderControl(output);
inputName.RenderControl(output);
sayHello.RenderControl(output);

//output.Write("Hello FAQ");
}

I too have encountered issues when using this sample code in WSS 3.0 SP1 with ASP.NET AJAX Extensions 1.0.

Similar to the JavaScript overflow issues identified by jsum, you are only allowed one ScriptManager per ASP.NET page. This means that a check will need to somehow be made to see if a ScriptManager is already present on the SharePoint page before another is added by the AJAX-enabled Web Part. I haven't quite figured out the best way to achieve this yet, but catching the System.InvalidOperationException that is thrown when the second or subsequent ScriptsdddddddfsdfsdfsdfManagers are added to the Page seems to be a temporary workaround.

Tragen: It appears to be related to using Publishing Webs. If you try it on a regular site it'll probably work. I haven't been able to determine a workaround for that yet. If you do find one, post it here.

I've downloaded this code and built a WebPart using it with no changes. I deployed the WebPart to my MOSS 2007 site collection, and added it to a page. Clicking the LinkButton causes a full postback each time with the whole page refreshing. There's no partial rendering of the Label control.

How can I get around this?

I even tried both 1.0 and 3.5 versions of System.Web.Extensions.

Thanks.

[WolfyUK] Have you followed the steps at http://msdn2.microsoft.com/en-us/library/bb861898.aspx to configure WSS 3.0 SP1 for AJAX-enabled Web Parts?

[Noelle Mallory - MSFT] Please post questions to the MSDN Forums at http://forums.microsoft.com/msdn. You will likely get a quicker response through the forum than through the Community Content.