Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
1–10 of 10 posts
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#2Odd choice of link - the basics of routing?
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#3This 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.
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#4This 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.
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#5I'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?
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#6The link should probably have gone to 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.
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#7The link should probably have gone to 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.
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.
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#8This 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.
Actually it is using bootstrap. Just heavily modified ;)
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#9The link should probably have gone to 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.
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…
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.
Re: Show HN: Laravel 3.1 PHP Framework. Includes awesome ORM.
#10Earlier quoted context omitted.
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…
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.
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?