12 ms·

Spring boot has form validations pretty much out of the box, via validation annotations.

ajmurmann 2y ago
It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.
- olavgg 2y ago
  The biggest difference here is that Spring Boot has the errors in a seperate object BindingResult. If you use Thymeleaf, this is smoothly integrated and you just write: <p th:if="${#fields.hasErrors('comment')}">Invalid Comment</p> Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.
- nesarkvechnep 2y ago
  I'm amazed that some people think that coupling your forms to your database models is a good practice.
  - lolinder 2y ago
    It depends a lot on the application. I have a little Django app that I haven't updated in years and is used by one person—it's basically just a nice frontend for a database. For that use case, being able to just directly plug forms into database models is super convenient!
  - imtringued 2y ago
    Maybe, because it works? What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?
  - mst 2y ago
    If the form is basically raw CRUD then it works out well, and being able to get up and running quickly and replace it with something more sophisticated later when you actually need that is a good thing. It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.
  - game_the0ry 2y ago
    Could you elaborate on why it is a bad practice?
  - neeleshs 2y ago
    More often than not, forms are the database model. They very frequently evolve together. The entire data transfer object to model copy back and forth is unnecessary most of the time
  - ajmurmann 2y ago
    It goes further than that. The form gets passed the model and it's name and based on that also drivers the URL and http action to take. IMO this is good coupling since it's very loose, trivially changed and eliminated boilerplate code that's just noise. Of course, as always, it depends on a number of circumstances what trade-off is best for you, your team, the specific problem, etc

It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.

olavgg 2y ago
The biggest difference here is that Spring Boot has the errors in a seperate object BindingResult. If you use Thymeleaf, this is smoothly integrated and you just write: <p th:if="${#fields.hasErrors('comment')}">Invalid Comment</p> Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.
nesarkvechnep 2y ago
I'm amazed that some people think that coupling your forms to your database models is a good practice.
- lolinder 2y ago
  It depends a lot on the application. I have a little Django app that I haven't updated in years and is used by one person—it's basically just a nice frontend for a database. For that use case, being able to just directly plug forms into database models is super convenient!
- imtringued 2y ago
  Maybe, because it works? What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?
- mst 2y ago
  If the form is basically raw CRUD then it works out well, and being able to get up and running quickly and replace it with something more sophisticated later when you actually need that is a good thing. It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.
- game_the0ry 2y ago
  Could you elaborate on why it is a bad practice?
- neeleshs 2y ago
  More often than not, forms are the database model. They very frequently evolve together. The entire data transfer object to model copy back and forth is unnecessary most of the time
- ajmurmann 2y ago
  It goes further than that. The form gets passed the model and it's name and based on that also drivers the URL and http action to take. IMO this is good coupling since it's very loose, trivially changed and eliminated boilerplate code that's just noise. Of course, as always, it depends on a number of circumstances what trade-off is best for you, your team, the specific problem, etc