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

а тут уже спорно. если версии отличаются симводически то можно и модулем обойтись, который унаследует предылущий

Ну тут зависит от различий, совместимости и поддержки. Я привел как пример.

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

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

Ну а разве одна точка входа не создает оверхед на роуты?

Ну тут зависит от различий, совместимости и поддержки. Я привел как пример.

ну я так и сказал по сути)

Ну а разве одна точка входа не создает оверхед на роуты?

создает, если валить все в одну кучу

но это если роуты явно заданы

можно ведь и автороутинг юзать

по контроллеру и экшену

не так красиво, но эффективнее, без обращения к ищачьему массиву роутов

и будет работать тупо автолоадер, который и так работает

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

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

это уже жирный конфиг http сервера) или регулярки. в любом случае так же лишняя работа

если не использовать явные роуты то пофиг

создает, если валить все в одну кучу

Они умеют кешироваться. не создаст при должном умении

Они умеют кешироваться. не создаст при должном умении

зависит от их количества

чем больше массив тем дольше из него выборка

как его не кешируй

это уже жирный конфиг http сервера) или регулярки. в любом случае так же лишняя работа

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

а вложеные роуты в модулях тем более зло

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

но можно и там и там все оставить максимально просто

как его не кешируй

мы экономим на спичках

по умолчанию йии парсит контроллер и экшен из урла

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

мы экономим на спичках

согласен, но я только что отметил новый год и можно похоливарить)

Вообще роутинг отдельная тема. В определенных случаях роутинг на if'ах бывает быстрее же.

а вообще если экономить, то на AR

согласен, но я только что отметил новый год и можно похоливарить)

я каждый день работаю, мне тоже можно

Но эти оптимизации реально могут быть полезны на больших проектах

а вообще если экономить, то на AR

он самый тяжелый кусок

Но эти оптимизации реально могут быть полезны на больших проектах

ага

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

Но эти оптимизации реально могут быть полезны на больших проектах

Вот тогда и будем про нее говорить. а преждевременная оптимизации зло.

я не о том

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

запрос через голый pdo с получением массива будет в разы быстрее

если не в сотни раз

Вот тогда и будем про нее говорить. а преждевременная оптимизации зло.

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

А если нет ? мы потеряем время и деньги. Ну если компания типо маил ру то да у них оптимизация должна быть

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

ненадо закладывать оптимизацию, надо закладывать ее возможность

т.е. максимальная абстракция и никакого хардкода

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

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

я все думаю хочу туда или нет

На вопрос, гражданин

Ну ты должен явно понимать узкие места при нагрузках и где можно сэкономить. Ну пост/гет/пут/делит это же основа рестфул

у меня время 4 38, я подвыпил, начинаю отключаться и пишу с телефона)

Соседний чат это пхпгикс?

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

Соседний чат это пхпгикс?

нет

Ну ты должен явно понимать узкие места при нагрузках и где можно сэкономить. Ну пост/гет/пут/делит это же основа рестфул

речь видимо о простом вебе

А ссылку можно?

да уже все, все ушли

речь видимо о простом вебе

Я разделял пост/гет в простом вебе для ajax к примеру.

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

если у тебя один экшен и обрабатывает форму и отдает вьюшку, то это ненадо делать в урлах. достаточно request->isPost

Я говорил что в непростых случаем я разделяю это. "заделяй и влавствуй"

это палка о двух концах

в чем профит?

зачем ты так делаешь?

страница create должна и то и то отрабатывать

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

Не должна.

должна

все от кейса зависит

Т.е. гет - отдаем страницу, если есть js грузим ajax, если нет сайт работает так же.

если используешь толькл два метода то ненадо, если больше, то надо, что бы не плодить проверки в экшене

Кстати. Вопрос о рендеринге на клиенте. Что думаете об этом?

эм . ну как бы удобнее разделять ответственность

ERROR: S client not available

чем все пихать в 1 экшен

Кстати. Вопрос о рендеринге на клиенте. Что думаете об этом?

тоже когда как

код лучше читается

Кстати. Вопрос о рендеринге на клиенте. Что думаете об этом?

я как пользователь, я не годую

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

тоже когда как

Ну просто как по мне рендеринг на клиенте не должен быть панацеей. Если выключен жс, можно отдать и так

жс сейчас выключен только в курле/вгете и в links

уже все работает на жсе

у меня тоже иногда выключен

Ну в браузере можно выключить же

зачем?

это как выключить браузер

При этом многие ангуляры и прочие при выключенном жс отдают пустоту

реальо чем выключать жс - грузите все через линкс)

При этом многие ангуляры и прочие при выключенном жс отдают пустоту

ибо нех

А нафига он нужен для простого сайта. Нет же они блять туда 3мб скриптов фигачата ради 1 фитчи

А нафига он нужен для простого сайта. Нет же они блять туда 3мб скриптов фигачата ради 1 фитчи

но ты же не собираешься пихать мусор в сайт?

на телефоне, почти всегда вырублен жс

но ты же не собираешься пихать мусор в сайт?

я ? стараюсь рендерить на сервере. хотя на рабочем проекте такого нет. ибо это большое приложение аналитики.

Ну да. Я стараюсь на проектах где реально не обойтись без js использовать noscript тег для заглушек. Мало кто так делает сейчас. Я по специфике фулл-стек, поэтому занимаюсь и вёрсткой, скриптами итд

я тоже

и считаю что если пользователь вырубил жс - это его проблема

такое стану запиливать только по тз

Ян, а ты работал с вью.джс?

нет

наркоманы. я тупо бекенд . этот жс не люблю

должна быть гармония

и рендеринг на клиенте экономит трафик и время на рендер

Я просто пытаюсь понять в общем суть js-фреймворков. Мне в проектах хватает тупо jquery/js native, не пойму для чего нужны ангуляры, реакты итд

ну вот у нас реакт .

и удобнее им динамические хрени делать

Я просто пытаюсь понять в общем суть js-фреймворков. Мне в проектах хватает тупо jquery/js native, не пойму для чего нужны ангуляры, реакты итд

для спа. т.е. самостоятелбного приложения на жс работающего по апи