Support external drop onto calendar

[GoogleCodeExporter]

Description of the new feature:
Support drop of arbitrary items onto the calendar.

Use Case:
Application has a list of contacts to one side of the calendar.
 Case 1: User drags a contact onto an empty block on the calendar.
         Application responds by creating a new Appointment.
 Case 2: User drags a contact onto an existing Appointment.
         Application responds by adding the contact to the Appointment
         and opening the appointment.

Assumptions:
1. Application code handles creating/updating appointments. gwt-cal only 
notifies that the drop occurred, either on a time block or an appointment.
2. I am assuming that gwt-dnd can handle separate drag/drop controllers for the 
same widgets, as I believe this will require this to avoid conflicting with the 
existing Appointment drag/drop operations.

Exceptions:
None known.

Code / psuedo-code:
To be provided. I will attempt to create and test an implementation, and add it 
as an attachment when done.

Original issue reported on code.google.com by grmcdor...@gmail.com on 14 Jan 2013 at 4:54

[GoogleCodeExporter]

I have implemented a working version. Unfortunately, it is based on a version 
with a click handler (issue 57); when I have disentangled it from that version 
I can supply a patch.

Original comment by grmcdor...@gmail.com on 14 Jan 2013 at 10:32

[GoogleCodeExporter]

In the interim, here is a patch that in addition to this enhancement includes 
fixes for issue 57 and issue 159.

Original comment by grmcdor...@gmail.com on 18 Jan 2013 at 7:49

Attachments:

• calendar-drag-drop-click-touch.patch

[GoogleCodeExporter]

Hi Grant,

Looks like a really nice feature, let me review the changes.

Thanks a lot.

Original comment by ctasada on 22 Jan 2013 at 9:02

• Changed state: Acknowledged

[GoogleCodeExporter]

There's a few issues with the patch, by the way (none major):
 * No highlighting when the drag is over an appointment. This can be solved by CSS, as gwt-dnd adds a CSS class to the target when the drag is over it.

Other issues are more minor, and could be future enhancements:
 * No capability for the application to specify to drag only to empty cells or only to appointments; drag is always enabled for both.
 * No capability for the application to review/veto drags in process (there's stub code for that, though)
 * Drag controller boundary is the root widget. It may be desirable to specify an alternate widget.
 * Drag controller is created on demand, which requires registering all appointments presently displayed with it when created. This is a bit awkward in the day view, as there's no container with just the appointment widgets in it.

Original comment by grmcdor...@gmail.com on 22 Jan 2013 at 9:45