4 ms·

The link should probably have gone to http://laravel.com/docs http://laravel.com/docs instead of the Routing page. The ORM looks better than PHP ActiveRecord,

by there 15y ago

The link should probably have gone to http://laravel.com/docs http://laravel.com/docs instead of the Routing page. The ORM looks better than PHP ActiveRecord, though it's kind of weird that validations live outside of the database models.

mgkimsal 15y ago
Agreed that validations outside the models is a bit weird. There are times when you have 'business logic' validation rules that aren't 'data validation' rules, but we almost always have data validation rules that match up with a particular model/table. Forcing those to be developed and documented apart from each other is odd. I'm assuming you could put a static $validationRules on a model and grab it in a controller for validation, but that it's not described/recommended/defaulting to that behaviour is a bit disappointing.
- ShawnMcCool 15y ago
  Laravel isn't the kind of framework to lock you into a specific way of doing things. It's different than what you may expect if you're coming from Symfony, Kohana, CodeIgniter, or Fuel. There's no reason to tie a validation system into a model. That's enough justification for it not to be done. You have the flexibility to implement it easily in whatever way you see fit.
  - mgkimsal 15y ago
    You can get reductionist and say there's no reason to do anything. The fact is, most of the time when people have models that represent things, there are going to be basic validation rules to represent standard constraints ("email has to be valid", "fields x/y/z can't be null", etc). Those constraints are specific to the concept of the model itself, outside of any relations it may have, or uses it may have in the rest of the app. To me, that's reason enough to provide for a validation system in a model in framework. Hell - why have models? There's no reason to tie a model in to a framework - just be flexible and do it however you want, right?

by there 15y ago

mgkimsal 15y ago

Agreed that validations outside the models is a bit weird. There are times when you have 'business logic' validation rules that aren't 'data validation' rules, but we almost always have data validation rules that match up with a particular model/table. Forcing those to be developed and documented apart from each other is odd. I'm assuming you could put a static $validationRules on a model and grab it in a controller for validation, but that it's not described/recommended/defaulting to that behaviour is a bit disappointing.

ShawnMcCool 15y ago
Laravel isn't the kind of framework to lock you into a specific way of doing things. It's different than what you may expect if you're coming from Symfony, Kohana, CodeIgniter, or Fuel. There's no reason to tie a validation system into a model. That's enough justification for it not to be done. You have the flexibility to implement it easily in whatever way you see fit.
- mgkimsal 15y ago
  You can get reductionist and say there's no reason to do anything. The fact is, most of the time when people have models that represent things, there are going to be basic validation rules to represent standard constraints ("email has to be valid", "fields x/y/z can't be null", etc). Those constraints are specific to the concept of the model itself, outside of any relations it may have, or uses it may have in the rest of the app. To me, that's reason enough to provide for a validation system in a model in framework. Hell - why have models? There's no reason to tie a model in to a framework - just be flexible and do it however you want, right?