xelam 26 фев 2014 в 20:58

Laravel. Интернет-ресурсы

4 мин

65K

PHP * Laravel *

Из песочницы

+32

Комментарии 43

shebanoff 26 фев 2014 в 21:07

Вот бы вы первым абзацем написали о том, что вообще такое — Laravel

Xlab 26 фев 2014 в 21:36

THE PHP FRAMEWORK FOR WEB ARTISANS.
PHP THAT DOESN'T HURT. CODE HAPPY & ENJOY THE FRESH AIR.

С сайта laravel.com.

agulitsky 27 фев 2014 в 06:41

Зайти в хаб по Laravel и требовать объяснений, что это такое. Гениально.

andgein 27 фев 2014 в 06:55

К сожалению, на Хабре не очень разумно устроена подписка на хабы. Я всё время боюсь пропустить новые интересные посты про какие-нибудь новые технологии, фреймворки, программы и так далее, поэтому как только появляются новые хабы, я тут же на них подписываюсь. В связи с этим не вижу ничего удивительного в том, что я не знал, что такое Laravel, когда открыл статью.

Valery4 27 фев 2014 в 11:46

Пост на главной, на хаб я не подписан. Ничего гениального… Приходится пройтись по ссылкам, чтобы понять нужно ли это мне.

Amega 26 фев 2014 в 22:45

Отличная подборка ссылок! Спасибо ;)
P.S. уже 4к+ подписчиков у хаба, радует…

vlom88 27 фев 2014 в 05:17

Больше всего радует что данный фреймворк очень динамично развивается. Но недавно Тейлор сказал что начиная с версии 4,2 все вкусности будут платными и вот статья на эту же тему в русскоязычном сообществе. Что конечно немного огорчило изначально, ну а потом с какой стати разработчики должны писать замечательный фреймворк за «хлеб»?

ajaxtelamonid 27 фев 2014 в 06:19

Там не написано, что «все», не нагнетайте. Скорее всего будет репозиторий как у cartalyst, где обновления и форум поддержки будут доступны только тем, кто оплатил подписку. И наверняка будет торрент с этими модулями, который будет регулярно обновляться.

vlom88 27 фев 2014 в 06:51

Немного не точно выразился, прошу прощения.

И наверняка будет торрент с этими модулями, который будет регулярно обновляться.

Эт да, но всегда стараюсь, преобретать платное по, а не качать с торрента, если программ действительно качественная и цена не более $100-130.

achekalin 27 фев 2014 в 11:45

Неужели еще и фреймворки надо будет на торренте качать? Интересно, что при этом будет за лицензия: либо «качай за деньги, используй где хочешь», либо «за деньги качай для себя, за отдельные деньги лицензируй per-site»?

Оно наверное и забавно, но ни разу не промышленно и уменьшает уверенность.

Тем более, что конкуренты таки есть. Хотя, конечно, тут кто на чем привык. вряд ли подписка будет кусача. Но, еще раз повторюсь, 1) нужно понимать, за что платятся деньги и 2) что будет дальше в смысле платности и развития.

ajaxtelamonid 27 фев 2014 в 12:07

Фреймворк всегда будет бесплатным. Платными будут некоторые модули к нему, написанные, оттестированные и поддерживаемые лично Тейлором и людьми из core-команды. Например, интернет-магазин (вряд ли сделают именно это, слишком банально и решений разных уже много, но продукты будут такого уровня, думаю).

imgen 27 фев 2014 в 09:28

На kohana всегда и всё бесплатно, еще и с HMVC из коробки.

ajaxtelamonid 27 фев 2014 в 12:10

«если вам понадобился HMVC, то вы скорее всего допустили ошибку на этапе проектирования приложения» — не помню автора, возможно, Фаулер.

imgen 27 фев 2014 в 12:33

можно и пешком на работу ходить по 20 километров в день, обосновывая -это полезностью для здоровья.
цитатки у Вас конечно… как вконтатке, от не знаю кого и не знаю — зачем

ajaxtelamonid 27 фев 2014 в 13:02

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

imgen 27 фев 2014 в 14:21

А выделять функцонал формирования этих данных в отдельные классы и вызывать их методы в контроллерах и других классах — это более правильный подход.

Да, Ваш подход идеален для одностранички. Когда у Вас будут десятки тысяч строк кода, которые напичкан вызовами Классов прямо в контроллере, ваш подход становится неоправданно дорогим и выльется множеством человекочасов, особенно для новых сотрудников.

К тому же его гибкость весьма сомнительна, в kohana есть уже всё, что мне необходимо, гибкость любого уровня. laravel скоре напоминает конструктор для маленьких. И кстати при том, что в kohana как Вы говорите, есть сомнительная обвязка, она почему-то быстрее. чем Ваш сомнительный laravel, без обвязки вокруг http-request-response.

ajaxtelamonid 28 фев 2014 в 13:10

hello wolrd, которыми тестят фреймворки, не используют hmvc.

Я несколько лет работал с Коханой, это прекрасный простой фреймворк, её layered file system — реально находка. Но «гибкости любого уровня» там, к сожалению, нет — фреймворк провоцирует писать статическими классами или как в прокрустово ложе ложиться в MVC, весь код перенося в контроллеры и задействуя HMVC как средства против дублирования кода. Я почувствовал что если буду дальше делать сайты на Кохане, то буду говнокодить и со временем совсем отстану от php-движухи, тупо переписывая composer-пакеты в кохановские модули, так как под Кохану уже давно никто ничего не пишет. Поэтому перешел на Ларавель.

imgen 28 фев 2014 в 13:29

