please bring back _registerInternalEvents to enable plugins to override them #4984

Closed
asyraf9 opened this Issue Sep 13, 2012 · 10 comments

4 participants

@asyraf9

hi guys, this is more of a request than an issue.

before JQM 1.1, all form submit, click, and hashChanges were defined in a single object called $.mobile._registerInternalEvents. this was called upon init to bind all the necessary navigation events to allow JQM's page navigations to happen.

now in the latest JQM version, all these handlers are bound in a callback that is tied to $.mobile.navReadyDeferred. this is awesome too, but i don't see a way for me to unbind or override these handlers, or even to remove the callback from the deferred and put mine in - except maybe, to do stopPropagation in my handler - which can be extremely buggy.

I love the _registerInternalEvents implementation - it allowed me to completely rewrite all the navigation event handlers in my splitview plugin - which was important, since I'm working on multiple pageContainers at one time.

so, I would like to propose that we bring that back, or namespace all the event handlers, or if you have a better idea how i can overcome this issue without changing core - even more welcome. thanks for the awesome work guys.

@asyraf9

btw, the change is fairly small, I can issue a pull request should that be necessary

@jaspermdegroot
jQuery Foundation member

@asyraf9 - Would be great if you can create a PR for this that we can review.

@asyraf9
@gabrielschulhof

@johnbender

I guess we can do this fairly easily like this.

@asyraf9
@gabrielschulhof

I'd rather not change when we attach the done callback. Instead, let's do it like this. If the function stored at $.mobile._registerInternalEvents has changed by the time the done callback executes, then we shall have this nailed.

@johnbender

@asyraf9

This puts us in a really tough spot.

On the one hand the change that @gabrielschulhof has proposed is fairly trivial and it appears as though it would help you out.

On the other hand this is a private method and we are already at the release candidate stage. 1.2 was in beta for something like a month when we could have made this change without concern. Again, it seems really trivial but making any code change during an RC is a risk.

It looks like user's of your plugin will have to wait for the next patch release to upgrade :(

@asyraf9

@gabrielschulhof loved that solution. thought about it yesterday and began testing it but saw that you'd beaten me to it here :) thanks. i'll issue a new PR for 1.2.1

@johnbender not to worry - please proceed with releasing 1.2 without this. I'll provide a modified version in my repo. sorry i hadn't asked for this earlier - i haven't been using my own plugin for a while, but each time jqm goes to beta or RC, my inbox gets full - had to do something heh.

@johnbender

@asyraf9

I should have added that the only reason it puts us in a rough spot is that we care about supporting community plugins. We really can't handle every use case internally and so we rely heavily on people like you to fill in the gaps.

We'll push to get 1.2.1 out quick in the meantime, and thanks again for contributing.

@asyraf9

You guys have been great. It's been a pleasure really. thanks!

@gabrielschulhof gabrielschulhof added a commit that referenced this issue Oct 2, 2012
@gabrielschulhof gabrielschulhof [navigation] Re-instate $.mobile_registerInternalEvents - thanks asyr…
…af9 -- Fixes #4984, #5059

Conflicts:

	js/jquery.mobile.navigation.js
9de514c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment