для этого нужен отдельный метод

лол. ты сказал, что делаешь СЕЛЕКТ, а не c/u/d

да, селект, но формы хочц очистить как в контактон форме

который потом редиректнет юзера на прошлую страницу с message

да, селект, но формы хочц очистить как в контактон форме

селект чего?

селект чего?

данные с БД, еслть ли такойто такойто адрес

опиши логику

того, что реализуешь

[name, email, text]

типичная контактная форма

опиши логику

форма, с полем [text], отправляеться в котроллер, узнаю есть ли такой адрес, вывожу юзеру инфу

мол такой-то юзре существует?

на той же странице вывожу инфу

мол такой-то юзре существует?

адрес

редиректай обратно

делай отдельный метод

для запроса

потом return redirect()->back().....

и на странице check делай есть-ли данные в сессии

или with('message', 'text')

на тот-же метод отправлять запрос имеет смысл только, когда в get передаёшь данные для селекта чего-либо по параметрам

чтобы в url хранить это всё дело для быстрого доступа

Вопрос касается sleeping owl. Добрый день, сделал рубрики через дерево. Есть 2 уровня. У товаров хочу сделать 2 поля, выбор рубрики, выбор подрубрики. При этом хотелось бы выбирать в 1 поле рубрику, а во втором оставались только подрубрики. Это осуществимо средствами админки?

Такой момент. Есть легаси проект. Беру ставлю числый ларавел, легаси проект кидаю в папку legacy, в роутинги прописываю: Route::any('{file}.php', function($file) { require_once ("legacy/{$file}.php"); }); начинаю переписывать и интегрировать страницы по очереди на лару нормально

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

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

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

контейнера? Docker?

контейнер ларавела, какой докер

DI

я просто выбираю между тремя стульями 1) переписать все с нуля сразу (нет) 2) страшный костыль с роутингом на легаси 3) контейнер лары и компонентное переписывание

и есть у меня ощущение что выбор между двумя оставшимися стульями в принципе таковым не является

у меня похожая ситуация, и я вот склоняюсь к варианту номер два, но это потому, что время на переписывание будет постольку-поскольку

я просто выбираю между тремя стульями 1) переписать все с нуля сразу (нет) 2) страшный костыль с роутингом на легаси 3) контейнер лары и компонентное переписывание

как удобно так и переписывай, кто тебя осудит)

Ну просто стремно юзать так нормальный фрейм.

Хотя от попытки его сделать не таким монолитным пригорело дико.

лучше да, не пытаться

имхо, самый лучший laravel-way - это юзать всю его магию по полной

согласно туториалам и заветам стауфера

и ларакастс

я просто выбираю между тремя стульями 1) переписать все с нуля сразу (нет) 2) страшный костыль с роутингом на легаси 3) контейнер лары и компонентное переписывание

Не думал над вариантом потихоньку куски старого легаси выносить в провайдеры и заворачивать в пакеты? потом взять голую лару и весь функционал накатить пакетами

как бы объяснить.. легаси - это функциональный php в котором до недавнего времена даже композера не было и на все вообще был свой костыль

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

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

ты хочешь себя мотивировать что-то с этим сделать, кроме rm -rf?)

угу. вчера на позитиве начал пакеты иллюминейта в контейнер встраивать. столкнулся со странной нумерацией пакета foundation, который не смог как-то нормально вытащить - психанул и всю лару накатил

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

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

у меня похожая ситуация, и я вот склоняюсь к варианту номер два, но это потому, что время на переписывание будет постольку-поскольку

хоть это и некрасивый вариант. И вообще начинаю думать, возможно, заюзать фалькон, т.к. на проекте 1) нагрузка 80-90к посетителей в день 2) куча php-шных скриптов, собирающих что-то в фоновом режиме.

Ларочка на большие нагрузки как? По скорости разработки-то найс, но по всяким бенчам что-то как-то так себе, или норм держит?

Всё в этом мире можно оптимизировать)

Всё в этом мире можно оптимизировать)

...особенно если выбрать сначала правильный инструмент.

Если написано херово - и работать херово будет. Лара нормально к нагрузкам, если её правильно приготовить

Ларочка на большие нагрузки как? По скорости разработки-то найс, но по всяким бенчам что-то как-то так себе, или норм держит?

ну вообще по бенчам синтетическим вторая с конца

а реальные аппы не так и плохо

просто в синтетике меряют какие-то банальные функции забывая что в сравнении с голым пхп лара еще контейнер тягает

Просто не нужно вешать дикие sql запросы на самые нагруженные ручки

Ларочка на большие нагрузки как? По скорости разработки-то найс, но по всяким бенчам что-то как-то так себе, или норм держит?

она на дне по скорости

ERROR: S client not available

щас статью найду

Просто не нужно вешать дикие sql запросы на самые нагруженные ручки

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

так что вопрос нагрузок - он такой.

Это понятно. Я к тому веду - что если стоит задача написать на ней апу для высоких нагрузок - то всё в твоих руках

нужно чётко понимать, как оно будет

Но фалькон так себе идея)

Это понятно. Я к тому веду - что если стоит задача написать на ней апу для высоких нагрузок - то всё в твоих руках

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

Но фалькон так себе идея)

а чё?

Быстрый же, как тварь.

учитывая 2) куча php-шных скриптов, собирающих что-то в фоновом режиме.

Сегодня быстрый а завтра как хипхоп

Все эти тесты - они синтетические и проводятся на голом фреймворке, без оптимизаций и прочей магии. Если написать нормальный код и оптимизировать сервер - то по скорости у тебя всё будет нормально

фалкон вроде самый быстрй

Сегодня быстрый а завтра как хипхоп

меня "калит", что у этого ебанутого фалькона, как ни зайду, сайт с докой то с ошибками, то с 404.

Все эти тесты - они синтетические и проводятся на голом фреймворке, без оптимизаций и прочей магии. Если написать нормальный код и оптимизировать сервер - то по скорости у тебя всё будет нормально

тоже верно

меня "калит", что у этого ебанутого фалькона, как ни зайду, сайт с докой то с ошибками, то с 404.

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

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

я извиняюсь, человек пожилой, не знаю - что такое хип-хоп?

Тебе в любом случае придётся колдовать, хайлоад - это дело такое

я извиняюсь, человек пожилой, не знаю - что такое хип-хоп?

Форк пхп от фейсбука

hhvm

Благодаря ему имеем 7.0

А, спасибо.

я, собственно, ещё пытаюсь понять - 80-90к уников - это уже хайлоад или ещё нет?

Это обыный трафик, я хайлоадом не назвал бы)

И не по уникам считается нагрузка)

я, собственно, ещё пытаюсь понять - 80-90к уников - это уже хайлоад или ещё нет?

нет