Changes between Initial Version and Version 6 of Ticket #6219


Ignore:
Timestamp:
Jul 24, 2008, 11:10:37 AM (12 years ago)
Author:
Sam Foster
Comment:

Its important that if we do allow a user to subscribe to splitter events including ther ondrag/onmove event - which fires very frequently - that we dont incurr a performance loss disproportionate to the amount of work that handler really needs to do. With that in mind, it would be ideal to be pretty granular about exactly which splitter, and which phase of the drag you were interested in recieving events from. That presents a potential problem in the proliferation of topics - particulaly if you wanted to e.g. subscribe to any splitter drag event

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #6219

    • Property Cc Sam Foster ptwobrussell Adam Peller added
    • Property Owner set to Sam Foster
    • Property Milestone changed from to 1.2
    • Property Summary changed from Add public drag notifications to BorderContainer to BorderContainer: Add public drag notifications
  • Ticket #6219 – Description

    initial v6  
    1 It would be nice and there are certainly use cases for being notified for when drag events begin and end. Right now, you have to dip into "private" stuff to pick this up; exposing the functionality via a public function that you could connect to would be nice. sfoster also seems to have had a use case for this, so that makes at least two "regulars" that think it would be helpful. Should be  a trivial patch.
     1Following discussion in #dojo, I'll create onMove, onMoveStart, onMoveEnd stubs on the splitter, and a getSplitter api on the BC to allow connection to the invidiual splitter events.