I have a field that needs to be automatically managed in the background. It’s fairly critical to the data integrity of my model, therefore it’s a required field.
The problem is that I don’t want to deal with setting this field in every place in the app I use the model. I had set it up to self-manage in beforeSave() but this failed because beforeSave() is never even called if validation fails, which it does if the field is missing.
I solved this by taking it out from the required in the validation rules and then taking care of setting it in beforeSave().
But I don’t like that. I would feel better about keeping it marked as required and simply having something like a “beforeValidate()” where I can check for these kinds of things and choose how to deal with them.
I couldn’t find any such method in the docs, but I feel like there’s a good chance I simply missed it. If someone knows, let me know. If no such method exists, I hope someone considers this as a decent feature request to add in.
I’m not really sure when those events fire in the sequence.
The specific issue I’m having relates to the validationDefaults triggering an error that prevents beforeSave from firing. This is not a directly user-managed field, but rather one that I manage in the background depending on user actions (it’s the sort order of a list) that has a unique constraint in the database (across the entity + parent entity).
So, I need to intervene, depending on things the user does before saving the data, and update the value of that field (for one or more records).
My workaround was to remove the validation rule for that field in the model. Now I can perform my logic in beforeSave(). That workaround makes me uncomfortable.
beforeMarshall fires before the data is marshalled into the entity, which I think is also when basic validation is done. beforeRules is fired after basic validation but before the rules are run. Hence the question about whether it’s validation or rules that’s tripping you up. (I know you said “validation” but a lot of people use that to refer to both of the processes together, and it’s important here to understand which one you mean.)
But if that field is only ever going to be set by your code, then why are you uncomfortable with not validating it? It’s pretty common practice, I believe, to entirely skip validation on fields that are generated by code, on the assumption that the code will Do The Right Thing.
Because it would help me with development if my lapses in managing the data were caught and flagged.
Also because the possibility exists that I will somehow at some point choose to expose control of this field in some way and want to ensure it is validated. The reason I manage the field in the background is as a convenience for the user, but it’s ultimately a user-choice thing. It’s a UX headache for users to manually have to input what sort order they want for each item in a list and deal with collisions or re-ordering them. They don’t care (until they care). They just want to enter data and have it all work out. So my approach is to assume order of entry is list order and then I will give them a GUI to change that order. But it’s entirely possible I will need/want to also provide a direct input to the field itself for some reason.
I just dislike the idea of validation rules for my data model where some are enforced for me and others aren’t.
Yes, that is validation. That’s probably worst case scenario for you. Can you convert it into a rule instead (almost certainly technically possible) and then do the extra processing you need in beforeRules?