Комментарии 43
Вот бы вы первым абзацем написали о том, что вообще такое — Laravel
THE PHP FRAMEWORK FOR WEB ARTISANS.С сайта laravel.com.
PHP THAT DOESN'T HURT. CODE HAPPY & ENJOY THE FRESH AIR.
Зайти в хаб по Laravel и требовать объяснений, что это такое. Гениально.
К сожалению, на Хабре не очень разумно устроена подписка на хабы. Я всё время боюсь пропустить новые интересные посты про какие-нибудь новые технологии, фреймворки, программы и так далее, поэтому как только появляются новые хабы, я тут же на них подписываюсь. В связи с этим не вижу ничего удивительного в том, что я не знал, что такое Laravel, когда открыл статью.
Пост на главной, на хаб я не подписан. Ничего гениального… Приходится пройтись по ссылкам, чтобы понять нужно ли это мне.
Отличная подборка ссылок! Спасибо ;)
P.S. уже 4к+ подписчиков у хаба, радует…
P.S. уже 4к+ подписчиков у хаба, радует…
Больше всего радует что данный фреймворк очень динамично развивается. Но недавно Тейлор сказал что начиная с версии 4,2 все вкусности будут платными и вот статья на эту же тему в русскоязычном сообществе. Что конечно немного огорчило изначально, ну а потом с какой стати разработчики должны писать замечательный фреймворк за «хлеб»?
Там не написано, что «все», не нагнетайте. Скорее всего будет репозиторий как у cartalyst, где обновления и форум поддержки будут доступны только тем, кто оплатил подписку. И наверняка будет торрент с этими модулями, который будет регулярно обновляться.
Немного не точно выразился, прошу прощения.
Эт да, но всегда стараюсь, преобретать платное по, а не качать с торрента, если программ действительно качественная и цена не более $100-130.
И наверняка будет торрент с этими модулями, который будет регулярно обновляться.
Эт да, но всегда стараюсь, преобретать платное по, а не качать с торрента, если программ действительно качественная и цена не более $100-130.
Неужели еще и фреймворки надо будет на торренте качать? Интересно, что при этом будет за лицензия: либо «качай за деньги, используй где хочешь», либо «за деньги качай для себя, за отдельные деньги лицензируй per-site»?
Оно наверное и забавно, но ни разу не промышленно и уменьшает уверенность.
Тем более, что конкуренты таки есть. Хотя, конечно, тут кто на чем привык. вряд ли подписка будет кусача. Но, еще раз повторюсь, 1) нужно понимать, за что платятся деньги и 2) что будет дальше в смысле платности и развития.
Оно наверное и забавно, но ни разу не промышленно и уменьшает уверенность.
Тем более, что конкуренты таки есть. Хотя, конечно, тут кто на чем привык. вряд ли подписка будет кусача. Но, еще раз повторюсь, 1) нужно понимать, за что платятся деньги и 2) что будет дальше в смысле платности и развития.
Фреймворк всегда будет бесплатным. Платными будут некоторые модули к нему, написанные, оттестированные и поддерживаемые лично Тейлором и людьми из core-команды. Например, интернет-магазин (вряд ли сделают именно это, слишком банально и решений разных уже много, но продукты будут такого уровня, думаю).
На kohana всегда и всё бесплатно, еще и с HMVC из коробки.
«если вам понадобился HMVC, то вы скорее всего допустили ошибку на этапе проектирования приложения» — не помню автора, возможно, Фаулер.
можно и пешком на работу ходить по 20 километров в день, обосновывая -это полезностью для здоровья.
цитатки у Вас конечно… как вконтатке, от не знаю кого и не знаю — зачем
цитатки у Вас конечно… как вконтатке, от не знаю кого и не знаю — зачем
20 км до работы пешком — это, имхо, как раз инициализировать всю http-request-response обвязку ради того, чтобы получить особым образом сформированные данные.
А выделять функцонал формирования этих данных в отдельные классы и вызывать их методы в контроллерах и других классах — это более правильный подход.
Вот вам именованная цитата, если вам так удобнее:
А выделять функцонал формирования этих данных в отдельные классы и вызывать их методы в контроллерах и других классах — это более правильный подход.
Вот вам именованная цитата, если вам так удобнее:
So, what is the solution to this dilemma? Many developers start packing logic into their controllers.
Once the controllers get large enough, they need to re-use business logic that is in other controllers.
Instead of extracting the logic into another class, most developers mistakenly assume they need to
call controllers from within other controllers. This pattern is typically called “HMVC”. Unfortunately,
this pattern often indicates poor application design, and controllers that are much too complicated.
Feel the need to call controllers from other controllers? Extract the logic into a third class that can be injected into any controller.
Taylor Otwell — Laravel: From Apprentice To Artisan, страница 24
А выделять функцонал формирования этих данных в отдельные классы и вызывать их методы в контроллерах и других классах — это более правильный подход.
Да, Ваш подход идеален для одностранички. Когда у Вас будут десятки тысяч строк кода, которые напичкан вызовами Классов прямо в контроллере, ваш подход становится неоправданно дорогим и выльется множеством человекочасов, особенно для новых сотрудников.
К тому же его гибкость весьма сомнительна, в kohana есть уже всё, что мне необходимо, гибкость любого уровня. laravel скоре напоминает конструктор для маленьких. И кстати при том, что в kohana как Вы говорите, есть сомнительная обвязка, она почему-то быстрее. чем Ваш сомнительный laravel, без обвязки вокруг http-request-response.
Да, Ваш подход идеален для одностранички. Когда у Вас будут десятки тысяч строк кода, которые напичкан вызовами Классов прямо в контроллере, ваш подход становится неоправданно дорогим и выльется множеством человекочасов, особенно для новых сотрудников.
К тому же его гибкость весьма сомнительна, в kohana есть уже всё, что мне необходимо, гибкость любого уровня. laravel скоре напоминает конструктор для маленьких. И кстати при том, что в kohana как Вы говорите, есть сомнительная обвязка, она почему-то быстрее. чем Ваш сомнительный laravel, без обвязки вокруг http-request-response.
hello wolrd, которыми тестят фреймворки, не используют hmvc.
Я несколько лет работал с Коханой, это прекрасный простой фреймворк, её layered file system — реально находка. Но «гибкости любого уровня» там, к сожалению, нет — фреймворк провоцирует писать статическими классами или как в прокрустово ложе ложиться в MVC, весь код перенося в контроллеры и задействуя HMVC как средства против дублирования кода. Я почувствовал что если буду дальше делать сайты на Кохане, то буду говнокодить и со временем совсем отстану от php-движухи, тупо переписывая composer-пакеты в кохановские модули, так как под Кохану уже давно никто ничего не пишет. Поэтому перешел на Ларавель.
Я несколько лет работал с Коханой, это прекрасный простой фреймворк, её layered file system — реально находка. Но «гибкости любого уровня» там, к сожалению, нет — фреймворк провоцирует писать статическими классами или как в прокрустово ложе ложиться в MVC, весь код перенося в контроллеры и задействуя HMVC как средства против дублирования кода. Я почувствовал что если буду дальше делать сайты на Кохане, то буду говнокодить и со временем совсем отстану от php-движухи, тупо переписывая composer-пакеты в кохановские модули, так как под Кохану уже давно никто ничего не пишет. Поэтому перешел на Ларавель.
Из приведенного списка книг могу настоятельно порекомендовать «Laravel: Code Bright» от Dayle Rees, с отличным юмором написана книга, читать нескучно и в целом для старта (и как справочник) книга будет полезна.
Я бы с неё порекомендовал начинать изучать Laravel.
Я бы с неё порекомендовал начинать изучать Laravel.
До "Code Bright" я пока не дошел (хотя уже купил). В свою очередь могу вкратце резюмировать "Laravel: From Apprentice to Artisan" Тэйлора.
Начинать изучать Laravel можно и с нее (ну и документацию на сайте никто не отменял). В книге в основном описан IoC, лежащий в основе фреймворка с примерами. В заключительной части книги подробно расписывается SOLID дизайн. Весьма позновательно.
Начинать изучать Laravel можно и с нее (ну и документацию на сайте никто не отменял). В книге в основном описан IoC, лежащий в основе фреймворка с примерами. В заключительной части книги подробно расписывается SOLID дизайн. Весьма позновательно.
Я посмотрел немного на код и мне показалось, что в нем есть что-то от Ruby.
Прошу, прощения если что то упустил, хотелось бы узнать на сколько хуже / лучше данный фреймворк по сравнению, например, с Yii?
Лучше или хуже, решать только вам, но у Laravel есть несколько неоспоримых преимуществ по сравнению с Yii
1) Более современный, минимальная версия PHP на которой работает Laravel 4.1 это 5.3.7, для Yii это 5.1.
2) Laravel более популярный по сравнению c Yii (зарубежном)
3) В Laravel по умолчанию есть драйвера для работы с серверами очередей.
4) В Laravel используются PSR стандарты
1) Более современный, минимальная версия PHP на которой работает Laravel 4.1 это 5.3.7, для Yii это 5.1.
2) Laravel более популярный по сравнению c Yii (зарубежном)
3) В Laravel по умолчанию есть драйвера для работы с серверами очередей.
4) В Laravel используются PSR стандарты
Про популярность и Google Trends несогласны.
С Yii сравнивать некорректно, сравнивать следует с Yii2.
Каких-то особых преимуществ я не заметил, с другой стороны в Yii2 можно делать вещи, пока недоступные для L4 (например, RaR с фильтрацией по полям отношения)
Каких-то особых преимуществ я не заметил, с другой стороны в Yii2 можно делать вещи, пока недоступные для L4 (например, RaR с фильтрацией по полям отношения)
Простите, первый раз слышу аббревиатуру RaR. Не просветите?
ar = record.
rar = relational active record.
rar = relational active record.
Вы имеете ввиду связывание моделей по N критерию, при этом ограничение некоторых полей этих моделей? Или может связывание моделей по нескольким критериям?
Я просто не понимаю что Вы хотели сказать сообщением: «Относительный ActiveRecord с фильтрацией по полям отношения».
Я просто не понимаю что Вы хотели сказать сообщением: «Относительный ActiveRecord с фильтрацией по полям отношения».
Ниже прояснил.
Вот это: select * from post left join author on post.id = author.id where author.name = '...';
только через RAR.
Вот это: select * from post left join author on post.id = author.id where author.name = '...';
только через RAR.
Вариант 1:
Вариант 2:
Если я ничего не путаю, это экспромт. Документация: laravel.com/docs/eloquent#relationships Прошу заметить, что нижеупомянутая Eager Loading находится тут: laravel.com/docs/eloquent#eager-loading
class Author extends Eloquent
{
public function posts()
{
return DB::table(self::$table)
->leftJoin('author', 'post.id', '=', 'author.id')
->whereRaw('author.name = ?', [*****])
->get();
}
}Вариант 2:
class Author extends Eloquent
{
public function posts()
{
return $this->hasMany('Post');
}
}
class Post extends Eloquent
{
public function posts()
{
return $this->belongsTo('Author');
}
}
Если я ничего не путаю, это экспромт. Документация: laravel.com/docs/eloquent#relationships Прошу заметить, что нижеупомянутая Eager Loading находится тут: laravel.com/docs/eloquent#eager-loading
Скорее всего путаете (или документация неполна), потому что прямо по Вашей ссылке #eager-loading приводится результирующий запрос к БД:
select * from booksselect * from authors where id in (1, 2, 3, 4, 5, ...)В eager loading да, но в hasMany совсем другой запрос получается, с указанными джоинами.
Не, стоп, при чем тут hasMany.
Мне нужно добыть все книги, которые belongsTo авторы. У каждой книги один автор, books.author_id = authors.id.
Пример требуемого sql-запроса я привел.
В случае hasMany (допустим, books hasMany images, т. е. у каждой книги много картинок) джойн как раз не нужен, иначе это фееричный запрос получится.
Мне нужно добыть все книги, которые belongsTo авторы. У каждой книги один автор, books.author_id = authors.id.
Пример требуемого sql-запроса я привел.
В случае hasMany (допустим, books hasMany images, т. е. у каждой книги много картинок) джойн как раз не нужен, иначе это фееричный запрос получится.
Как-то так:
public function postsBy($author)
{
return $this->belongsTo('author')->where('author_name', '=', $author);
}
Выходит все упирается в «вопрос религии» и предпочтений?
Не совсем.
На простых приложениях — действительно религия. Приложения типа «хелло ворлд» (что в доках фреймворков обычно выглядит как «напишем свой движок для блога») везде примерно одинаковые.
Но дьявол, как обычно, в деталях. Когда дело доходит до чего-то чуть более сложного, чем блог, могут внезапно начаться проблемы.
Возьмем, к примеру, уже упомянутый мной выше RAR. Авторы современных фреймворков очень любят писать всякие красивые слова про NoSQL, проблему N+1 и круто реализованную жадную загрузку. А потом внезапно оказывается, что невозможно вывести список постов с авторами, отсортированный/отфильтрованный по имени автора (пример для блога), потому что все записи из отношения выгребаются отдельным запросом. Т. е. не select… from posts left join authors, a select… from posts, select… from authors where id in (...).
А на вопрос «а как бы сделать так, чтобы можно было» чаще всего следует ответ «используйте DAO».
На простых приложениях — действительно религия. Приложения типа «хелло ворлд» (что в доках фреймворков обычно выглядит как «напишем свой движок для блога») везде примерно одинаковые.
Но дьявол, как обычно, в деталях. Когда дело доходит до чего-то чуть более сложного, чем блог, могут внезапно начаться проблемы.
Возьмем, к примеру, уже упомянутый мной выше RAR. Авторы современных фреймворков очень любят писать всякие красивые слова про NoSQL, проблему N+1 и круто реализованную жадную загрузку. А потом внезапно оказывается, что невозможно вывести список постов с авторами, отсортированный/отфильтрованный по имени автора (пример для блога), потому что все записи из отношения выгребаются отдельным запросом. Т. е. не select… from posts left join authors, a select… from posts, select… from authors where id in (...).
А на вопрос «а как бы сделать так, чтобы можно было» чаще всего следует ответ «используйте DAO».
Выглядит интересно. Но вот платный PHP-фрэймворк? И много они продадут, прежде чем всё это начнут сливать в сеть?
Платный? Laravel github.com/laravel/laravel
Laravel Packages Registry уже нету
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Laravel. Интернет-ресурсы