Drag and drop in the Reorderer

[Daphne Ogle]

Yes.  Very helpful.  Thanks!

On Oct 15, 2007, at 6:05 PM, Colin Clark wrote:

> 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

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071016/151e4fb5/attachment.html>