RegisterExtenders invoked before Init, cannot avoid adding rules to ko.extends.

[slaneyrw]

There is an option to set registerExtenders to false when init is invoked to bypass registerExtenders, but the bootstrap has already executed kv.registerExtenders ( ~ line 914 )

//now register all of these!
(function () {
    kv.registerExtenders();
}());

You cannot avoid registering all the rules as ko.extensions

[crissdev]

@slaneyrw Indeed, you cannot prevent the rules from being registered during init, but why would you need this? You can change / remove / replace the builtin rules quite easily. Can you provide a use case for this? Thanks.

[slaneyrw]

To avoid a clash of registered extenders.

[crissdev]

I would recommend choosing unique names for your custom rules. But the problem I currently see is that although we have a registerExtenders option it cannot be used. I will look into this more and see if either I'm wrong or it can be fixed.

[slaneyrw]

It's not only custom rules, but you are also competing with all other knockout extenders. for example, I had a number extension that forces all values into an observable to be converted into a number ( as knockout will push in a text value if bound to an input ). The number extender from the validation library overwrote mine forcing me to rename my custom extender.

[crissdev]

@slaneyrw Sorry for the delay on this one.

Until some sort of solution is found for this you may choose to code an unregister method like the following:

function unregisterExtenders() {
    for (var ruleName in ko.validation.rules) {
        if (ko.validation.rules.hasOwnProperty(ruleName)) {
            if (ko.extenders[ruleName]) {
                delete ko.extenders[ruleName];
            }
        }
    }
}

This method will leave the other extenders like validation and validatable intact, so you can use your own custom rules with no problems.

[crissdev]

@slaneyrw Some work is done in this direction and it would be great to have some feedback on it. See branch issue-545 and related issue #545. Thanks.