1. Cross-browser drag and drop.
2. Modify WebParts page (drag and drop, minimize, restore, close, add, delete) without postback.
3. Update contents of WebPart without postback.

Cross-browser drag and drop is enabled by using the WebParts controls in the AJAX Futures CTP.

Modifying a WebParts page without postback is implemented by wrapping the WebPartManager and WebPartZones in an UpdatePanel.  This was partially working in the July CTP, but it does not work and is not supported in ASP.NET AJAX 1.0.  It may be supported in Orcas.

Updating the contents of a WebPart without postback is implemented by placing an UpdatePanel inside a WebPart.  This is supported in the core ASP.NET AJAX Extensions 1.0.  It should work with either the ASP.NET 2.0 WebParts controls, or the AJAX Futures CTP versions of the WebParts controls.

Hope this helps.  I've also posted this to the ASP.NET Forums: https://forums.asp.net/thread/1545256.aspx.

Beta2
public class MyScriptControl : Control, IScriptControl {
    protected override void OnPreRender(EventArgs e) {
        base.OnPreRender(e);
        ScriptManager.GetCurrent(Page).RegisterScriptControl(this);
    }
}

RC
public class MyScriptControl : Control, IScriptControl {
    protected override void OnPreRender(EventArgs e) {
        base.OnPreRender(e);
        ScriptManager.GetCurrent(Page).RegisterScriptControl(this);
    }

    protected override void Render(HtmlTextWriter writer) {
        base.Render(writer);
        ScriptManager.GetCurrent(Page).RegisterScriptDescriptors(this);
    }
}

In the RC, we added this to the ExtenderControl base class, so this change doesn't affect controls deriving from ExtenderControl.  It only affects controls directly implementing IScriptControl and IExtenderControl.  This change is mentioned several times in the ASP.NET AJAX CTP to RC whitepaper (search for "RegisterScriptDescriptors").  The rest of this post explains the rationale behind this change.

We needed to make this change because there are some scenarios where a control's PreRender() method is called but its Render() method is not.  One example is a control inside a closed WebPart.  In Beta2, ScriptControls did not work inside closed WebParts.  The ScriptDescriptors would be registered, but the control would never render any HTML, which causes a JavaScript error when we try to find the associated HTML element.

To fix this issue, we needed to somehow verify that a ScriptControl was rendered before registering its ScriptDescriptors.  Unfortunately, there is no way to externally determine whether a control has been rendered, so the only solution was to require the ScriptControl to call into the ScriptManager from its Render() method.  We realize this extra call to RegisterScriptDescriptors() is annoying, but it was the only to fix the bug, and the change only affects controls directly implementing IScriptControl or IExtenderControl.  As a result, we added the ScriptControl base class in RC, which makes it easier to write a basic ScriptControl without directly implementing the IScriptControl interface.

The new model is also more correct from a purist's standpoint.  A control's script library is registered via its ScriptReferences, and it is safe to register these even if the control is never rendered.  To maximize flexibility in rendering these script libraries, the ScriptReferences must be registered during the PreRender phase.  A control's instance script is registered via its ScriptDescriptors, and it is not safe to register these if the control is never rendered.  So, the instance script must be registered during the control's Render phase.

There are five separate demos:

1. ExternalWebParts: The WebParts and Connections for a page are stored in an external XML file, instead of the page itself.  Shows how to decouple the WebPart definitions from the page.  Illustrates the different phases of the WebParts life cycle.
2. ContentManagement: Customizes WebPart Personalization to implement a content management application.  Multiple versions of the personalization data are stored for each page and loaded dynamically.  Illustrates how to extend WebParts Personalization.
3. SecondaryIntefaces: Uses the "SecondaryInterfaces" feature of WebParts connections to implement a basic interface yet provide richer data on a second interface.
4. SecureImportExport: Uses a custom WebPartManager to encrypt the sensitive data in an exported .WebPart file.  The data can not be view or modified by the end user, and can only be decrypted by the web server that encrypted it.  Illustrates how to extend the import/export process.
5. WebPartsAdmin: Allows management of Personalization data via an external page.  Implemented by executing the target page in a child request.  Illustrates how to modify the personalization data on another page.

PRS418_Sanabria_Harder.zip

AMS306_Harder_Tariq.zip