Open nathanl opened 11 years ago
Ah, poop-on-a-stick! You can't do that because users would see it and be confused.
This is not the first time I've wished for separate developer-facing and user-facing validation errors.
Well, you can easily roll your own simply by mixing a module into AR:Base that lazy-initializes your own error object and calls a before_validate that marks the "real" error object as invalid if something is present in the internal one.
Then you can write a validation handler for the state machine to see if the state is included in the current machine. Should only be a few LOC.
Yeah, I was thinking about this more as a usability improvement for all developers. Now that I'm aware of it, I can figure it out easily; just wanted to spare others the pain.
Ah, for the particular state attribute validation I've written an :after_initialize hook that verifies that the state is valid and sets the attribute to a "you fucked up" state (known to the state machine) if it's not.
That in turn allows the user to transition to any other target state.
I've just spent a while chasing down a mysterious "is invalid" validation error. Turns out that the problem was that this attribute is managed by state_machine and the value I set was not one of its states.
A message like "is not a valid state_machine state" would have been much clearer.
Thoughts?