Widgets: Drag, drop and reorder. Simply done with JQUERY.

The heart of the Dropthings project, IGoogle or Pageflakes is the client side moving of the widgets. Be it dragging and dropping the widgets in other columns or reordering the widgets in a single column, this client side behaviour it the flashy part of the widget system.

In the Dropthings project the Author originally used the microsoft AJAX client side library along with quite a bit of his own code. No critisim here, he coded a complex cross-browser system that WORKED! I would not even have tried.

But, in the latest addition it says that the code was converted over to JQUERY. Well I looked at that code and while he may have converted to use JQUERY, he is not really USING JQUERY. Most of his system is still in place. No problem with that, unless you are not the Author and want to modify or enhance it.

I went another route: pure JQUERY. With just a few lines of code and a bit of AJAX to update the server I got all that functionality without all the complexity. Here it is:

        $(document).ready(function() {
            $(".DropZone").sortable({
                opacity: 0.5,
                smooth: true,
                helper: "clone",
                handle: ".WidgetHeader",
                connectWith: ".DropZone",
                placeholder: "WidgetSortPlaceholderHighlight",
                forcePlaceholderSize: true,
                stop: function(event, ui) {
                    callMyService();
                }
            });
        });

Thats it. You now have multi column drag and drop support. Just have your div's associated with the DropZone class and the Header of the WidgetContainer associated with the WidgetHeader class. My OnStop call to callMyService() walks through all the .DropZone controls and gets the ID of the Widget, the ID of the DropZone and the index (the order of the widgets) and calls the Webservice to update the database.

Here is a link to a working minimum example.

Dropthings - The good ideas and the bad

In a previous post I talked about my first impressions of the Dropthings project. Here I will talk about some of the ideas that I really liked in the Dropthings project, what ideas I will take away for my own project and the ideas that I thought were great but did not fit with my exact needs. And, at the very end I may add a few comments on another bad idea contained in the Dropthings project.

First I like the idea of not directly loading the widgets onto the page but instead having a common container where you load the widget, then the common container [lets call it the WidgetContainer :-)], is loaded on to the page. Here is a mockup of my version of the WidgetContainer user control:



The Dropthings project and my project save the widget information in two tables, the Widget table where all the default information about the widget is stored and the WidgetInstance table where the user specific widget information is stored. Since my requirements are that no controls are loaded until the user logs in, the entire generic user system in Dropthings, though cool, is not needed in my application.

So, after login, the process of loading the page is as simple as looping through the returned records and creating an instance of each widget inside its host container.

Lastly I would like to talk about the use of LINQ in the Dropthings project. Now I am not a huge advocate of LINQ, but there are times when it is the only tool that can solve the problem at hand, and I love it for that. What I do not like is that it:
A: Is database specific. Try running LINQ on Oracle or DB2 without purchasing third party plug-in. Sorry, cannot be done.
B: Unless it is watched very closely, the implementers of LINQ cross the data/rules boundary. In Dropthings you find LINQ commands everywhere. If you wanted to roll the Dropthings project out with an Oracle or DB2 back end, you would have a monumental time replacing all the Data access.

So, if the Dropthings project were not so tightly coupled with the data layer and workflow, I think (just my opinion) that the entire system would have benefited.

Which UpdatePanel caused the Post?

Now that is a question! And the answer tool me nearly a day to discover. (OK, all of you that know the answer, stop snickering. I'm just learning the ASP.NET AJAX model)

After many dead ends, here is the key to finding what UpdatePanel caused the Post:
ScriptManager.GetCurrent(Page).AsyncPostBackSourceElementID

This returns the actual element ID that forced the Post. How does this help? Well, any post that originated in a UpdatePanel would be from a child control. So, if you walk up the control tree and find a UpdatePanel, you will have the UpdatePanel that caused the Post.

private UpdatePanel GetUpdatePanelThatCausedPostback()
{
    var c = Page.FindControl(ScriptManager.GetCurrent(Page).AsyncPostBackSourceElementID);

    while (c != null && !(c is UpdatePanel)) { c = c.Parent; }

    if (c != null) return (c as UpdatePanel);
    else return null;
}

Here we get the control that actually fired the Post and then we walk up the control tree, one by one, until we are either past the top (null) or we have found an UpdatePanel.

Then we simply either return the newly found UpdatePaenl or we return null.

Creating a Widget framework in ASP.Net

Note: I've added a label: "widget" for all my posts relating to implementing a Widget framework in Asp.Net.

A recent request at my workplace sent me off looking for a Widget framework for ASP.Net similar to IGoogle and PageFlakes. All I found was Dropthings.

Just like everyone else, after downloading the source code, I loaded the project in Visual Studio and tried to run the solution. After messing with the SQL Express DB for a few minutes, the Dropthings solution fired up with no problems. Well, after playing with the example site for a few minutes I shut the site down and started it back up again, this time walking through the code, one line at a time.

After manually stepping through about a gazillion lines of code, the site finally fired up. Wow, was it really that complex to dynamically load a few widgets on a web page? OK, maybe I was so focused on the trees that I could not understand the forest. So, I tried to step through the click event of the minimize button and ... well, lets just say that there is complex and there is COMPLEX.

Before we go any farther, lets start with a few definitions:

1 - Widget: A self contained application that runs in a subsection of the web page. Widgets usually have header area similar to a windows program and just like a windows program usually have minimize and maximize buttons. Other buttons, such as refresh and edit buttons may also be available.

2 - Widget Container: One or more areas, usually columns, where widgets are displayed on the web page and with drag and drop functionality, between which widgets can be moved and re-ordered.

3 - Widget Based Site: A web site with one or more pages that dynamically display widgets that the user can personalize by adding removing and rearranging widgets.

Now, does such a framework have to be soooooo complex as dropthings? After a deep and long look at the source code, there are quite a few things to commend the author for. There is also a ton of things he needs to be castigated for.

As I endeavor to create a widget based site from scratch, I will blog my successes and failures as well as the elements I found in dropthings that I decided to recreate in my site.