Drag and drop in the Reorderer

Eli Cochran eli at media.berkeley.edu
Fri Oct 12 22:06:58 UTC 2007

(Comments below are for the whole community and are not directed at  
Michelle or Joseph, who are doing yeomen's work teasing out all these  

I think that this calls into question the decision that we made at  
the Summit to standardize on Dojo for our JS development. (And no,  
I'm not gloating.)

Are we saying that we're leaving the field open once again, or are we  
still looking for the holy grail of JS frameworks?

We're always going to find one framework that does X well while  
another does Y well; while one has a great widget for W, another will  
have an even better widget for Z. There is value in settling on a  
single framework. One framework means one style of coding, one  
learning curve, better interoperability,... Seems that the best thing  
is to pick one framework because fits our needs the most closely, and  
then fill in (within that framework) the functionality that is missing.

But maybe I'm off-base here. Maybe, aside from some extra load time,  
mixing and matching JS frameworks and widgets isn't such a bad thing.  
Thoughts? (Do back-end developers get into the same issues when  
picking between JSF and RSF?)

Finally, I'm curious, why did you decide on the jQuery.UI version and  
not the YUI version?

- Eli (jQuery rocks!) Cochran

On Oct 12, 2007, at 1:46 PM, Michelle D'Souza wrote:

> Hi everyone,
> While attempting to upgrade to the 0.9 release of dojo, we  
> discovered that dojo's drag and drop in its current incarnation  
> will not work for the Reorderer. This is due to limitations in dojo  
> DnD's ability to handle certain types of markup - see the trac  
> ticket if you're interested: http://trac.dojotoolkit.org/ticket/4650.
> 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
> 2. Allows nested Reorderers
> 3. Allows arbitrary non-orderable elements and hierarchy
> 4. Not dependent on scanning for css classes
> 5. Name-spaced
> 6. Dojo compatible
> Nice to have:
> 1. Good documentation
> We looked at YUI, Ext, Tool-man, Mochikit and JQuery.
> - YUI passes all the criteria, has good documentation and examples.  
> Actual DOM manipulation requires some hand rolled code. There is a  
> very good example that we could use as a starting point.
> Ext seems to be the same as YUI but with less documentation and  
> examples.
> - Tool-man only supports very simple cases of drag and drop.
> - Mochikit has a bug where it does not work with dojo. There is a  
> work around, but it didn't seem to help.
> - JQuery interface plugin is dependent on scanning for CSS classes  
> and doesn't seem to allow nested Reorderers.
> - JQuery EasyDrag and jqDnR plugins only support simple cases of  
> drag and drop.
> - JQuery UI passes all the criteria, has good documentation and  
> examples. Out of the box it seems to work well with the Reorderer.
> Based on this, we are going to move forward with using the JQuery  
> UI drag and drop for the Reorderer. Please let us know if you have  
> any concerns about this.
> Michelle
> ------------------------------------------------------
> Michelle D'Souza
> Software Developer, Fluid Project
> Adaptive Technology Resource Centre
> University of Toronto
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

. . . . . . . . . . .  .  .   .    .      .         .              .     

Eli Cochran
user interaction developer
ETS, UC Berkeley

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071012/599c5e15/attachment.html>

More information about the fluid-work mailing list