Skip to content

Should conditional type evaluation destroy data? #204

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

Closed
Anthropic opened this issue Jan 8, 2015 · 6 comments
Closed

Should conditional type evaluation destroy data? #204

Anthropic opened this issue Jan 8, 2015 · 6 comments

Comments

@Anthropic
Copy link
Member

I have an attribute directive I applied to my own decorator to remove data that was in elements hidden by a conditional type evaluation.

Should this perhaps be included in the main angular-schema-form behaviour?

(function(window, angular, undefined) {'use strict';
  angular
    .module('schemaForm.extension',[])
    .directive('destroyHiddenData', ['oySchemaFormUtil', function(oySchemaFormUtil) {
      return {
        link: function(scope, element, attrs) {
          scope.$on('$destroy', function(){
            if(scope.form.key) oySchemaFormUtil.setKeyValue(scope.model, scope.form.key, '');
          })
        }
      };
    }]);
})(window, window.angular);

Note: the oySchemaFormUtil is my own function that just manipulates data based on key, but unlike the built in one it also allows for total deletion which is why I use it instead. Not relevant to discuss in this post thread.

@davidlgj
Copy link
Contributor

Yes, this might be a good idea... It would make conditional even more useful.

Maybe an option to turn it off if needed?

@Anthropic
Copy link
Member Author

I would suggest that the option allow for setting the value to a user preferred ( null, undefined, empty string or the current behaviour of do nothing) value, as in many cases it completely depends on how they then save the data to their database.

@Anthropic
Copy link
Member Author

Upon reflection I would like the default behaviour to set the value to null. It should not delete it as that is not ideal in JavaScript and the back end will need to be able to see changes without relying on every field always having a value.

@jbsaff
Copy link
Contributor

jbsaff commented Apr 28, 2015

@Anthropic I took a stab at this feature in #371. I opted to use undefined instead of null, as that would most closely represent the state of how the user experienced the form (they don't see the question, so it never should come up in the model). However, I did include a check for a formDefaults definition of the destroyStrategy, which would allow for the entire form to use null as the mechanism for destroying data that has been hidden.

@Anthropic
Copy link
Member Author

@jbsaff great, I will keep an eye on it :)

@Anthropic
Copy link
Member Author

Completed by #371

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

No branches or pull requests

3 participants