-
Notifications
You must be signed in to change notification settings - Fork 33
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
Automatic validation #240
Comments
@vcraescu Thanks for reporting an issue.
The scenario you have described, its seems you're having using same controller action for Begin said that, I'm sorry, you had to spend time much around this one. I'm disappointed since one of the goal of Thanks for bringing up, I would surely make validation flow flexible and extensible for every possible scenario.
One of the goal of Let's take a spin for what aah currently provides -
Lines 21 to 39 in b1a2826
Lines 213 to 218 in b1a2826
So from the context of validation, what would be error object values: reason as
Let's take a spin for what aah currently missing -
What are the possible solutions we could go for - Solution 1:
Solution 2:
Solution 3: (this is similar as your proposed solution)
PS: Solution 3 have possibility of removing validation library from aah. It means aah user could have their choice validation library and performing validation at controller action. |
@jeevatkm Yes, I'm using multiple verbs for an action. The app we're building right now It's just a prototype and we just render ol' school html. No REST, just plain html. I'm not big fan of having a different method for validation because inside Action method you might have some logic to render the current action. Things which you will put into aah.Data object and pass it to the view. You usually do that before you actually validate the object because it is needed even the object is valid or not. If you're being moved to a different method to handle the error basically you will have to duplicate that logic there. Example:
If the object is not valid, inside HandleErrorEdit method I will have to do this part again before I add the errors to aah.Data object:
My solution:
|
@vcraescu Sounds good to me. Once its ready I will ping you, so that you could try it out and share feedback. |
The entire entity validation logic should be reimplemented. I believe it's wrong how it works now because it makes almost impossible to use it at all. See the following scenario.
Controller
This request will always fail even it is just a GET request and
frm
is supposed to be zero because nothing was submitted yet. Even If i remove any validation tags fromforms.MyForm
and put them directly onmodels.MyModel
just to overcome this issue, but Ifforms.MyForm
has any reference to a model which has validation tags again it will fail. Spent so much time fighting this behaviour.Having a single HandleError method is a very bad idea in my opinion because when you end up in HandleError method your context is lost. You don't know the action where the error occurred and how you're supposed to handle it. You just end up with an error object you have to deal with but you don't know how. In the wild that's not always the case. Validation can be complex and might have a lot of logic behind and it needs to be very flexible. Magic kills flexibility. This might make sense If we would have single action controllers or single verb per action. But as longs as you have multiple verbs per action you gonna have a really bad day. :sad:
A better approach would be to remove any automatic validation and let the user handle it. I mean the context could have a method
Validate(m interface{})
which is just a proxy to validator and let the programmer validate the objects he needs. Something like below:The text was updated successfully, but these errors were encountered: