-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Refactor Field validation #2169
Comments
The base Field now calls the validator as part of the constructor. There is still additional cleanup to fields:
|
I ran into this while working on the custom fields demo. Problem Statement
ProposalRefactor setValue on the base class to be a template that looks something like this:
(Plus null checks, sameness checks, events, etc.) This way the developer could just define the 'do' methods, and know they aren't forgetting anything. And it would be easier to debug because we would know the path would be the same every time. Also great is that if anyone has overriden setValue this is still backwards compatible because all of the changes would be on the abstract field class. How does that sound to you peoples? |
@NeilFraser do you have any thoughts on this? |
I think @BeksOmega's suggestion will work, and it looks like it'll work for backwards compatibility. This is another case where we should have tests that are the same before and after, to verify that existing implementations continue to work. |
Sometimes fields check if they are attached to a block before validating new values, is this the intended behavior? It looks like this was originally inteded to support headless workspaces? but I think headless workspaces would want their values to be validated as well. Here's the original commit. Do you remember why this was added @NeilFraser ? |
I'm not sure why we do that for text inputs. We do something similar for variables; that's because the set of variables that exists depends on the workspace, and the field doesn't have a pointer to the workspace--but the source block does. |
Note on this: The field side of this has been fixed, but the events side also needs to be fixed. For example, if a function-caller-block is notified that the function-definition-block's text input value has changed, and goes to change its label value, the setValue call to change the label will start a new group. This breaks undo. So the grouping functionality needs to be reworked. |
Closing as the original issue is fixed, and I think the secondary events issue was a misdiagnosis of the problem. |
Problem statement
Currently,
field.validator_
is called in some of the methods of classes that inherit from Field, but not called in the Field class itself (whether bycallValidator(..)
or more direct methods). When and where the validators are called in the field classes is not standardized and therefore makes coding and fixing bugs for all field types difficult. It would therefore be more consistent to have thecallValidator(..)
method called in the Field setValue method.The text was updated successfully, but these errors were encountered: