Skip to content
This repository has been archived by the owner on May 16, 2021. It is now read-only.

Automatic handling of form reset #271

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

Automatic handling of form reset #271

fidian opened this issue Jan 15, 2013 · 1 comment

Comments

@fidian
Copy link
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.

@shehi
Copy link
Member

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 as completed Aug 26, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants