Coolite 0.8 breaking changes

[r_honey]

Alas, I expected the Coolite team to atleast enumerate breaking changes exhaustively.

After satisfying myself that the 3 braking changes listed officially do not impact me, I migrated my project to 0.8. And guess what, it struck me out of the blue.

Coolite.Ext.Web.ScriptManager.GetCurrent(page)

has been renamed to

Coolite.Ext.Web.ScriptManager.GetInstance(page)

Also, its overload is available. I agree this could be simply absorbed by a Global Search & Replace. But this leaves a question in your mind, what if something else also changed, but has not been documented??

[geoffrey.mcgill]

I'm sure there are others. If you run into a compiler error, just let us know and we'll investigate.

In what context are you using ScriptManager.GetInstance? In general you should not need to use that method.


There are some methods in the library that we leave as public modifiers, but could be treated as private/internal/protected. The .GetInstance method is one of those.

[r_honey]

Well, I work in an environment where I have multiple Script Managers to manage (System.Web.UI, AjaxControlToolkit, Coolite, and one of my own for my own scripts).

What's more, I work in an extremely modular way. I have built complex, compiled controls for myself. I have User Controls, that can be used on separate different pages.

And every scenario might require a different (combination of) ScriptManagers to be present on the page. Dropping multiple instances of one generates errors, so does dropping none, if that is required.

So, what I have done is to create a Proxy control to manage the managers :;. You can understand the rest of the story from the code below.

<r:ScriptManagerProxy runat="server" registerCooliteManager="true" registerSystemManager="true" registerAjaxToolkitManager="false" />

This essentially frees me from the burden of ensuring that each required manager is present exactly once on each page, that too before any control requires it. Any Template or Compiled control can create an instance of this Control, and add to its control collection. The rest is an obvious story.

GetCurrent(page) is the method that all other managers provided (including Coolite before 0.8). I could not find a reason for refactoring the name to GetInstance().

Also, the renamed method looks like to suggest me that this method would automatically add an instance of the Coolite ScriptManager to the page, if one is not already present, thus meaning you will no longer see those "Add a Manager" exceptions. Am I correct??

[r_honey]

Another change (though not a breaking one), I have found.

Coolite.Ext.Web.Column has been refactored into Coolite.Ext.Web.ColumnBase & Coolite.Ext.Web.Column with the latter deriving from the former.

Also, GridPanel.ColumnModel.Columns has been switched from Collection of Column to Collection of ColumnBase.
This would generate compiler error or a warning depending upon your project settings.

[r_honey]

Now, this one is a serious omission.

Earlier, I remember, in all <ExtraParams> that we can specify in markup, there used to be 3 options, ext:Parameter, ext:ConfigItem and ?? (I don't remember the 3rd one).

Now, there's only one, ext:Parameter. I always wondered what the difference between those 3 was. To me, all of them looked the same as regards the functionality. So, looks like the Coolite team did the right thing by removing the redundant ones. But without documenting it !!!

[Mark.Cooke]

Moving to JSON.NET v3.5 is a breaking change for those using an older version (2.0).

Another (minor) breaking change: PagingToolBar --> PagingToolbar

[r_honey]

I fully acknowledge &amp; appreciate the hard work the Coolite team is putting up, and also that it often becomes difficult for a small team to manage &amp; document exhaustively all changes made during major releases (I see 0.8 as a major release, not in terms of too many new controls, but in terms of enhancements here &amp; there all over the toolkit). And these small enhancements are proving tricky.

Now here's another breaking change that you should be aware of. This regards the use of AjaxMethods.

In 0.7, if you returned an empty string ("") from an AjaxMethod, the toolkit reported it as null to your success handler (in javascript) as the handler's first argument.

In 0.8, an empty string return value is reported as it is, i.e. an empty string to your javascript success handler.

[geoffrey.mcgill]

Hi r_honey,

I'll see if I can reproduce your results with the AjaxMethod and figure out why it's functioning differently. Off the top of my head I can't think of a reason why that would have changed between releases.

[geoffrey.mcgill]

Hi r_honey,

I ran the following sample in both v0.7 and v0.8. The ajax response for both was an empty string.

Example

<%@ Page Language="C#" %>

<%@ Register Assembly="Coolite.Ext.Web" Namespace="Coolite.Ext.Web" TagPrefix="ext" %>

<script runat="server">
    [AjaxMethod]
    public string DoSomething()
    {
        return "";
    }
</script>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Coolite Toolkit Example</title>
</head>
<body>
    <form id="form1" runat="server">
        <ext:ScriptManager ID="ScriptManager1" runat="server" />
       
        <ext:Button ID="Button1" runat="server" Text="Submit">
            <Listeners>
                <Click Handler="Coolite.AjaxMethods.DoSomething();" />
            </Listeners>
        </ext:Button>
    </form>
</body>
</html>

Response

{ result : "" }

Can you post a sample which reproduces your scenario?

[r_honey]

This is getting really frustrating. This is another instance of Coolite behaving differently outside DNN &amp; inside it (You would have noticed geoffrey, I started a separate thread yesterday only for these incompatibilities of Coolite when used with DNN).

You have to take my word, that Coolite 0.7 passed null to the success handler of an AjaxMethod inside the DNN framework, but for 0.8, it passes an empty string if the AjaxMethod returned empty string only.

But to my relief, I was still able to reproduce a working sample that shows this difference between the toolkit 0.7 &amp; 0.8 versions in this scenario.

The zip file attached with this post has 2 simple websites for 0.7 &amp; 0.8, with only sample Default.aspx pages. Click on the button on the pages in both the sites, and see the response (the alert that pops up). You would see the incompatibility (a breaking change) straight away.

However, I again insist, that in this sample for 0.7, an object is passed to the success handler. When I do the same thing inside DNN, null is passed to the same handler.

By the way, the attachment is >4 MB in size. The time it was taking for upload almost made me cancel the process. See if you can increase upload speeds for attachments. Otherwise, I would need to use Rapidshare in future.

EDIT: I got the following error during upload: The connection to the server was reset while the page was loading.
So, I have uploaded the attachment at rapidshare:
http://rapidshare.com/files/247250756/Website.zip.html