Comments 23
Route::get('/order', 'OrderController@index')->name('order.index');
Route::get('/order/view/{id}', 'OrderController@view')->name('order.view');
Route::get('/order/create', 'OrderController@create')->name('order.create');
Route::get('/order/update/{id}', 'OrderController@update')->name('order.update');
Route::post('/order/create', 'OrderController@create');
Route::post('/order/update/{id}', 'OrderController@update');
Route::post('/order/delete/{id}', 'OrderController@delete')->name('order.delete');
Route::resource('order', 'OrderController');
Просто почему бы и нет) А вообще говоря, вполне рабочий вариант.
Притянуто за уши, но все-таки:
- минимализм в конфигурации, указываем только то что нужно
- экономия времени при разработке — скопировали, поменяли, добавили
- минимум новых зависимостей, тот же язык программирования
- в Laravel и так часть Symfony, почему бы компоненты из другого фреймфорка не использовать
Приведите свой пример, как вы решаете эту задачу.
в Laravel и так часть Symfony, почему бы компоненты из другого фреймфорка не использовать
https://github.com/michael-vostrikov/laravel-yii2/blob/master/composer.json#L11
совсем маленькая часть yii используется
Я не использую Laravel для разработки. Мне после Zend и Symfony он не зашел (написали несколько проектов на Laravel). Но если абстрагироваться, то взял бы Symfony + EasyAdmin или Symfony + Sonata. Если есть время, то лучше %ВАШ_ФРЕЙМВОРК% + фронтенд на React, Vue, Angular2+, Ember.
Если про решение на Laravel, то наверно взял етот grid, хотя бы потому, что тянуть два фреймворка ето лишнее.
Лично для меня server-side рендеринг уже прошлое.Надо отделять мух от котлет. Чисто мое мнение.
(в общем-то в yii точно так же можно без виджетов обходиться с помощью партиалов и блоков… но как-то принято на каждый чих делать виджет-класс)
А не могли бы вы показать примерный код, что будет на сервере и на клиенте?
В общем-то вьюха с таблицей выходит не многословнее конфига GridView и по сути мало чем отличается
Спасибо. Я имел в виду сущности и интерфейс, описанные в статье, чтобы можно было сравнить, но так тоже подойдет.
вьюха с таблицей выходит не многословнее конфига GridView
У вас на конкретный грид выходит (20+30+10) + 140 = 60 + 140 = 200 строк.
У меня (40+50) + 20 = 90 + 20 = 110 строк.
В два раза меньше кода, написанного вручную, который надо поддерживать.
При этом в переиспользуемом коде есть ограничение в виде одного periodAttribute. А если мне надо период и по created_at и по last_login_at?
переносимость не завязанная на неймспейсы
Не очень понял, что это значит, но вроде у меня нет в коде чего-то, завязанного на неймспейсы. Их использование такое же, как и для любых других сторонних компонентов.
смена css-фреймворка
Смена css-фреймворка это не та вещь, которая происходит часто, а вот гриды и формы нужны для каждой новой сущности.
никаких головоломок при необходимости добавления разворачивающихся подстолбцов
За исключением того, что все это надо делать вручную, чего я и пытался избежать, подключая сторонние компоненты.
но как-то принято на каждый чих делать виджет-класс
Это делают, когда надо инкапсулировать логику по инициализации или получению данных. И хардкодить длинные пути, уходящие в vendor, тоже не очень красиво. Но если логически это именно часть верстки, то и делают через include или болки. Например, верстку формы для create и update.
При этом в переиспользуемом коде есть ограничение в виде одного periodAttribute. А если мне надо период и по >created_at и по last_login_at?
Это просто гист выдранный с конкретного проекта… он совсем простой и такого решения за глаза хватает, можно periodAttributes сделать массивом и каждый проверять.
Как вы количество строк посчитали не совсем поняла — но штука в том что пока у вас в примере самый простой грид… а если добавить аякс-свитчер, сделать редактируемый инпут, модалку или когда вам понадобится сколь-нибудь нестандартный столбец, агрегация суммы, массовые операции, или например выбор отображаемых столбцов — у вас все это быстро разрастётся плюс обрастет дополнительными костылями, за счет специфики регистрации скриптов в yii -виджетах. Штука что виджеты yii получаются с оверхедом — и как презентер, и как получатель данных (в ларе для этого предусмотрен шаринг через view-composer), и как кусок переиспользуемой вьюхи, и как регистратор скриптов. Они хороши для кодеров, но часто смешивают логику и верстку-дизайн.
Посмотрите https://backpackforlaravel.com для админки — там и гриды и формы и уже куча всего интегрированного.
Угу, "Buy license", 14 Мб, 1000 файлов, большая конфигурация и куча документации по настройке. Она сама как фреймворк.
Как вы количество строк посчитали не совсем поняла
concrete_filter.php + concrete_search.php + controller_action.php + верстка. Хотя с версткой я немного ошибся, есть общие части, но с захардкожеными id-шниками и которые нужно подключать строго внутри тега tr. Это тоже то, чего стоит избегать, особенно в однотипном коде наподобие разделов админки, где бывает много копипасты.
но штука в том что пока у вас в примере самый простой грид… а если добавить ...
Так я ж о том и прошу) Покажите сложный пример, где проявятся преимущества вашего подхода.
часто смешивают логику и верстку-дизайн
У представления есть своя логика, не надо путать ее с бизнес-логикой. Логику представления необязательно писать на javascript, с серверным рендерингом этим занимается серверный язык.
Угу, "Buy license", 14 Мб, 1000 файлов, большая конфигурация и куча документации по настройке. Она сама как >фреймворк.
Or use for free in your non-commercial applications
есть общие части, но с захардкожеными id-шниками
они не захардкоженные — там значение по умолчанию указывается. Копипасты нет — реюзабельное инклудится, базовые шаблоны сохранены в php-storm как шаблоны,
Так я ж о том и прошу) Покажите сложный пример, где проявятся преимущества вашего подхода.
Я думаю принцип и так вполне понятен… вместо yiigrid — столбцов для часто-используемого специфического функционала используются view-partial группировки/суммирование и прочее — за счет фич eloquent\collection и loop.index blade
преимущество — чистые скрипты и вьюхи удобные и понятные фронтендеру, чистые классы, никаких сторонних фреймворков
А вот и покажите серверный+клиентский код для описанной функциональности на любой из этих библиотек)
С этим лучше на тостер
большая конфигурация и куча документации по настройке
Предполагаю что вам просто не хочется изучать что-то новое, и вы пытаетесь тащить старое и привычное, и у Вопрос только в том — почему не делать на yii?
Для формбилдера кстати есть https://laravelcollective.com/docs/5.4/html
Зачем мне non-commercial, если я делаю закрытую админку для заказчика. Мне самому обычно хватает клиента к SQL.
они не захардкоженные
<div id="grid_filter"> ... <form id="grid_filter_form">
Но даже если сделать как везде, то будет сильная связанность между 2 разными вьюхами. Нужно знать негласное правило, "если я подключаю вот этот файл с вот таким id, то при подключении того файла надо указывать тот же id".
Я думаю принцип и так вполне понятен
Пока что я заметил, что надо много кода писать вручную.
за счет фич eloquent\collection преимущество
Дак и у меня модели Eloquent.
С этим лучше на тостер
Не вижу связи. Я знаю способы это сделать без тостеров. Но мне говорят, что можно сделать лучше, вот я и прошу показать это на деле. Пока что согласились только вы.
Предполагаю что вам просто не хочется изучать что-то новое
Суть не в этом. Есть разные способы это сделать, и с GridView это быстро и немного, причем это не тяп-ляп, а получается готовый к продакшену код.
Я же не просто так попросил привести другую реализацию, наоборот, я хочу узнать что-то новое, что будет полезно. Но то, что я вижу в документации, оставляет желать лучшего.
Вопрос только в том — почему не делать на yii?
У Yii свои недостатки, и к тому же тут сравнение не фреймворков в целом, а отдельных компонентов. А еще может быть уже существущий проект на Laravel.
Для формбилдера кстати есть https://laravelcollective.com/docs/5.4/html
Это аналог yii\helpers\Html. Для Bootstrap-форм надо много писать вручную. Зачем, если есть готовые компоненты? К тому же там много магии типа "If there is an item in the Session flash data matching the input name, that will take precedence over the model's value".
Если бы для Laravel были удобные аналоги, мне бы в голову не пришло интегрировать 2 фреймворка)
проблема в написании html-кода?
вообще-то он отлично пишется — отличный автокомплит + livetemplates + по css-классам в том числе
<a href="{{someurl}}" class="some class" data-role="some" id="some"> Some Name</a>
<input type="text" value="foobar" id="foo_id">пишется однофигственно
Html::a('Some Name',$someUrl,['id'=>'some','class'=>'some class','data'=>['role'=>'some']]);
Html::input('text','foobar',['id'=>'foo_id']);If there is an item in the Session flash data matching the input name, that will take precedence over the model's value
Это фича old() ларавела https://laravel.com/docs/5.4/requests#old-input — так как там прицип валидации завязан на request т.е. модели не валидные данные не присваиваются вообще в отличие от yii
… Но даже если сделать как везде, то будет сильная связанность между 2 разными вьюхами. Нужно знать > негласное правило, «если я подключаю вот этот файл с вот таким id, то при подключении того файла надо указывать тот же id».
C чего вы вообще взяли что они связаны? там где нужна конкретная связь по id он параметризуется. Нет никаких негласных правил
Просто ларавельщики привыкли к datatables https://datatables.yajrabox.com самый популярный пакет
Проблема в том, что в обоих случаях это однотипный код, который надо написать, поддерживать, и копировать в другой аналогичный раздел.
модели не валидные данные не присваиваются вообще в отличие от yii
Они должны быть не в модели, обозначающей сущность, а в модели формы. В форму на клиенте можно ввести невалидные данные, модель этой формы на сервере должна отражать положение дел на клиенте. На то она и модель. И валидация должна быть в ней, а не в сущности. В Zend, если я правильно помню, аналогичный подход, только более громоздкий, с гидрированием и фабриками.
C чего вы вообще взяли что они связаны?
<button class="btn btn-sm bg-purple" form="{{$formId or 'grid_filter'}}"><i class="fa fa-search"></i> Найти</button>
Потому что в коде так написано. Кнопка в одном partial ссылается на форму из другого partial. Id параметризуется, и надо знать, что если тут я в параметрах передал grid_filter2, значит там мне тоже надо передавать grid_filter2.
https://datatables.yajrabox.com
Выглядит неплохо, спасибо за информацию, посмотрю на досуге. Только немного смущает, что на ajax везде надо проверять.
есть же куча jQuery гридов. Kendo UI, jqueryui и так далее.
А вот и покажите серверный+клиентский код для описанной функциональности на любой из этих библиотек) Но вообще я специально поставил статью в раздел "Ненормальное программирование".
А с другой стороны, это вполне рабочее решение с минимумом настройки на официальных компонентах от разработчиков фреймворка.
Как скрестить ежа с ужом. Используем GridView из Yii 2 в проекте на Laravel