Drag and drop in the Reorderer

[Colin Clark]

Hi Daphne,

These are good questions. I think everyone should feel free to ask for 
clarification on these kinds of technical issues that are also 
fundamental to how our components are used.

Let me see if I can take a shot at being an educator here, as you say. 
Explanations below.

Michelle said:
>> Anastasia, Joseph and I spent yesterday and today evaluating other 
>> drag and drop solutions that we can use in place of dojo's. Here are 
>> the criteria that we used for selecting a drag and drop solution:
>>
>> 1. No assumptions about DOM structure beyond 
>> - a known container describing the boundary of the Reorderer
>> - identified orderables

The Reorderer should be able to work with all kinds of markup. For 
example, it should be possible to move items around that are positioned 
inside a table. Or items that are nested within lists. And so on.

The one thing the Reorderer should expect is to be told explicitly which 
elements are orderable, and in which portion of the document they live. 
It shouldn't assume that everything within the Reorderer's container is 
actually orderable, only those things that have been specifically 
denoted as such.

>> 2. Allows nested Reorderers 

The Reorderer should work with other Reorderers inside it. This can get 
very complicated from a technical perspective, but has a very clear and 
simple use case:

We're in the process of using the Reorderer in uPortal, allowing users 
to rearrange their portlets on the page in an accessible way. Now, what 
if one of those portlets contained the Gallery, which also uses the 
Reorderer to power the Lightbox?

 From the user perspective, these are completely different cases of drag 
and drop. So our drag and drop library has to understand the difference 
between these two instances of the Reorderer. For example, it shouldn't 
allow users to move a portlet into the list of images in a Gallery 
collection!

>> 3. Allows arbitrary non-orderable elements and hierarchy

You should be able to intermingle orderable and non-orderable elements 
in the markup. For example, our default approach to communicating image 
order in the Lightbox relies on a set of hidden form fields embedded in 
the markup, one per image. Some drag and drop toolkits assume everything 
within a container is orderable.

>> 4. Not dependent on scanning for css classes

A lot of DHTML solutions use a technique of searching the document for 
any elements with a particular CSS class. At the moment, the Reorderer 
actually searches for elements with a CSS class of "orderable." This 
will break in a portal where we may have nested Reorderers, and is 
something we're going to fix for the 0.1 release. So we definitely don't 
want our drag and drop library to impose this restriction on us.

>> 5. Name-spaced

Once again, namepacing in JavaScript is a prerequisite for 
portal-friendliness. It just means that the code should be 
self-contained and not conflict with any other arbitrary JavaScript code 
that may be running within the same page.

Does this help?

Colin

-- 
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org