opencart или woocomerce

opencart или woocomerce

Чат по ларе, соответственно и вопрос касается исключительно лары.

пэхапэ

На чистом с 0 , а вы мазахист батенька))

Никто не пилил е-коммерц проектов на ларке?

я советую что лучше для ИМ, как по мне пилить велосипед на ларе дольше чем использовать готовое решение со стороны, но вам решать куда бюджет сливать

Эм)) Знатаки, внимание вопрос ? битрик - ооп или нет?)

Битрикс*

Битрикс говно

Битрикс говно

+++++

нет

Это понятно))

Причем полное!

?

нет

А почему, если кратко

через функии работает

Ну на сколько я помню он аля MVC был, через функции и апи, вдруг что поменялось)

https://b.yasb.exileed.com/t/laravel_pro

ребята, обновляю данные в таблице user, и передаю данные во вюшку если передать Auth::user() то во вюшке я получаю данные до изменения, если же передам User::where('id', Auth::user()->id)->first() то получаю уже новые данные

как этот момент поправить?

для обновления модели используй Auth::user()->fresh() или Auth::user()->refresh()

Почему все упорно пишут Model::where('id', $id)->first() вместо Model::find($id) ? Неужели все primary key меняют? Или запись find($id) чем то плоха

запрос то один и тот же

cкорее на случай изменения первичного ключа. Мало ли, что кому в голову стукнет. Скажут, допустим, что мы создаем новый первичный ключ, ибо старый чем-то плох. А логика уже прописана. И везде бегай, ищи, где нужно поменять "find($id)" на "where('old_primary_key', $id)". Да и не нужно бегать в модель каждый раз, чтоб вспомнить, что у тебя первичным ключем выставлено. Либо просто от незнания о существовании метода find() ¯\_(ツ)_/¯

запрос то один и тот же

но разве laravel это не про элегантность кода и чистоту :) я понимаю что запрос тот же

cкорее на случай изменения первичного ключа. Мало ли, что кому в голову стукнет. Скажут, допустим, что мы создаем новый первичный ключ, ибо старый чем-то плох. А логика уже прописана. И везде бегай, ищи, где нужно поменять "find($id)" на "where('old_primary_key', $id)". Да и не нужно бегать в модель каждый раз, чтоб вспомнить, что у тебя первичным ключем выставлено. Либо просто от незнания о существовании метода find() ¯\_(ツ)_/¯

Вот это реальная причина и польза использования where, хотя не помню на практике что бы была необходимость сменить ключ в процессе еволюции проекта)

меня больше удивляет почему юзают find а не findOrFail который в 90% случаев гораздо правильнее

меня больше удивляет почему юзают find а не findOrFail который в 90% случаев гораздо правильнее

Потому что перед этим заюзали праивло валидации exist

Потому что перед этим заюзали праивло валидации exist

ужаснейшее правило :))

никогда не надо его юзать

поч?

ну... если приложение простейшее. без логики. тупой интерфейс взаимодействия с базой, то там наверно пофиг. можно все что хочешь юзать.

меня больше удивляет почему юзают find а не findOrFail который в 90% случаев гораздо правильнее

ну не всегда нужен феил если записи нет)

ну не всегда нужен феил если записи нет)

поэтому я исказал что в 90% случаев

ну... если приложение простейшее. без логики. тупой интерфейс взаимодействия с базой, то там наверно пофиг. можно все что хочешь юзать.

это не аргумент. почему не стоит юзать правило exist в валидации во всех остальных случаях?

потмоу что HTTP слой не должен знать где хранятся данные.

это вообще не его дело. и от этого лишь большие проблемы

достаточно добавить softDelete и придется менять все правила валидации

потмоу что HTTP слой не должен знать где хранятся данные.

Т.е. ты предлагаешь в ХТТП слое валидацию делать чисто по формату данных, а остальную логику, типа проверки существования в хранилище и прочие, делать в сервисном слое?

достаточно добавить softDelete и придется менять все правила валидации

Не придется, там через квери билдер проверяется, достаточно только глобальный скоуп АР модели установить.

Т.е. ты предлагаешь в ХТТП слое валидацию делать чисто по формату данных, а остальную логику, типа проверки существования в хранилище и прочие, делать в сервисном слое?

угу. ну там все сложнее но примерно так

более того.. я предлагаю ее даже дублировать

достаточно добавить softDelete и придется менять все правила валидации

'exists:table,column,deleted_at,NULL'

но для простеньких приложений это реально не надо

'exists:table,column,deleted_at,NULL'

охеренное правило! мне нравится

?

готов обклеить ими все приложение?

?

Не придется, там через квери билдер проверяется, достаточно только глобальный скоуп АР модели установить.

