Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.(laravel.com)
laravel.com
Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
http://laravel.com/docs/routing#the-basics
5 comments
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.
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.
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.
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.
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?
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?
This framework looks nice and very well documented. I'll probably try it out next time I need to write something in PHP. The code bits I've seen in the docs look nearly elegant. At last, PHP's ecosystem starts to look a bit more enjoyable.
I've looked at Laravel before, and I'm confused as to why Laravel is so tightly coupled internally. Unlike something like Silex, which uses dependency injection, I can't override the Route class in your application without rewriting a large chunk of the stack or replacing the file.
In addition, the idiom of static calls for everything seems strange. Why was that pattern (or anti-pattern) chosen above other, more OO options?
In addition, the idiom of static calls for everything seems strange. Why was that pattern (or anti-pattern) chosen above other, more OO options?
This is an excellent example of good documentation. And for some reason it is refreshing to not see a twitter bootstrap site as well.
This looks to be a very nice php framework. I used to be all over codeigniter or fuelphp, but since moving to ruby (rails & sinatra) I am happy to see php frameworks like this springing up.
great work.
This looks to be a very nice php framework. I used to be all over codeigniter or fuelphp, but since moving to ruby (rails & sinatra) I am happy to see php frameworks like this springing up.
great work.
Actually it is using bootstrap. Just heavily modified ;)
Odd choice of link - the basics of routing?
The ORM looks better than PHP ActiveRecord, though it's kind of weird that validations live outside of the database models.