Curb the Belly of the Beast: Drag & Drop ServerRequest-Hell And Icefaces

Icefaces supports drag-and-drop functinality regarding its component-library. For sure its easily to implement with much more issues afterwards. Some things brought me almost to cry. If you have a droplistener on your dropArea, your calling event does probably  not bearing your dragged value.



#{workflowTask.name}

Drop Target 1

As you can see, the dropping zone posseses an appropriated dropListener. The regarding Java-Code seems correct for me as well:

   public void addTaskDestinationToTransition(DropEvent event) {
		if (event.getEventType() == DndEvent.DROPPED) {
            String targetId = event.getTargetClientId();
            if ((targetId != null)) {

               WorkflowTask  workflowTask = (WorkflowTask)((HtmlPanelGroup) event.getComponent()).getDragValue();
              ...
            }
        }
	}

But it doesnt matter what i do, the DragValue seems alway be null. Its a bug in IceFaces 1.7.2SP1. Well, be smart, and add instead a dragListener that makes somethin similary. Simply add a dragListener to the dragged component and change the argument of the java-method to DragEvent.

If its done, you run into another problem that seems much harder for me.The dragged component (if its in a drag-state on push the component away from its current place) reverts its state after a few seconds without doing anything. You just holding down the mouse on the left mouse button and moving it on the page up and down…

How can we curbing this issue? Well, at first you have to grasp mostly every reaching of a dropping zone or even moving of the dragging-component invokes an AJAX-Request. And you know, you move the mouse not in everycase straigh forward to the finish-line but more in “flowing-movements” up and down. This increases excessively Pages-Requests that must be avoided. In most cases you dont have an “localhost-infrastructure” rather than a WAN-Landscape wher people will connecting to youre site from india or australia. Its a pidy about that tcp-packet-exchange!!

Well, for me i have implied that this problems belongs to this AJAX-problematic. So if we can stop sending traffic-jam to Skynet we can probably farily increasing our drag-and-drop behaviour.

Icefaces comes along with “sendmasks” which nothing less then descriptive flags about information-states that have to be sent to the server. For instance, if you want to know when a user starts an dragging-operation, this can be exposed as such a flag. Normaly you dont want bother the server (and your self) with such logentries. The only thing you likely want to know is WHAT you´ve dropped- not WHEN OR WHO. So therefore we using the attribute dragMask in every dragging-component to constraining the send-behaviour:



#{workflowTask.name}

Comments

Leave a Reply




Security Code: