Comments 126
Одно из пока что незадокументированных изменений — в конструкторах контроллеров теперь нельзя получить инстанс авторизованного юзера (и, скорее всего, любые другие инстансы, которые зависят от Middleware). Т.е. если в <= 5.2 вы где-то использовали такой код:
class HomeController extends Controller
{
protected $user;
public function __construct()
{
$this->user = Auth::user(); // Или auth()->user()
}
}то теперь это не работает.
В официальной документации пишут что
You may access the authenticated user via the Auth facade:
use Illuminate\Support\Facades\Auth; $user = Auth::user();
Стоит отметить, что Dependency Injection через конструкторы (в том числе контроллеров) по-прежнему работает.
Кстати да
https://github.com/laravel/framework/issues/14983
Но я нигде не встречал упоминания о подобной смене поведения, имхо это баг.
Мелкий поганец закрывает все тикеты на эту тему. Уверя, что никогда нельзя быо так делать, Однако все делали и стабильно работало.
Сам Тейлор такой метод предлагает
https://github.com/laravel/framework/pull/14834#issuecomment-241140241
Привычка, потом удобно юзать типа $this->user
Страшного на самом деле ничего нет.
Просто сломался функционал, а нигде об этом ни слова )
количество символов примерно одинаковое а логически второе выглядит яснее вроде.
Ну как минимум, чтобы не дергать лишний раз создание фасада
Вы ведь понимаете, что обращение к Auth фасаду — это лютое зло? И что дабл диспатчеризация (или DI в конструктор) на порядок лучше сервис локации?
$username = 'Guest';
if( \Auth::check() ){
$username = \Auth::user()->name;
}
Хотя, для сохранения изменений лучше, все же, юзать как пишет Rencom:
class ... {
protected $user;
function __construct(){
$this->user = \Auth::user();
}
public function changeName($name) {
$this->user->name = $name;
$this->user->save();
}
}
<?php
$this->widget('CMaskedTextField',array(
'mask'=>'99/99/9999'
));
?>
Есть ли что то подобное для или в Ларавел ??
Конечно понимаю что это костыль все таки, мешать серверсайд с клиентсайд, но все таки!!!
Тег strike> на работает на восклицательных знаках.
Пиши в ЛС.
Тег strike> на работает на восклицательных знаках.
А что касается:
А вы не можете объяснить с чем это связано?
Много различных мнений в Инете читал при выборе фрейма и, как мне показалось, Уии несет в себе множество различного рода костылей и нарушение логики структуры, вдобавок, логика Laravel практически совпадает с моей и, таким образом, лично мне удалось очень быстро вкурить что и как в нем работает, задавая себе вопрос: «Куда бы я этот метод сунул?».
Если интересны более развернутые ответы, рекомендую погуглить эту тему.
Ах да, российские разработчики ведутся на рекламу и всякую хрень в виде «нафиг разделять проект на MVC, когда можно все в одном месте фигачить», вот и сидят на битриксе да Уии.
Это мое сугубо личное мнение.
Разве Yii(2) не имеет как раз таки вполне понятную структуру для работы с MVC?
ЗЫ Ларавел, однако, я не пробовал.
В тексте моего комментария нет данного слова и, как видим, комментарий изначально таким был, без изменений.
Так что свои додумки не нужно приписывать другим людям.
Прям конкретный пример? Если взять Yii как бэкенд то там есть неплохой REST генератор.
'rules' => array(
array('restUser/index', 'pattern' => 'api/v1/users', 'verb' => 'GET'),
array('restUser/view', 'pattern' => 'api/v1/users/<id>', 'verb' => 'GET'),
array('restUser/create', 'pattern' => 'api/v1/users', 'verb' => 'POST'),
array('restUser/update', 'pattern' => 'api/v1/users/<id>', 'verb' => 'PUT'),
array('restUser/delete', 'pattern' => 'api/v1/users/<id>', 'verb' => 'DELETE'),
)
Route::get('api/v1/users', 'UserController@index');
Route::get('api/v1/users/{id}', 'UserController@view');
Route::post('api/v1/users', 'UserController@create');
Route::put('api/v1/users/{id}', 'UserController@update');
Route::delete('api/v1/users/{id}', 'UserController@delete');
Второй вариант не совсем корректен, он заменяется на:
Route::resource('api/v1/users', 'UserController');
http://www.yiiframework.com/doc-2.0/guide-rest-routing.html:
'urlManager' => [
'enablePrettyUrl' => true,
'enableStrictParsing' => true,
'showScriptName' => false,
'rules' => [
['class' => 'yii\rest\UrlRule', 'controller' => 'user'],
],
]
For example, the above code is roughly equivalent to the following rules:
[
'PUT,PATCH users/' => 'user/update',
'DELETE users/' => 'user/delete',
'GET,HEAD users/' => 'user/view',
'POST users' => 'user/create',
'GET,HEAD users' => 'user/index',
'users/' => 'user/options',
'users' => 'user/options',
]
Так что как-то не убедительно.
use yii\web\Controller;
use yii\filters\AccessControl;
class SiteController extends Controller
{
public function behaviors()
{
return [
'access' => [
'class' => AccessControl::className(),
'only' => ['login', 'logout', 'SIGNUP'],
'rules' => [
[
'allow' => true,
'actions' => ['login', 'signup'],
'roles' => ['?'],
],
[
'allow' => true,
'actions' => ['logout'],
'roles' => ['@'],
],
],
],
];
}
// ...
}
Route::group(['middleware' => ['auth', 'role:editor']], function () {
Route::get('/', function () {
// Использует посредника Auth
});
Route::get('user/profile', function () {
// Использует посредника Auth
});
});
'components' => [
// ...
'i18n' => [
'translations' => [
'app*' => [
'class' => 'yii\i18n\PhpMessageSource',
//'basePath' => '@app/messages',
//'sourceLanguage' => 'en-US',
'fileMap' => [
'app' => 'app.php',
'app/error' => 'error.php',
],
],
],
],
],
\Yii::t('app', 'welcome');
В Laravel просто натыкать файлики:
/resources
/lang
/en
messages.php
/es
messages.php
trans('messages.welcome');
$model = new \app\models\ContactForm();
// populate model attributes with user inputs
$model->load(\Yii::$app->request->post());
// which is equivalent to the following:
// $model->attributes = \Yii::$app->request->post('ContactForm');
if ($model->validate()) {
// all inputs are valid
} else {
// validation failed: $errors is an array containing error messages
$errors = $model->errors;
}
public function rules()
{
return [
// the name, email, subject and body attributes are required
[['name', 'email', 'subject', 'body'], 'required'],
// the email attribute should be a valid email address
['email', 'email'],
];
}
public function store(Request $request)
{
try {
$this->validate($request, [
'name' => 'required',
'email' => 'required|email',
'subject' => 'required',
'body' => 'required',
]);
} catch(\Illuminate\Foundation\Validation\ValidationException $e) {
return $e->getResponse();
}
// Статья прошла проверку, сохранение в БД...
}
Я могу продолжить…
Второй вариант этого примера тоже можно сделать на порядок удобнее:
class UserStoreRequest extends FormRequest
{
public function rules()
{
return [
'name' => 'required',
'email' => 'required|email',
'subject' => 'required',
'body' => 'required',
];
}
}
// Controller
public function store(UserStoreRequest $request)
{
/// Запросы на этот метод всегда будут валидными и содержать верные данные
return User::create($request->all());
}
Вот по переводам не стоит даже сравнивать. В Yii intl со всеми его фичами. То, что в Laravel на эту тему, не дотягивает даже до Yii 1.1. Скорее всего, причина в географии основных авторов и пользователей фреймворка. Для штатов переводы, мягко говоря, не актуальны.
DSL в котором чёрт ногу сломит, вместо Symfony\Laravel совместимого синтаксиса.
Почему? Тот же i18n мы помогли допилить в Aura.
Это не так просто, как может показаться. Особенно учитывая обратную совместимость. Так-то я лично ничего против отдельных библиотек не имею, если они качественно сделаны.
Так мы говорим про сейчас, а не про 2011 год, когда эти решения принимались.
Не всё так однозначно. С одной стороны "такое есть только у нас" — как бы и плюс фреймворку. С другой — универсальные библиотеки проще поддерживать, хоть и сложнее написать. Они потенциально могут получить больше пользователей и pull request-ов.
Вообще цель Yii не сманить всех юзеров и получить с них какой-то профит, а дать сообществу (и себе в том числе) отличный инструмент для API и веб-разработки.
что это дает? ни монетизации, ни вклада в php-сообщество
ни один человек не перейдет на yii ради валидации, а замкнутость внутри себя ничего хорошего не дает ни yii ни разработчику.
Очевидно, это даёт конкурентное преимущество при начальном выборе фреймворка разработчиком. Если мне нужно сделать REST API, я предпочту фреймворк, который умеет REST API из коробки, а не просто фреймворк и непонятно какого качества сторонний пакет. Ну и по аналогии с другими фичами всё то же самое.
ни один человек не перейдет на yii ради валидации
Ради одной валидации — нет. Ради валидации, кодогенерации, ActiveRecord, скорости работы и других понравившихся моментов — вероятно. Особенно когда альтернатива — делать что-либо с нуля, тратя на это своё драгоценное время.
ну и что в итоге в yii есть, что дает преимущество для джуниора? intl-форматирование вряд ли можно к этому отнести — какие-то плюсы становтяся видны только после какого-то опыта. gii — ну ок. Все фичи так или иначе процентов на 80-90 присутствуют везде, но «раздербаненому» ларавелу это не мешает набирать популярность.
И какие преимущества «блокируют» разнос функционала по пакетам? Наверное дело не в этом?
Я отвечал на вопрос «что это дает?» с точки зрения завоёвывания первого места среди фреймворков и всего такого. В случае Yii цели непременно стать первым и конвертировать своё первое место в деньги нет. Yii никогда не был коммерческим и, возможно, никогда не будет. Мы просто делаем удобный нам и нашему сообществу инструмент.
Теперь отвечу на вопрос о том, что именно блокирует разнос функционала по пакетам. Это банально обратная совместимость. Сломать всё и выпустить Yii 3.0 в виде ядра и библиотек — это не наш метод. Времени поддерживать 1.1, 2.0 и 3.0 одновременно у нас нет. Останется множество проектов на Yii 2.0, которые не смогут мигрировать (как это уже случилось с 1.1). Просто взять и кинуть сообщество — это неправильно. Поэтому когда и если мы примемся за выделение отдельных библиотек, делать мы это будем постепенно. Чтобы дать возможность безболезненно мигрировать.
Тут все просто — либо да, либо нет.
Если да, то поехали. Можно начать с выноса db-слоя и создания соответствующих интерфейсов и адаптеров в оставшейся части фреймворка, и зарелизить в 2.5/3.0.
Если нет, то даже обосновывать не нужно, и этот подтред существует зря.
http://www.yiiframework.com/doc-2.0/guide-tutorial-i18n.html#message-formatting
Например, встроенные правила плюрализации для большинства языков нашей планеты.
'rules' => [
['class' => 'yii\rest\UrlRule', 'controller' => [
'subject',
...
],
],
Ну а в плане реализации? В Yii стандартные CRUD есть из коробки. Методы в контроллерах не дублируются.
Вот по переводам не стоит даже сравнивать. В Yii intl со всеми его фичами. То, что в Laravel на эту тему, не дотягивает даже до Yii 1.1. Скорее всего, причина в географии основных авторов и пользователей фреймворка. Для штатов переводы, мягко говоря, не актуальны.
В данной ситуации я — пользователь и сравниваю то, с чем успел поработать. Если нужен именно intl — уверен, под laravel есть соответствующий extension. В случае Laravel — в 80% случаев все работает из коробки так, как требуется в большинстве прикладных задач. В Yii же — всегда нужно править конфиги, где-то что-то допиливать, а порой и вендор переопределять. Такая кастомизация — это не плохо, да только время разраба на это расплывается.
Задача перевести приложение на 10—20 языков, в которых ни один из программистов ничего не понимает, довольно типична. Особенно для коробочных устанавливаемых продуктов. Разве не так?
Задача перевести приложение на 10—20 языков, в которых ни один из программистов ничего не понимает, довольно типична. Особенно для коробочных устанавливаемых продуктов. Разве не так?
На моей практике коммерческой разработки это происходит обычно так — программисту передают переводы нужной локали и он их сам добавляет. Вендорных переводов, как правило, остается >30%
Вчера быстро погуглил, нашел вот такой пакет. Не тестировал, но взял на заметку.
Почти торт. Осталось чуть допилить, чтобы обойти баги PHP.
Ну а в плане реализации? В Yii стандартные CRUD есть из коробки.
class SomeController extends ActiveController
{
public $modelClass = SomeModel::class;
}
Ну и описание фильтров сюда еще добавится.
Если писать RESTful сервисы — этого должно хватать.
Просто в Yii довольно много всего из коробки (как работает не важно). как в Laravel не знаю.
И вообще пора уже больше и больше завоевывать Laravel рынок в рунете, ато не порядок. Yii и других обижать не нужно, Yii2 тоже отличная вещь. Или тот же Symfony(Laravel кстати активно использует компоненты оттуда), просто команде Laravel, помимо хорошего фремворка, удалось создать звезду из него, благодаря популярности он быстро обрастает фишками, функционалом, расширениями и решениями для обхода кучи проблем. Еще позволяет еще меньше кодить(это касается рутины), а сосредоточится на важных архитектурных моментах. Для любителей стабильности, начиная с версии 5.1 появились LTS релизы.
Короче говоря есть смысл задуматься и на досуге попробовать что-то собрать, порог вхождения для любителя последних технологий и модных фишек PHP достаточно легок.
Лично я знакомился с Ларой когда только 5.0 вышла в свет. Уже тогда глядя на 4.2 видел значительную разницу. Кстати, в изучении пришлось очень тяжко, т.к. документация по 5.0 была только на офф сайте в виде текста и обо всем приходилось либо догадываться методом «научного тыка», либо вчитываться в доку. А сейчас, как написал чуть выше, версия 5.3 для новичков стала очень простой. Радует)
Я с коллегами знакомился с ларавелем когда выша версия 4.0 или 4.1 — точно не помню.
После этого изменения до 4.2 были вполне себе неплохими, обновились.
Теперь 4.2 устарела, не LTS, баги не будут правиться, уже сталкивался с этим — предлагают обновляться.
А проектов уже больше десятка.
Теперь выходит 5.3. Он не LTS, изменения с 5.0 до 5.3 по структуре и прочему были значительными, нет обратной совместимости.
И я теперь даже не знаю на какой версии начинать проекты. 5.1 LTS, но там много чего нет, 5.3 уйдёт в небытие и просто так обновиться до следующего LTS (5.6 например) может не выйти.
Это очень сильно огорчает.
По поводу LTS даже не подскажу — у меня всего пара проектов, которые легко (ну, почти легко) обновляю до свежей версии.
Дополнительно скажу мнение, пусть возможно и непопулярное.
То, что они не следуют SemVer, нарушается обратная совместимость и происходят кардинальные изменения в рамках мажорной версии (5-ая), означает только то, что фреймворк ещё не зрелый.
И вот моя заметка для начинающих: надо иметь это ввиду и понимать, что в любой момент всё может поменяться.
По моему личному мнению, дело не в зрелости, нет смысла погружать себя в рамки обратной совместимости, все шагают вперед, я привык все держать на последних версиях, если не забивать на маленькие апдейты, то поддержка не станет апокалипсисом. А учитывая насколько большую аудиторию имеет данный фреймворк, собственно как и комьюнити то проблем с подобными выворотами у них не возникает, а мы имеем свежачек.
Как по мне, фреймворк можно назвать зрелым, когда у него не выходят минорные релизы, где постоянно меняется структура и ломается обратная совместимость.
Я тоже люблю держать свои личные проекты на последних версиях.
Но не проекты на работе, над которыми работает 5 человек, и где не хотелось бы останавливать их работу ради обновления с нарушенной обратной совместимостью, переносить на другой сервер ради php 5.6. И уж тем более когда таких проектов больше 10.
По факту изменений структуры в минорных версиях, нигде не видел чтобы кто-то регламентировал это, более того мы можем тогда ругать разработчиков PHP за то, что эти гады добавляют и изменяют функциональность в минорных версиях(если смотреть на это взглядом сверху) :) в общем-то подобный подход и дает свежачек этому фреймворку
Laravel поддерживает php7 и 5.6, все что ниже уже давно «протухло», не выпускаются даже фиксы по безопасности: http://php.net/supported-versions.php
Я думаю если на проект вброшено аж 5ppl команда, то она следит за безопасностью продукта и уже давно должна была напинать под зад сисадмину для перехода на новую версию.
Хотя это уже все придирки, да и в общем то… я сейчас на должности Java программиста, так что мне грех Php обсуждать :)
НО как только предложил руководству (лирическое отступление — руководство — это программеры, разработавшие сайт) перейти на пых 7, мускул 5.7 и вообще сайт с нуля переписать на фрейме, посыпалась куча возгласов на тему скорости обработки, «загруженности» кода и прочего. И пофигу, что их сайт открывается тыщу лет при инете в 50 метров на мощном компе, и пофиг что сделал тестовый раздел и показал, что на Ларе с полной версией бутстрапа страница генерится за 10-40 миллисекунд. МИЛЛИСЕКУНД, КАРЛ! А их сайт генерится около 400-1500 миллисекунд, судя по консоли разработчика в хроме…
А по теме, лично я тоже за переход. Вот, как в статье написано, переход занимает 2-3 часа. У меня сейчас проект на стадии разработки — его апгрейдил с 5.2 до 5.3 минут за 30: создал новый проект, подключил нужные пакеты, перекинул код контроллеров, роуты и прочее. Все. Готово. Работает как новый)
Так и делали.
Вот, например, обнаружился баг в зависимости ларавела: https://github.com/laravel/framework/issues/13250
В итоге сделали использовали https://getcomposer.org/doc/04-schema.md#replace — сделали форк и подменили пакет.
Единственное хочу отметить, тенденция фреймворков у которых почти 99% функционала идет out of the box ведет к тому, что люди пишут аппликухи быстрее, но не понимают как вещи работают under the hood. Идеальный пример — Java Spring. Провожу интервью по 3-4 человека в неделю, народ разворачивает API на Спринг буте за пару минут, но когда задаешь вопросы как работает @AutoWired или другие вещи — люди теряются и начинают рассказывать о черной магии…
Так она и есть для них чёрная магия. Не каждый лезет под капот инструмента и разбирается в его внутренностях. Если инструмент хороший, документации, как правило, достаточно, чтобы в исходник не заглядывать.
Ну, кто-то опускает, а кто-то лезет в исходник и ищет правду. В этом и разница между junior и выше.
Фреймворки — вещь отличная, но их использование должно мотивировать, а не тормозить саморазвитие.
Фреймворк — инструмент. Мотивировать — не его задача как не задача, например, электрической отвёртки ломаться и заставлять рабочего прокачивать кисти рук.
Идеология идеологией, а реальность, особенно в PHP и вебе, вносит свои коррективы. Вот в приложении не стал бы париться из за единичной просадки в пару миллисекунд, а в фреймворке приходится потому что эта единичная просадка может использоваться в реальных продуктах тысячи раз на страницу. Приходится жертвовать.
Вот за это им жирнючий минус. Удобная штука… Была…
Вышел релиз Laravel 5.3