Drag and drop in the Reorderer
colin.clark at utoronto.ca
Tue Oct 16 01:05:04 UTC 2007
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.
>> 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
>> 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
portal-friendliness. It just means that the code should be
that may be running within the same page.
Does this help?
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work