Drag and drop in the Reorderer

Michelle D'Souza michelle.dsouza at utoronto.ca
Mon Oct 15 16:07:19 UTC 2007

Thanks for the comments Eli. This is a very important issue that we  
need to work out in the community. Please see my responses below.

On 12-Oct-07, at 6:06 PM, Eli Cochran wrote:

> (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 issues.)
> 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.)

At the summit we decided to use Dojo for JS development based on the  
accessibility work that has been put into Dijit (their widget set).  
My understanding of that decision is that for widgets we will use  
Dijit but for framework level things we can use the toolkit that most  
meets our needs.

Let me back up a bit and give a little more context for why we  
started looking for another drag and drop solution. Coming out of the  
work that Anastasia, Eric and Joseph did at the summit, we want to  
implement the Reorderer in uPortal for the December release of  
uPortal 3. Given the current Dojo implementation of drag and drop  
this is not possible. In the mock up that was put together using the  
Dojo 0.9 beta, the drag and drop behaviour changed the uPortal markup  
enough to make uPortal unusable. In the Dojo 0.9 release matters are  
made worse due to more restrictive constraints around markup that  
drag and drop will work with. Essentially, drag and drop in the  
Reorderer will not work in both the sakai gallery lightbox and  
uPortal using the Dojo 0.9 release.

> 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?)

We did discuss the user confusion that may be created by mixing  
widgets from different toolkits - the argument being that widgets  
from different toolkits will look and feel different.  We probably  
need to look at specific cases to know whether or not this is true.

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

The YUI version required us to write some extra code while the jQuery- 
UI version appears to work seamlessly with the Reorderer out of the box.


Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071015/7cff2382/attachment.html>

More information about the fluid-work mailing list