Reorderer component in v 0.3

[Colin Clark]

Damian,

Comments inline...

On 24-Jul-08, at 2:37 PM, Sobieralski, Damian Michael wrote:
> I got the callback to work on drop. YAY!

Awesome!

> My DOM looks something like this:
>
> <div class="orderable_container">
>  <div class="decoration_div"></div>
>  <div class="orderable_item"></div>
>  <div class="decoration_div"></div>
>  <div class="orderable_item"></div>
>  <div class="decoration_div"></div>
> </div>
>
> The decoration_div actually has some functionally so it's not really  
> a decoration div but let's keep it this way for this example for  
> simple illustration.  So basically any orderable_item has a  
> decoration div before and after it.  So when we pick up the  
> orderable widget, we need to remove the decoration widgets that once  
> surrounded it "intelligently". And, of course, when dropped we need  
> to see what (if any) decoration divs need to exist in the just  
> reordered orderable_item's new home.
>
>  A pickup callback would allow me to quicky see who the orderable  
> div's neighbor's are and zap them before I am moved around in the DOM.

We definitely need to add a pickup callback. It's on the list for the  
0.5 beta release next month.
  In the meantime, let's see if we can come up with a workaround...

>  I CAN after drop traverse the DOM looking for irregular decoration  
> divs'....but we have so much JS now that our client stuff is getting  
> pretty slow as is. We have large pages and adding a full traversal  
> of orderable_container to clean up the decoration divs would be very  
> time costly for us.

I agree. Trolling the DOM looking for your decorator divs could end up  
being quite slow. Here are a couple alternatives that might work for  
you.

1. Are the decorator divs actually visible? If not, is it possible to  
wrap them, along with the orderable item, in a container div and mark  
the container as orderable?

In other words, is it possible to move both the item and the  
decoration divs at the same time? We do this in the Lightbox markup,  
where we have hidden form fields nested inside that are used to POST  
the response back to the server. Here's an example:

<div class="orderable_container">
      <div class="orderable">
          <div class="decoration_div" id="item1-decoration"></div>
          <div class="orderable_item" id="item1"></div>
      </div>
</div>

2. If that doesn't work, here's another option. We've modified the  
orderChangedCallback so that you are given the item that was just  
moved. It looks like we'll be able to get this into Infusion 0.4,  
which will be released on Wednesday.

Assuming you knew the item that was just dropped, could you then  
quickly figure out which decoration div needs to be updated? For  
example, a simple id-based scheme could work:

<div class="orderable_container">
  <div class="decoration_div" id="item1-decoration"></div>
  <div class="orderable_item" id="item1"></div>
  <div class="decoration_div" id="item2-decoration"></div>
  <div class="orderable_item" id="item2"></div>
  <div class="decoration_div" id="item3-decoration></div>
</div>

In your callback, you'd do something like this:

var myOrderChanged = function(droppedItem) {
     // Wrap the dropped item in a jQuery.
     droppedItem = jQuery(droppedItem);

     // Fetch the decorator based on the id of the dropped item.
     var decoratorForItem = jQuery("#" + droppedItem.attr("id") + "- 
decorator");

     // Move the decorator to its new position.
     decoratorForItem.remove().insertBefore(droppedItem);
};

Again, this is a workaround, but it might do the trick. Let me know  
how it goes, and if you're still stuck we can see if there's something  
else we can provide for you.

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org