наверн какая то внутренняя оптимизация при большом колве данных

причем если смотреть в тинкере он покажет первые N а потом будет так же App\Message {#4202 …8}, App\Message {#4203 …8}, App\Message {#4204 …8}, App\Message {#4205 …8}, App\Message {#4206 …8}, App\Message {#4207 …8},

причем если смотреть в тинкере он покажет первые N а потом будет так же App\Message {#4202 …8}, App\Message {#4203 …8}, App\Message {#4204 …8}, App\Message {#4205 …8}, App\Message {#4206 …8}, App\Message {#4207 …8},

Var_dump?

print_r

Попробуй

вопрос был более чем конкретный

Память может экономят

Сам такое видел не раз

Var_dump?

dd тот же var_dump только покруче или я ошибаюсь?

dd тот же var_dump только покруче или я ошибаюсь?

dd - метод фреймворка

хелпер ф-ция

var_dump - отладочная функция php

даже тот же dumper symfony после 79-го результата тоже сворачивает результаты

даже тот же dumper symfony после 79-го результата тоже сворачивает результаты

Заложили логику, что ты все смотреть не будешь

Либо конкретизируешь выборку

есть какие-нибудь правила именования сервисов?

Для обучения лучше писать сайты без всяких готовых решений, типа orchid?

ну и еще там недавно какую-то новую админку сделали готовую для ларавель

Ясен фиг

какие вардамперы ребята, используйте xDebug, прекрасный инструмент

Никто не спорит

Ясен фиг

смотря на твоё фото я не могу тебе верить

а тебе какие док-ва нужны?

на моей стороне опыт

резюме почитать, или там, опенсорс проджекты посмотреть может?

а ?

А может хуями в личке меряться пойдете?

а ?

мне кажется ты под веществами

а че он мое эго задевает

я чувствительный

😩(

Где почитать про принятые правила именования классов: моделей, сервисов, методов и т.д?

PSR помойму 4

если я вас правильно понял

если я вас правильно понял

Всё-таки неправильно поняли. Имеется ввиду: что по меркам "красивого" кода должно содержаться в коротком имени класса. В имени переменной. Например все классы контроллеров в примерах заканчиваются на *Controller. Стоит ли так же делать с сервисами? Ну и так далее. Может где-то есть описание/стандарт/рекомендации?

аа, обычно это по договоренностям в командах

Хотя может быть и есть какой то регламент, о котором я не в курсе. Буду рад если просвятите.

Всё-таки неправильно поняли. Имеется ввиду: что по меркам "красивого" кода должно содержаться в коротком имени класса. В имени переменной. Например все классы контроллеров в примерах заканчиваются на *Controller. Стоит ли так же делать с сервисами? Ну и так далее. Может где-то есть описание/стандарт/рекомендации?

Есть рекомендации но они разнятся от автора к автору. В ларе есть конвенции только на модели. Ну и проследить какие то "тренды" можно по коду лары и в доках. Вообще большенство таких рекомендаций это вкусовщина. Очень важно одно - единообразие в рамках проекта.

Тэйлор не писал таких рекомендаций?

тейлор вроде не писал

по поводу постфиксов принодлежности как то повелось что есть классы которые маркируются постфиксом а какие то нет. На самом деле есть мнение что все постфиксы - зло. я не разделяю.

В ларе есть searchForm аналог searchModel в yii2?

В ларе есть searchForm аналог searchModel в yii2?

а кинь ссыль на доку yii по searchModel

в самой ларе ничего такого нет вроде

ребзя

а хотя ладно

http://www.yiiframework.com/wiki/653/displaying-sorting-and-filtering-model-relations-on-a-gridview/ public function search($params)

ну т.е надо самому что то похожее для проекта реализовывать

не в контроллере же это делать

http://www.yiiframework.com/wiki/653/displaying-sorting-and-filtering-model-relations-on-a-gridview/ public function search($params)

ну в общих чертах наверное это типо вот этих пакетов. - https://github.com/Tucker-Eric/EloquentFilter - https://github.com/mnabialek/laravel-eloquent-filter - https://github.com/czim/laravel-filter

найдешь лучше кинь мне плиз)

благодарю, дома ознакомлюсь

да чо искать)

проще самому написать

если не подойдет

ну собственно я вот и начал тоже искать нашел эти 3. ну и в каждом что то меня не устроило и я начал свой писать https://github.com/Larapac/QueryFilter

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

Есть страница, на которой выводится список из таблицы БД. Как наиболее правильно сделать кнопку експорта в файл excel? Интересует не сам экспорт в эксель а экспорт из уже произошедшего запроса. Я плохо разбираюсь, но догадываюсь, что можно экспортировать из полученной коллекции, но в коллекции всего 10 элементов (т.к. пагинация), а необходимо экспортировать все. Необходимо делать еще один метод, который по нажатию кнопки будет снова осуществлять поиск по базе и отдавать уже эксель?

запрос придется делать еще один вне зависимости от чего бы то нибыло

у вас в коллекции данные ограниченные пагинацией

@ellrion если потребуется помощь - могу подключиться, пакеты можно писать совместно :)

запрос придется делать еще один вне зависимости от чего бы то нибыло

спасибо

@ellrion если потребуется помощь - могу подключиться, пакеты можно писать совместно :)

если будут идеи конечно issues pr кидай

всем привет как вы создаете пакеты? при разработке функционала сразу делаете пакет в папке vendor, и работаете в нем, или после добавления фичи - новый пакет и перенос нужных файлов? и правильно ли инициализировать репозиторий внутри вендора? как лучше поступить? поделитесь, пожалуйста, опытом)

вообще главная задача научить композер различать объявленное вами пространство имен

вполне допустимо (на мой взгляд) объявить где нибудь рядом с App вашу папку

тут прописать

это composer.json

чисто теоритически заведется

ну уж лучше тогда просто указать локальный репозиторий. https://getcomposer.org/doc/05-repositories.md#path

потому что уже в пакете у тебя должен быть свой композер с автолоудом для него

согласен, не имею опыта разработки модулей до внесения их в репозиторий

а вообще допустим phpstorm умеет сразу с несколькими репами работать

вы можете как основной проект править, так и свой проект в вендоре

по крайней мере мы как то так делали)

для экспорта в excel это актуальный метод? https://inprocess.by/blog/eksport-v-excel-iz-laravel/ или есть что лучше/правильнее?

Всем привет. Нужна сила сообщества) Даже не знаю как правильно описать то что у меня не получается. Есть список сайтов , есть список тематик. У каждого сайта несколько тематик и в каждой тематике несколько сайтов. Связано это все через промежуточную таблицу и belongsToMany Сейчас при редактировании сайта мне необходимо получить список его тематик и отметить их галочками. Тематики связаны с сайтами вот так public function site() { return $this->belongsToMany('App\Site'); } получаю списко тематик вот так $themes = Theme::with( 'site' ) ->where( 'main_theme', 0 ) ->get(); оно все классно работает, но оно тянет за собой ВСЕ сайты в тематиках. А мне нобходимо получить абсолютно все тематики и только тот один сайт который сейчас редактируется, чтобы отметить что он пренадлежит той или иной тематике чекбоксом...

$site->themes()->get()?

по логике примерно так должно в ларе заехать