jQuery UI: Droppable Fundamentals

The draggable and droppable jQuery UI interaction components are cool.  But it turns out that after a recent experiment, I discovered a few things I had gotten wrong with the widgets in the past.  For example, reverting the draggable back to its original position on a failed drop, highlighting the droppable target while dragging, and changing the state of the draggable while dragging.  These are just the visible behaviors that help the user out.  There are a few things I'd got wrong with the code in the past too, so I've put together an example to illustrate some fundamental principles when working with these interactions.  Check out the comments in the code.

jQueryUI UML

The jQueryUI Javascript user interface library has some interactions that would be well-suited for a UML canvas. For instance, the draggable interaction is essential for moving modeling elements around. Same with the selectable and resizable interactions. The main challenge would be creating the widgets that represent the UML modeling elements.

Transactional Javascript API Interaction

Any meaningful javascript application is going to make use of some kind of application API that lives off on a server somewhere. Generally, some user interface triggers some event which, in turn, will send a request to a remote API. These requests are generally asynchronous. That is, the request happens in the background while the user interface is still responding to events. The number of API connections and requests can add up rather quickly. Even if the data sent over the network for each request and corresponding response are relatively small, there is still the overhead involved with assembling the request.

Using a transactional javascript API access pattern can help cut down on network bandwidth. This is done by minimizing the work done by the API on a given request. Additionally, we also cut down the response size for a given request. The bandwidth consumption will grow to a much larger size if each API response is sent to the javascript application in a single HTTP response. It would be nice if a single HTTP response could contain multiple API responses. One potential solution is to only return a transaction id for each transaction request. The javascript can then store this transaction id. At the core of the javascript application would be an interval that would check the API for completed transactions and their corresponding responses. This approach is illustrated below.