Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Помогите убедить команду взять Laravel за основу в дальнейших разработках.
Фреймворк будет использоваться для написания крупных проектов, интернет-магазинов и т.п.
Я немного знаю Laravel, больше в команде никто не знает ни Laravel ни Yii. Нужны убедительные аргументы, почему Laravel хорош,
если вы знаете Yii, то чем Laravel лучше Yii, чем Yii сам по себе плох? Нужны именно аргументы, впечатлениями я и сам могу поделиться:)
P.S. Прошу к самостоятельному изучению и сравнению не отсылать (я ведь спрашиваю именно Ваше мнение) и воздержаться от оффтопа.
P.P.S. Прошу любителей Yii(если они тут есть) не устраивать холивары - Yii на ровне с Laravel хорошие продукты, но я хотел бы команду убедить взять всё же Laravel.
Не в сети
Имхо, но основное преимущество laravel - простота и это сильно индивидуальное, я к примеру сколько раз не пытался начать работать с yii так и не смог, всегда какие-то проблемы на ровном месте возникали. Так что попробуйте оба фреймворка, за пару дней изучения вполне можно понять к какому больше душа лежит. Все таки это не cms которая под задачи подбирается, это инструмент с помощью которого задачи решаются.
я к примеру сколько раз не пытался начать работать с yii так и не смог
Аналогичная ситуация, после Laravel в Yii постоянное ощущение, что что-то не то и не так. 2-а раза брался его изучать, так и не смог.
Не в сети
Аналогичная ситуация, после Laravel в Yii постоянное ощущение, что что-то не то и не так.
И у меня аналогично, только в другом порядке. Сначала попробовал изучить Yii, а уже после наткнулся на Laravel. Определяющим фактором в пользу Laravel, стало совпадение логики фреймворка с моей собственной.
Yii к месту и не к месту делает серьёзное лицо и заставляет использовать слоёный пирог из абстракций, паттернов, наследования и прочего оверинжиниринга. Laravel же, позволяет подойти к проблеме по-человечески, без напускного формализма и лишней бюрократии.
В Вашей ситуации я бы попробовал сесть всей командой и написать несложный проект, сначала на одном фреймворке, потом на другом. И уже по итогу решать на чём команде удобнее разрабатывать.
Taylor Otwell @taylorotwell
In other news, features debuting at @laraconeu are going to rock your world. Can’t wait to show you!
http://live.laracon.eu/
Не в сети
В Вашей ситуации я бы попробовал сесть всей командой и написать несложный проект, сначала на одном фреймворке, потом на другом. И уже по итогу решать на чём команде удобнее разрабатывать.
Согласен, подумываем над этим.
Не в сети
Мы с yii первого перешли на laravel... Мое мнение что laravel идеален для мелких и средних проектов, на laravel удобно и легко писать код. yii просто уже устарел, в нем образовалось много костылей, именно поэтому и переписывают в yii2, которую еще надо будет оценить... Повторюсь, пока не вышел yii2 и не устаканился, laravel бесспорный фаворит для мелких-средних проектов.
p.s. в пользу yii скажу что мне в нем больше нравилась валидация и crud.
А что мешает поднимать на ларавеле сложные проекты? И что тогда по Вашему использовать для сложных проектов?
Я начал тоже с CodeIgniter потом перешел на Yii, но сейчас использую Laravel 4 и ощущения просто чудесны. Из преимуществ отличная ORM, Routes, Rest из коробки и много готовых пакетов. В освоении гораздо проще.
Сразу скажу если возьмете Yii будете довольны, но после того как попробуете сделать тот же проект на Ларе будете ощущать что надо было брать Лару.
Советую попробовать и то и то, для опыта, хороший прогер не гнушается пробовать.
Не в сети
А что мешает поднимать на ларавеле сложные проекты? И что тогда по Вашему использовать для сложных проектов?
Тема не об этом
Не в сети
Мастер 
Не в сети
А что мешает поднимать на ларавеле сложные проекты? И что тогда по Вашему использовать для сложных проектов?
Этот ответ только мое мнение... И тема немного холиварна...:)
Большой проект можно реализовать и на ларавел, другой вопрос, выбрал бы я ларавел для большого проекта - нет. Для большого проекта я бы на данный момент выбрал Symfony2, а если в проекте много вычислений, то выбор пал бы очевидно вообще не на php, а на java к примеру и spring fw...
В чем разница?
На ларавел очень удобно писать проекты, мне нравится синтаксис, орм, вообще почти все:) Мне кажется это самый удобный php фреймворк на данный момент. В симфони же вам придется плодить кучу сущностей... В симфони вам придется писать много кода... Но, симфони это очень большой фреймворк, в нем из коробки проект бьется на бандлы(модули), в нем есть кэширование всего и вся, что отразится на производительности, мне также нравится doctrine, ну и мне очень нравится что в симфони, при правильном написании, всегда порядок в коде, все разбито по составляющим... Симфони очень хороший фреймворк, но только для очень больших проектов... После ларавел вам не захочется садится на симфони:) Сейчас еще очень интересно посмотреть на yii2, жаль только что они очень сильно затягивают с релизом...
Ну и php - язык интерпретируемый... Конечно компилируемый язык быстрее, в таких гигантах как yandex, google, позади языки компилируемые... У джавы есть прекрасный фреймворк спринг для тех кто хочет попробовать...
Что хочу сказать... Вы один, или вдвоем, троем не напишете такой сайт, у которого будет посещений как у гугла или яндекса, поэтому смело можете выбирать любой из фреймворков... А если вы все же думаете что напишете, то при такой посещаемости сайта, поверьте, у вас будут деньги на то, чтобы нанять команду, которая перепишет весь ваш сайт на любой язык. Поэтому смело выбирайте тот фреймворк, который вам нравится и к которому лежит душа... Идеального фреймворка нет, у всех свои достоинства и недостатки.
В заключении, скажу: на данный момент мне кажется что достаточно посмотреть только 3 фреймворка, это Symfony2, Yii2, Laravel и сделать свой выбор...
Подозреваю, народ хотел услышать, почему Laravel не годится для больших проектов 
Laravel на самом деле годится для проектов любой сложности. Он же по сути тот же симфони, только по-другому скомпонован, чтобы новичкам было попроще писать. Доктрину и т.п. можно навесить и на него.
Не в сети
Мне кажется, ключевой вопрос не «можно-нельзя» (никто ведь не может запретить), а «целесообразно ли».
ИМХО, при разработке большого проекта крупной[, распределённой] командой, главное — дисциплина написания кода и высокоуровневая архитектура. Laravel же по сравнению с более строгими фреймворками, с одной стороны, предлагает большую свободу в выборе решений и способов их реализации (+ к архитектуре, - к дисциплине), а с другой привносит большую долю неопределённости, анархии (- к архитектуре, - к дисциплине, + дополнительный объём работы по разработке и согласованию конвенций).
Т.е. в больших проектах Laravel целесообразно использовать только при наличии грамотного архитектора и дисциплинированной команды. В остальных случаях лучше подобрать что-нибудь строгое, с большим количеством готовых соглашений и паттернов. Это позволит избежать разброда и шатания.
Кто что думает?
Taylor Otwell @taylorotwell
In other news, features debuting at @laraconeu are going to rock your world. Can’t wait to show you!
http://live.laracon.eu/
Не в сети
Мастер
- Т.е. в больших проектах Laravel целесообразно использовать только при наличии грамотного архитектора и дисциплинированной команды.
В общем-то как всегда, всё сводится к тому, как команда использует инструмент. Laravel меньше перегружен концепциями (aka java’измом) чем та же Symfony, что есть и плюс, и минус. Совместить строгую архитектуру и свободу концепций невозможно по определению, так что присоединяюсь к сказанному.
Не в сети
Как любитель Yii могу сказать одно - Yii2 всех порвет))
Но тут нужно понимать одно - если ты всю жизнь будешь кататься на мэрсе и ни разу не прокатишься на бмв - ты не сможешь адекватно оценить ту и другую машину. Они обе хороши, максимально просты в использовании, мощные, красивые и прекрасно справляются с основной задачей - возить человека. Если ты будешь достаточно хорошо знать их обе - это тебе только в плюс, т.к. ты будешь точно знать в какой момент нужно использовать ту или иную машину.
Вот у меня сейчас такой момент - я использовал только Yii более года. Пришло тестовое задание от нового работодателя, в котором он четко указал использовать фрэймворк Laravel. Вот сижу и разбираюсь)) Чисто мое мнение - без 100 грамм не разобраться. Нужно ставить какие-то фигни для автокомплита, куча зависимостей от сторонних расширений типа симфони)) В процессе установки оно меня больше всего удивило, какого фига половина фрэймворка - это компоненты симфони?))
Очень сложно, на первый взгляд, сделана маршрутизация, но что такой подход может быть куда более гибким в дальнейшем - это факт.
Документация не последовательна. Т.е. прочитав начало я не понял, как мне дальше работать? Порог вхождения даже с достаточным знанием ООП и MVC фрэймворка YII не позволяет мне сразу сесть и начать писать свое приложение. У Yii таких проблем нет.
Начальное приложение - страница заглушки меня совсем убила. Очень важно на этом этапе уже заинтересовать разработчика готовыми фишками типа стартовой страницы, отправки почты, входа в систему (пусть без применения базы). Именно тут должна быть проложена дорога правильного написания кода и понимания как все работает. Мне попросту нечем оперировать, нечего задебажить, чтобы посмотреть как оно работает от и до.
Посмотрел код готовых приложений - вот там пошло некоторое понимание, но т.к. там у каждого разработчика свой стиль кодирования - появляется неразбериха, а как было бы правильнее то закодить?
Топикстартеру : Если разработчики выбрали Yii - пускай используют его, т.к. в дальнейшем вы уже не будете столь ответственным за сделанный "неверный" выбор. К счастью мне повезло, в свое время я заставил всех своих разработчиков перейти на Yii и особых проблем не возникало, но факт остался фактом, что приходилось иногда успокаивать программиста, объяснять где он ошибился и т.д.
Bloom, и вот опять дело в логике и вкусах конкретного индивида)
> Чисто мое мнение - без 100 грамм не разобраться.
> Очень сложно, на первый взгляд, сделана маршрутизация
> Документация не последовательна.
Это точь-в-точь моё первое впечатление от Yii
Taylor Otwell @taylorotwell
In other news, features debuting at @laraconeu are going to rock your world. Can’t wait to show you!
http://live.laracon.eu/
Не в сети
Вот вам моё второе впечатление:
Blade - извращение. Никакого автокомплита и удобства, зачем изобретать велосипеды для без того хорошего шаблонизатора под названием PHP? Сделал лайаут по документации http://laravel.com/docs/templates - фиг там.. тупо не отображает контент, но вот лайаут - без проблем.
Документация просто убивает отсутствием поиска по ключевым словам, куда больше информации нахожу на сторонних ресурсах.
API бесполезно до безобразия. http://laravel.com/api/4.2/ - вбейте в поиск View::make (они же не догадались, что кто-то может перекидывать ссылки на API). Теперь откройте http://www.yiiframework.com/doc/api/1.1 … der-detail Где информации больше? Где сразу становится понятно, что делает метод? Хотя оба они делают одно и тоже.
Я начинаю все больше понимать, что с данным фрэймворком нужно работать тупо по памяти. Выучить максимум его возможностей и использовать их, т.к. PHPStorm вообще не дает никаких преимуществ в обращении с ним. Достаточно простые вещи, которые в офф документации Yii встречаются сразу на старте - тут приходится искать очень долго. К примеру такая вещь как {{ url('css/stile.css')}} в layout. Покажите мне в офф документации где написано как это использовать? В yii это видно сразу в тестовом приложении.
Blade нужен исключительно своими директивами @extends , @section , @yield и т.п. - с помощью них компонуется лейаут в laravel-style компоновки приложения, они практически незаменимы. Плюс очень удобный @include - он вставляет внешнюю вьюху и, о чудо и счастье, туда не надо передавать переменные, все переменные, которые объявлены на данный момент будут переданы туда автоматом. Юзать остальные фичи blade типа {{}} имхо нет смысла - нет автодополнения, автовыделения в IDE, ну и действительно, просто зачем, когда есть прекрасный шаблонизатор php.
По поводу документации ты прав, она сферическая и в вакууме, практические стороны, с которыми сталкивается каждый новичок там затронуты вскользь, её можно использовать только как справочник, когда фреймворк уже знаком. Разобраться же во фреймворке чисто по ней очень трудно. Но ситуацию исправляют туториалы, которых в сети просто куча.
Phpstorm на фреймворке из коробки действительно помогает мало, но стоит поставить https://github.com/barryvdh/laravel-ide-helper , то все магическим образом преображается. Работает автодополнение по всем классам и фасадам, Ctrl+B работает везде и на всем, можно смотреть исходники вглубь не залезая в документацию. Плюс генерится phpdoc для твоих моделей, так, что становится возможным даже автодополнение названия их полей - они берутся из БД. Мне лично с laravel работать в phpstorm очень удобно.
Тут еще такая особенность, что я фрилансер и работаю один. Поэтому мне не нужен простой порог вхождения, я после смерти Kohana начал искать фреймворк, на котором бы я мог остановиться уже насовсем, который гарантированно проживет долго - и между symfony и laravel выбрал второй. Для организации устоявшиеся юзкейсы по коду могут быть важнее и тут общая прагматичность yii выводит его вперед, конечно.
Не в сети
Blade - извращение
Смысл шаблонизаторов в PHP — упрощённый синтаксис (спорно) и наследование шаблонов. Blade с этим справляется. А если Вы не любите шаблонизаторы, от него можно просто отказаться)
Документация просто убивает отсутствием поиска по ключевым словам, куда больше информации нахожу на сторонних ресурсах.
Действительно затруднения есть. В документации описаны лишь общие приёмы работы в формате скорее ликбеза, чем справочника. Но тут, кмк, особенность концепции. Laravel состоит большей частью из сторонних библиотек и компонентов, досконально описывать их в документации нет смысла, для глубокого понимания лучше читать доки на их собственных сайтах.
Где информации больше? Где сразу становится понятно, что делает метод?
В документации Yii. Laravel тут проигрывает всухую.
PHPStorm вообще не дает никаких преимуществ в обращении с ним
Частичная поддержка в EAP уже есть. Сейчас можно использовать: Laravel IDE Helper.
К примеру такая вещь как {{ url('css/stile.css')}} в layout. Покажите мне в офф документации где написано как это использовать?
В yii это видно сразу в тестовом приложении.
Вот тут и есть разница в подходах, имхо: Yii про гнутьё уже готового велосипеда, Laravel про написание своего.
P.S. Камрад slider23 опередил)
Изменено konfuji (27.08.2014 09:38:52)
Taylor Otwell @taylorotwell
In other news, features debuting at @laraconeu are going to rock your world. Can’t wait to show you!
http://live.laracon.eu/
Не в сети
За ссылку на хэлперы благодарю))) Реально читать всю документацию без практики - время на ветер, поэтому до них попросту не добрался. Если вам интересно моё мнение - могу и дальше отписываться о своём "путешествии" в мир Laravel. Забрасывать я его явно не стану, т.к. нужно не только "на бмв кататься", но и мэрсы знать надо)))
В данный момент изучаю миграции, тут Yii идет таким-же путем, поэтому особых трудностей не возникло.
IDE helper был поставлен в первую же очередь. Мало того в репозитории PHPStorm есть еще и плагин для работы с Laravel. Он, конечно, версии 0.1, но со своими обязанностями справляется автокомплитя пути к вьюхам.
Из удобочитабельных статей пока понравилась (и я еще в процессе ознакомления с ней) вот такая: http://amegatron.ru/category/laravel/
Мастер
- Юзать остальные фичи blade типа {{}} имхо нет смысла — нет автодополнения, автовыделения в IDE, ну и действительно, просто зачем, когда есть прекрасный шаблонизатор php.
Многие так не думают и это обидно. {{ }} — опасная конструкция, так как не экранирует вывод. Получаем вездесущий XSS. «Так ведь быстрее!» Ума не приложу, почему её и {{{ }}} не поменяли по смыслу, как это сделано во всех нормальных JS-шаблонизаторах (mustache, handlebars).
- её можно использовать только как справочник, когда фреймворк уже знаком.
Ты знаешь, её даже как справочник толком-то нельзя использовать — тот же Eloquent там описан настолько плохо, что некоторые поля классов вообще отсутствуют 
. Единственный вариант — читать исходники, что в третьей ветке было замечательным, а в 4 из-за фасадов — просто сплошная каша. Когда внезапно натыкаешься на непонятное поведение методов (merge() — метод коллекции, но с какого перепугу он удаляет дубликаты в Eloquent?) отладка этого занимает непропорционально много времени — иногда по часу и больше. На метод!
Хотя, конечно, проблем с этим на простых сайтах нет, либо если не хочешь заморачиваться с чем-то слишком умным, а делаешь просто, чтоб работало. Но с другой стороны это делает фреймворк менее универсальным, точно не для написания своих велосипедов.
Laravel удобен своей структурой, но вот прямолинейности и документации ему не хватает 100%.
- Laravel состоит большей частью из сторонних библиотек и компонентов, досконально описывать их в документации нет смысла
На самом деле сторонние компоненты используются намного реже, чем ядерные фичи самого фреймворка (Symfony вообще запрятан глубоко под капот). У меня, во всяком случае, проблемы постоянно именно с ядром — ORM, routing, шаблоны и прочее. О Carbon и других сторонних вещах говорить не приходится — у них с документацией всё в порядке (конечно, и проекты сами по себе меньше).
Не в сети
Bloom, продолжайте, очень интересно. Я от Ваших сравнений уже начал подумывать над более подробным ознакомлением с Yii)
Proger_XP, с документацией и маскировкой фасадами действительно швах. Но на счёт велосипедов не соглашусь. На мой взгляд Laravel ближе остальных к Unix-way, а замена любых компонент/пакетов/подсистем (не внутри фреймворка, а внутри велосипеда) в сочетании с Composer и теми же фасадами — проще простого.
Taylor Otwell @taylorotwell
In other news, features debuting at @laraconeu are going to rock your world. Can’t wait to show you!
http://live.laracon.eu/
Не в сети
Мастер
- Но на счёт велосипедов не соглашусь. На мой взгляд Laravel ближе остальных к Unix-way
Я наверное не точно выразился. «Велосипедов» на Laravel написать действительно проще, насчёт Unix-way — не уверен, что его можно применять к фреймворкам, но тем не менее.
Я имел в виду, что на текущий момент если делаешь шаг в сторону от стандартного (читай — базового) применения Laravel — попадаешь на многочасовые прогулки по исходникам в поисках самых разных хвостов, а потом и их починки (или нет, тогда пишешь какой-нибудь свой Paginator, забив на стандартный). Очень надеюсь, что в скором будущем Laravel эти проблемы перерастёт, хотя что-то по документации не похоже — могли бы уже привести в порядок…
Не в сети
Не используйте Laravel... он доводит... нет больше терпения искать простые вещи на сторонних сайтах.
Как его заставить больше не записывать поля created_at и updates_at?? В процессе разработки я понял, что они мне не нужны. Я удалил их из базы и теперь запросы на инсерт не выполняются. Зашибись.
Почему такая важная вещь как валидация сделана через такую задницу? Для чего придумано столько всяких findandkillme() и findandbecool(). Походу для того, чтобы запутать разработчика.
1. Документация по ОРМ к счастью, в одном месте. Заходим http://laravel.com/docs/eloquent , Ctrl+F 'created_at' и под первым же вхождением видим: "If you do not wish to have these columns automatically maintained, set the $timestamps property on your model to false."
2. А как можно валидацию сделать проще ?
$validator = Validator::make(Input::all(), $rules);
if ($validator->fails())
{
return Redirect::to('url')->withErrors($validator);
}
Если же хочешь, чтобы модели у тебя автовалидировались при сохранении (имхо, стремный момент, но практикуется), то повесь валидацию на эвент: http://www.laravel-tricks.com/tricks/au … validation
Изменено slider23 (30.08.2014 08:32:27)
Не в сети
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)