Мы не гонимся за «интернет-движухой», все модули написаны внутри самой компании. Кто-то может назвать это стагнацией, а кто-то стабильными проектами. Для одновневных проектов кохана не подходит, тут уж и правда лучше использовать что-то другое, быть может и вовсе готовую цмс.

hDrummer 27 фев 2014 в 06:13

Из приведенного списка книг могу настоятельно порекомендовать «Laravel: Code Bright» от Dayle Rees, с отличным юмором написана книга, читать нескучно и в целом для старта (и как справочник) книга будет полезна.
Я бы с неё порекомендовал начинать изучать Laravel.

Amega 27 фев 2014 в 06:33

До "Code Bright" я пока не дошел (хотя уже купил). В свою очередь могу вкратце резюмировать "Laravel: From Apprentice to Artisan" Тэйлора.
Начинать изучать Laravel можно и с нее (ну и документацию на сайте никто не отменял). В книге в основном описан IoC, лежащий в основе фреймворка с примерами. В заключительной части книги подробно расписывается SOLID дизайн. Весьма позновательно.

vaniaPooh 27 фев 2014 в 06:36

Я посмотрел немного на код и мне показалось, что в нем есть что-то от Ruby.

agulitsky 27 фев 2014 в 06:39

Автор говорил, что фреймворк «ruby inspired».

Davert 27 фев 2014 в 20:37

Простите за категоричность, но все существующие РНР фреймворки делятся на
* Rails clone — Laravel, Yii, Phalcon, Symfony1,…
* Spring clone — Symfony2, Zend2
* Sinatra clone — Silex, Slim, etc

Так что вы всегда можете встретить что-то знакомое.

xskif 27 фев 2014 в 09:08

Прошу, прощения если что то упустил, хотелось бы узнать на сколько хуже / лучше данный фреймворк по сравнению, например, с Yii?

Big_Shark 27 фев 2014 в 09:30

Лучше или хуже, решать только вам, но у Laravel есть несколько неоспоримых преимуществ по сравнению с Yii
1) Более современный, минимальная версия PHP на которой работает Laravel 4.1 это 5.3.7, для Yii это 5.1.
2) Laravel более популярный по сравнению c Yii (зарубежном)
3) В Laravel по умолчанию есть драйвера для работы с серверами очередей.
4) В Laravel используются PSR стандарты

RUQ 27 фев 2014 в 10:15

Про популярность и Google Trends несогласны.

НЛО прилетело и опубликовало эту надпись здесь

metamorph 27 фев 2014 в 10:55

С Yii сравнивать некорректно, сравнивать следует с Yii2.

Каких-то особых преимуществ я не заметил, с другой стороны в Yii2 можно делать вещи, пока недоступные для L4 (например, RaR с фильтрацией по полям отношения)

SerafimArts 27 фев 2014 в 16:29

Простите, первый раз слышу аббревиатуру RaR. Не просветите?

metamorph 27 фев 2014 в 17:15

ar = record.
rar = relational active record.

SerafimArts 27 фев 2014 в 17:50

Вы имеете ввиду связывание моделей по N критерию, при этом ограничение некоторых полей этих моделей? Или может связывание моделей по нескольким критериям?

Я просто не понимаю что Вы хотели сказать сообщением: «Относительный ActiveRecord с фильтрацией по полям отношения».

metamorph 27 фев 2014 в 18:27

Ниже прояснил.
Вот это: select * from post left join author on post.id = author.id where author.name = '...';
только через RAR.

SerafimArts 27 фев 2014 в 18:42

Вариант 1:

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

metamorph 27 фев 2014 в 19:29

Скорее всего путаете (или документация неполна), потому что прямо по Вашей ссылке #eager-loading приводится результирующий запрос к БД:

select * from books
select * from authors where id in (1, 2, 3, 4, 5, ...)

SerafimArts 27 фев 2014 в 20:35

В eager loading да, но в hasMany совсем другой запрос получается, с указанными джоинами.

metamorph 27 фев 2014 в 20:40

Не, стоп, при чем тут hasMany.

Мне нужно добыть все книги, которые belongsTo авторы. У каждой книги один автор, books.author_id = authors.id.
Пример требуемого sql-запроса я привел.

В случае hasMany (допустим, books hasMany images, т. е. у каждой книги много картинок) джойн как раз не нужен, иначе это фееричный запрос получится.

franzose 28 фев 2014 в 16:13

Как-то так:

public function postsBy($author)
{
    return $this->belongsTo('author')->where('author_name', '=', $author);
}

xskif 27 фев 2014 в 17:13

Выходит все упирается в «вопрос религии» и предпочтений?

metamorph 27 фев 2014 в 17:29

Не совсем.

На простых приложениях — действительно религия. Приложения типа «хелло ворлд» (что в доках фреймворков обычно выглядит как «напишем свой движок для блога») везде примерно одинаковые.

Но дьявол, как обычно, в деталях. Когда дело доходит до чего-то чуть более сложного, чем блог, могут внезапно начаться проблемы.

Возьмем, к примеру, уже упомянутый мной выше RAR. Авторы современных фреймворков очень любят писать всякие красивые слова про NoSQL, проблему N+1 и круто реализованную жадную загрузку. А потом внезапно оказывается, что невозможно вывести список постов с авторами, отсортированный/отфильтрованный по имени автора (пример для блога), потому что все записи из отношения выгребаются отдельным запросом. Т. е. не select… from posts left join authors, a select… from posts, select… from authors where id in (...).

А на вопрос «а как бы сделать так, чтобы можно было» чаще всего следует ответ «используйте DAO».