I totally agree with all of your comments. Specifying invocation order of the event handlers is not reliable and leads to more problems.
I can hook up event handlers to all my date input text fields that uses a date picker to update the range of the date picker whenever there is a change to the current value. However, it also means that I need to do it at the initialization time since these date fields have pre-filled date values. That makes it... less DRY (Don't Repeat Yourself). I think to add a callback event to the date picker plugin is the way to go. So I have submitted a feature request on this plugin and simply going to modify it myself for now before it is implemented. Thank you for helping me out on this issue, very much appreciated! On Jul 22, 10:58 am, Dave Methvin <[EMAIL PROTECTED]> wrote: > > The question is actually separated with the above problem. Many event > > handlers are registered using the bind() call. In those cases, how can > > we further manipulate them using JQuery? Such as replace them, or > > change the invoking order of these handlers? > > Notice that the docs for AddEventListener say "Although all > EventListeners on the EventTarget are guaranteed to be triggered by > any event which is received by that EventTarget, no specification is > made as to the order in which they will receive the event with regards > to the other EventListeners on the EventTarget." > > http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarge... > > jQuery has its own internal event mechanism, and could provide a way > to affect the calling order. However, in a page with several plugins > and with elements being added/removed dynamically it would probably > not help. If there was some additional argument to bind() that said "I > should be called first (or last)" it would run afoul of the same > problem--what if multiple handlers want to run first? Plus it's an > abstraction nightmare--how am I to know that my handler should run > before one in a plugin whose internal design I don't undersand? I have > a feeling this led the W3C to avoid specifying the order of handler > calls. > > So, if that's off the table, the solution would have to involve > removing the dependency between the click handlers. > > > The more specific detail of the problem: I am using the datePicker > > plugin, which creates a clickable link and registers an event handler > > Does datePicker have a way to change the date range long before the > click handler runs? For example, if something on the page causes you > to need a change in the date range, you could do it then rather than > wait for the click event that DatePicker handles. > > Another possibility would be to add a line in that datePicker click > handler that either triggered a custom event to let you change the > date range before the calendar is displayed. That sounds like a useful > thing to have in the plugin anyway.