но не в правиле валидации, насколько я знаю

готов обклеить ими все приложение?

Я не топлю за exists ))

угу. ну там все сложнее но примерно так

Я сейчас валидирую данные, кидаю в ДТО, вызываю сервис и в него ДТО пробрасываю. Брат жив, всё ок, контроллеры тонкие стали, времени много не занимает это.

Я сейчас валидирую данные, кидаю в ДТО, вызываю сервис и в него ДТО пробрасываю. Брат жив, всё ок, контроллеры тонкие стали, времени много не занимает это.

это хороший вариант.

Но на счет exist нужно ещё подумать, вроде всё логично, но Laravel это же в большинстве случаев для быстрой разработки, а не дрочения на слои.

Как бы exists проверяет наличие/отсутствие записи в базе, почему вы хотите от него проверки soft delete?

но... вот с бизнес-валидацией иногда не вяжется. по мне так лучше просто упасть с эксепшеном если нет такой записи

чем в правиле валидации обсасывать

а если эксплисит биндинг?

а если эксплисит биндинг?

what is explicit binding? is there implicit binding? :)

да, пардон

если чесно то я не понял что за биндинг имеется ввиду :)

и неважно явный он или нет

если чесно то я не понял что за биндинг имеется ввиду :)

https://laravel.com/docs/5.6/routing#implicit-binding

аааа. это ужасно :)

опять таки фичи для мелких приложух.

аааа. это ужасно :)

Это слишком неявная хрень.

надо будет включить это в мастеркласс :)) как пример плохого кода

надо будет включить это в мастеркласс :)) как пример плохого кода

Ну ты же сам понимаешь, что для бложиков это ок =)

Ну ты же сам понимаешь, что для бложиков это ок =)

Именно

Самое главное отучиться от этого когда пишешь чтото сложнее

Пацаны до сих пор не могут понять, чем плохи фасады и как ПРОСТО И ЛЕГКО можно от них избавиться.

Самое главное отучиться от этого когда пишешь чтото сложнее

не вижу проблем на самом деле. порезанное на слои приложение даже с неявной хренью будет весьма понятно

Есть база данных с милионом фильмов, пользователю нужно показать новые фильмы. Получается что на каждый запрос надо будет сортировать бд? Это вроде как должно занимать мого времени. Как эта проблема решается?

Есть база данных с милионом фильмов, пользователю нужно показать новые фильмы. Получается что на каждый запрос надо будет сортировать бд? Это вроде как должно занимать мого времени. Как эта проблема решается?

можешь джобой подготовливать кэши

можешь джобой подготовливать кэши

Получается что работа с большими бд сводится исключительно к кешам?

Получается что работа с большими бд сводится исключительно к кешам?

Ну... нет

Ты можешь обучить модель, а потом на вход давать ей вектор пользователя и она быстро будет тебе подыскивать

но это намного сложнее чем кэш для БД для определенного человека сделать :)

Есть база данных с милионом фильмов, пользователю нужно показать новые фильмы. Получается что на каждый запрос надо будет сортировать бд? Это вроде как должно занимать мого времени. Как эта проблема решается?

Да я думаю тут индекс по дате и все ок

Да я думаю тут индекс по дате и все ок

Смотря что ты хочешь предлагать пользователю

если тупо новые фильмы (которые новые вышли), то это одно

Ты можешь обучить модель, а потом на вход давать ей вектор пользователя и она быстро будет тебе подыскивать

У него же не рекомендательная система, а просто нужно выборку сделать новых фильмов

а если ты на основе его оценок хочешь подсовывать - то совсем другое

Новых - вышедших новых, или новых для пользователя (я например до сих пор Ситизен Кейн не видел, но это не новый фильм)

Смотря что ты хочешь предлагать пользователю

К примеру показывать пользователю таблицу в которой он может сортировать фильмы по рейтингу дате и тп

какие субд вы используете? mysql & mongodb?

mysql

К примеру показывать пользователю таблицу в которой он может сортировать фильмы по рейтингу дате и тп

А дальше?

какие субд вы используете? mysql & mongodb?

Postgres, mongodb

Если просто список фильмов и сортировка только по одному столбцу - то тебе просто нужен индекс по этому столбцу

Postgres, mongodb

а postgres чем-то лучше?

А дальше?

выдавать на них ссылки для онлайн просмотра + информация (описание и тп)

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

Тогда вообще не понимаю в чем вопрос

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

как минимум по 2-м

как ты это видишь в интерфейсе?

ну и order by field1, field2 - тоже не проблема

столбец рейтинг и дата выпуска, сортировки по убыванию / возрастанию по щелчку