-
Notifications
You must be signed in to change notification settings - Fork 647
Simplify sfMessage directive and uses #387
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
Simplify sfMessage directive and uses #387
Conversation
update(scope.ngModel.$valid); | ||
} | ||
template: '<div ng-if="!error && form.description" ng-bind-html="form.description"></div><div ng-if="error" ng-bind-html="error"></div>', | ||
controller: ['$scope', function($scope) { |
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.
Just curious, why controller instead of link?
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.
It would actually be better written as link – I'll go ahead and do that. My first iteration actually used both (one to compile the element, the other the way it is). I'm going to change this back to link :) good catch!
Hi @mike-marcacci, thanks for the PR! One thing though, would you mind redo it without the files in I've commented a bit above as well, am I right to presume its the two way binding with description that is the main problem here? |
Hey @davidlgj sorry for the slow reply! Been a crazy week. Yes, you're correct that the auto-binding is what I'm really after. I get what you're saying about custom add-ons wanting to use a field with a name other than I'll go ahead and remove the |
There's no need to overthink sfMessage; in all cases it uses the parent scope's . This allows faster processing, and full data-binding so that an application can modify descriptions on-the-fly.
I've started some tentative work on an angular material decorator, I'm going to see where that goes, but it might be that we don't want descriptions at all there! Anyways, if I don't merge this as it is I'll at least try to fix up the binding. Edit: I guess I'm saying give me some time :) |
Yes, so currently in the budding material decorator, https://github.com/Textalk/angular-schema-form-material we're using sf-message without description at all. Would it be OK to reject this PR if I implement a watch on the description so its always updated? |
Absolutely! Thank so much for the politeness :) I'm really excited to see how that material decorator, ahem, materializes |
Great! I'll try to get the watch done today. Checkout the development branch, it's starting to come together, inputs, textarea, selects and checkboxes sort of work. @Anthropic is doing some awesome work on it! |
I've made a watch on description in development branch, e7ff94b Seems to work(TM) :) |
After discussion in json-schema-form/angular-schema-form#387
There's no need to overthink sfMessage; in all cases it uses the parent scope's
form.description
. This allows faster processing, and full data-binding so that an application can modify descriptions on-the-fly.