由于我在做一个类似Live.com的东西，所以需要类似WebPart的功能。我不清楚Atlas扩展的那个所谓的Cross Browser WebPart到底是什么，支持如何，所以不敢去尝试，从而决定用DragDropList。
首先，关于如何使用DragDropList，可以参考Dflying的以下两篇文章：
参照第二篇文章轻松制作出WebPark拖放效果来是完全没问题，接下来要做的就是让用户拖放修改后的界面保存下来。这时候ASP.NET 2.0新增的Profile Service就是一个很好的选择，而且Atlas也包括对Profile读写的支持。接着问题就来了，何时能够获取到拖放结束的事件然后更新Profile呢？DragDropList和DraggableListItem没有对外公开任何事件，所以在使用它们快速实现类似WebPart的功能时仅仅能够获得视觉上的效果，无法对它们编程以实现任何有实际意义的东西。
这时候我选择了继承DragDropList来增加对外的事件触发能力，需要做的仅仅是重写onDragEnd方法。感谢Beta1的prototype书写方式，所有函数都是virtual的，这给重写带来了方便，不需要再用registerBaseMethod覆盖掉基类的函数。重写如下：
function MyDragDropList$onDragEnd(cancelled)
{
debug.trace(cancelled);
MyDragDropList.callBaseMethod(this, "onDragEnd", [cancelled]);
this._dragVisual.style.width = null;
this._dragVisual.style.height = null;
this._dragVisual.style.zIndex = null;
}
debug.trace(cancelled)在这里是做演示作用，真正放在此位置的应该是一条触发事件的指令，甚至可以根据cancelled值决定是否触发，因为若它为true则实际上拖放没造成任何变化。
后面对样式属性的删除又是什么呢？这是对DragDropList某一个bug的work around。在拖动过程中，由于拖动的DomElement（也就是this._dragVisual）脱离了它原本的上下文，如果它原本的样式属性是100%那就会出问题，所以DragDropList取了它的offsetWidth属性来作为它的width，这样width的单位就一定是px。然而这却造成了另外一个问题，拖动后DomElement的width变成了一个单位为px的值，用户缩放浏览器时它就不能跟随缩放，这不符合我在CSS文件中定义width的单位为%时所期望的。于是我就在拖放结束后删除DragDropList对此DomElement样式的影响，让CSS文件定义的样式重新成为当前样式。
最后，提供一篇我觉得比较有价值的文章，方便大家实现自己的IDragSource和IDropTarget：Drag and Drop with Atlas: interfaces。文章中详细解释了这两个接口的各个方法，比起你自己去研究DragDropList的代码要简单一些。