Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Automatic handling of form reset #271

Closed
fidian opened this Issue Jan 15, 2013 · 1 comment

Comments

Projects
None yet
2 participants
Collaborator

fidian commented Jan 15, 2013

Issue #270 could have been avoided entirely if Uniform detected and responded appropriately to form reset events. Unfortunately, I don't know if this feature would cause more problems than it solves, plus I'd want it to work in a really generic way. Since input elements don't need to be in a form or can be in multiple nested forms or can be automatically added/removed at a whim, the simple solution of binding to $('form').on('reset', ...) is problematic. We'd need to find the parent form, then all child elements that are uniformed. Or, perhaps a manual reset button/link is used and we need to somehow tie into that.

Due to the difficulties I currently see, I'm making this a feature request but am not implementing it for 2.0.x.

Owner

shehi commented Aug 26, 2016

@fidian , issues such as (from those I resolved recently) #348 and #349 also were related to this issue. But it is my firm belief that handling certain action mechanisms shouldn't be Uniform's responsibility. The sole goal of this package is to "style" form elements, simple as that. And in doing so, it is responsible of making sure when form elements are transformed to Uniform'ed state (i.e. uniform()) or the other way around (restore()), the values are preserved and are accurate. I realize the fact that form reset changes values as well, but to be honest, a lot of mechanisms actually change values when we start coding an interactive layer for our web views. Ultimately, we handle them ourselves, no plugin does that for us. So instead of creating event binders and potentially causing a confusion especially for new developers who hardly can capture event handlers and reuse them, I say we stay completely out of that business. The fewer bindings/event-handling we do with Uniform, the easier the task of this package will be - meaning, Uniform should strive to leave as few footprints as possible as it performs its job.

To that end, just to resolve this "reset" form issue, our users should just update their form elements via update() through setTimeout() with a millisecond delay, to avoid potential race condition, where Uniform sometimes acts sooner than browser manages actually to finish its native reset event:

$("input[type='reset']").click(function(e) {
    setTimeout(function () {
        $uniformed.uniform.update();
    }, 1);
});

That's it, this completely solves our reset problem. From here on, we will only have performance problems, tied to the speed of update(), but that's rather general problem, not necessarily related only to this reset issue. When we solve performance issues (for forms where up to hundred form elements need uniform-ing), we will solve all related problems as well.

To that end, I am closing this issue once and for all.

@shehi shehi closed this Aug 26, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment