-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing Validation Group Issue #1
Comments
Hi Justin. Thanks for the fiddle. I will give it a glance this weekend. |
I think I have a hack that will work. I'll send it to you tomorrow. The
|
After much debugging, I found two key problems:
|
I saw that same behavior too. I tried debugging but I couldn't locate where I wonder if using the JSON.stringify may be a more generic solution to On Sat, Feb 9, 2013 at 6:33 PM, Carl Schroedl [email protected]:
|
Sorry for the delay in response. I did some more debugging and I still can't find the origin of the ghost rules. Thanks for your idea about JSON.stringify -- I like it. It might force us to make our constraint group definitions really verbose in order to trigger equality between the strings though. Do you see any way around that? I suppose we could do this: var comparisonStringMadeFromConstraintGroup = JSON.stringify(ko.utils.extend({ all: 'of', the: 'default' rule: 'properties' }, theConstraintGroup)); //set defaults, overwrite values if present in the constraintGroup we're removing //then iterate through the rules and match stringified rule objects to comparisonStringMadeFromConstraintGroup If I go this route I would want to closely examine ko.validation's default rule objects for all of the builtin validators. In the words of Jackie Chan Adventures: |
I thought of another way. The best way of ensuring exact removal of constraintGroups would be to give every constraint group a unique ID and attach that ID to every rule on every observable involved in the application of a particular constraint group. When you need to remove a constraint group, iterate through all the view model properties involved in the constraint group, iterate through all of the rules for each property, and remove rules where the rule's constraintGroupID matches the ID of the constraintGroup that we have asked to remove. This way removes the need for expensive JSON.stringifys and the dependence on ko.validation's rule object format, provided we are still able to add a constraintGroupID property. I'm fiddling with this idea here: http://jsfiddle.net/carlschroedl/y2MaA/ It's still a work in progress. Hop on if interested. |
Justin, I have implemented the group id fix I mentioned above. It relies on a miniscule change to Knockout-Validation. Please voice your support on the pull request I sent to Eric so that the functionality gets incorporated: In the meantime, feel free to rely on my patched version of Knockout-Validation and this new branch of ValidatedViewModel that contains the fix. |
Although this thread is quite old the solution is to add |
Hello,
Thank you for your library. I really like it. However, I am stuck with a small problem. I am trying to build a screen to manage network settings. You can choose either DHCP or Static IP addresses using a radaio button. The addressType is bound to the radio buttons. When the user changes the addressType, I have a subscription that will toggle the validation group for the 'static' rules. Basically the static rules group just validate that the IP, Netmask, and Gateway are required and valid IPs. The problem I am seeing is that even after removing the validation group for static, by choosing the "DHCP" radio button I am still seeing 3 validation errors for the validation group that was removed.
I created a fiddle demonstrating this. If you choose the "DHCP" radio button, then click the "Test" button, there should not be any errors since the only required field is addressType and it has a value since the radio-button was checked.
Can you see anything that I am doing wrong?
http://jsfiddle.net/jspradlin/YmjGR/
Thanks in advance,
Justin
The text was updated successfully, but these errors were encountered: