-
Notifications
You must be signed in to change notification settings - Fork 649
Feature: clean model when a field is removed from view, such as when a condition is no longer satisfied. #371
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
Merged
davidlgj
merged 11 commits into
json-schema-form:development
from
jbsaff:feature/cleanModelUsingDestroyStrategy
May 10, 2015
Merged
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
3ab26b4
Update README.md
Dervisevic e5c6183
Update README.md
Dervisevic 3353cca
Extended schema-validate directive to handle cleaning the model when …
jbsaff 896ec3e
Additional doc example.
jbsaff e73bfe2
Part of another branch pull request.
jbsaff 76a562c
Fixes from code review in #371. Reworked the default destroyStrategy …
jbsaff 0d6f417
Removed extra console logging.
jbsaff 4568337
Only clean model if the form's condition is no longer satisfied. This…
jbsaff 4d72f3d
Merge remote-tracking branch 'origin/feature/cleanModelUsingDestroySt…
jbsaff d20b273
Remove extraneous console log.
jbsaff dcff62b
sfSchema can communicate via sfRetainModel service to force the model…
jbsaff File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
angular.module('schemaForm').factory('sfRetainModel', function() { | ||
|
||
var data = {retainModelFlag: false }; | ||
|
||
return { | ||
/** | ||
* @description | ||
* Utility service to indicate if the sfSchema model should be retained. | ||
* Set to true to prevent an operation that would have destroyed the model | ||
* from doing so (such as wrapping the form in an ng-if). | ||
* | ||
* ex. | ||
* var foo = sfRetainModel.getFlag(); | ||
* | ||
* @returns {boolean} returns the current value of the retainModelFlag. | ||
*/ | ||
getFlag: function () { | ||
return data.retainModelFlag; | ||
}, | ||
|
||
/** | ||
* @description | ||
* Set the value of the retainModelFlag. | ||
* True prevents cleaning the data in the model, while false follows the configured destroyStrategy. | ||
* | ||
* ex. | ||
* var bar = sfRetainModel.setFlag(true); | ||
* | ||
* @param {boolean} value The boolean value to set as the retainModelFlag | ||
* @returns {boolean} returns the value of the retainModelFlag after toggling. | ||
*/ | ||
setFlag: function(value) { | ||
data.retainModelFlag = value; | ||
return data.retainModelFlag; | ||
} | ||
} | ||
}); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was looking through the code and testing some, and I'm not quite sure why we need to check on the condition here? Shouldn't we always just follow the destroy strategy if we get a destroy event? I'm thinking that condition might not be the only thing that can remove a form element from the form, any other add on might use a
ng-if
somewhere and since any field not in the DOM won't get any validation done on it anyways It's probably best to remove it from the model.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had left it in as a way to help show where I was coming from with my solution, because I wasn't 100% confident that the service I put in would be correct (I'd still label myself an apprentice with Javascript). Assuming that the flag will handle for the case where the destroy is coming from outside of the form, then I agree that destroys initiated within the form should just follow the destroyStrategy. It'll be more consistent (and still configurable) and easier to explain.