Drag and drop in the Reorderer
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.
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work