path параметры

Абдула ты задавай чо нить конкретное, а то наговнокодишь там :D

Абдула ты задавай чо нить конкретное, а то наговнокодишь там :D

Вооот! Поэтому хочу изучить код существующих проектов, по этому же спрашивал, есть ли открытые проекты, чтоб изучить код

По одному и тому же url делается GET, POST и DELETE запрос. Чтобы они ссылались на разные action`ы, нужно все это описать в url manager. Вот и спрашиваю как это в крупных проектах делается. Не загромаждается ли url manager правилами, когда контроллеров 10-20 и больше

По одному и тому же url делается GET, POST и DELETE запрос. Чтобы они ссылались на разные action`ы, нужно все это описать в url manager. Вот и спрашиваю как это в крупных проектах делается. Не загромаждается ли url manager правилами, когда контроллеров 10-20 и больше

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

По одному и тому же url делается GET, POST и DELETE запрос. Чтобы они ссылались на разные action`ы, нужно все это описать в url manager. Вот и спрашиваю как это в крупных проектах делается. Не загромаждается ли url manager правилами, когда контроллеров 10-20 и больше

Ты наследуйся от yii\rest\Controller и забудь о своих бедах

Вооот! Поэтому хочу изучить код существующих проектов, по этому же спрашивал, есть ли открытые проекты, чтоб изучить код

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

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

+1

снова наговнокодишь ;D

5-6 итерации сам будешь писать гайды как делать правильно

ну как вариант посмотреть https://github.com/githubjeka/yii2-rest

Эти правила же для каждого контроллера надо прописать?

Эти правила же для каждого контроллера надо прописать?

нет, правила вообще не надо писать, только если они не стандартные

Вот же в документации написано, что нужно добавить правило

https://github.com/yiisoft/yii2/blob/master/docs/guide-ru/rest-routing.md

Вот документация.

https://github.com/yiisoft/yii2/blob/master/docs/guide-ru/rest-routing.md

Имею ввиду массово на каждый контроллер

Т.е. изначально у тебя будет только одно правило

слышал, что в Yii2.1 планируют избавиться от jquery, но что-то пруфов не нашел на эту тему, да и в ветке 2.1 в composer jquery подтягивается. Может кто-нибудь поделиться ссылочками на эту тему?

@samdark а когда планируется выпилить jquery зависимости?

2.1

ну так чо список контроллеров перечислил и погнал

т.е. для каждого контроллера по 7 правил.

слишком глубоко залез для начала )

2.1

?

А если контроллеров 10, то 70 записей.

чем заменят, не в курсе?)

чем заменят, не в курсе?)

вынесут в отдельный пакет

А если контроллеров 10, то 70 записей.

не совсем так. в конфиге у тебя будет одна запись и у атрибута controllers уже массив из 70 значений

слишком глубоко залез для начала )

А как поступают, когда не "начало"

А что такого плохого в jQuery, что от него решили избавиться? ?

А что такого плохого в jQuery, что от него решили избавиться? ?

например у тебя только rest или только консоль, но ты один фиг тащишь с собой весь ненужный код в вендоре

А что такого плохого в jQuery, что от него решили избавиться? ?

в самом JQ ничего, а вот тотальная зависимость от него очень мешает.

ну и может ты свой ангуляр прикрутил или еще что

А как поступают, когда не "начало"

когда не начало конкретные вопросы задают

а не общие "с чего начать?")

не совсем так. в конфиге у тебя будет одна запись и у атрибута controllers уже массив из 70 значений

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

в самом JQ ничего, а вот тотальная зависимость от него очень мешает.

Ждём 2.1

Ждём 2.1

переписывать все по новой придется? бля я здохну

Я вообще планирую api+console скелет сделать как выйдет 2.1

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

можешь без REST правил из коробки обойтись совсем, использовать дефолтную маршрутизацию

я не проверял на 70 контроллерах скорость

честно не знаю

можешь без REST правил из коробки обойтись совсем, использовать дефолтную маршрутизацию

тогда уже не rest получится? нет?

тогда уже не rest получится? нет?

REST это не правила из коробки )

вынесут в отдельный пакет

спасибо за разъяснения ?

REST это не правила из коробки )

Я не про yii2 говорю. Я вообще о принципах REST. А в yii2 для поддержки этих принципов, используют правила URL manager`а

Пойду http://yiipowered.com почекаю. Может найду че

Пишу апи для реакта и возник спор c фронтендщиком насчет метода который выдает категории для списка в форме. Я отправляю ему как есть массив обьектов json [{"id":1, "name":"Здоровье"},...]. Он мне говорит перепиши метод, чтоб он возвращал [{"value":1, "label":"Здоровье"},...], чтоб он мог мою выдачу напрямую вставить, без цикла, который бы проходился по массиву брал бы name и вставлял в label, брал бы id и вставлял бы в value. По сути он хочет цикл из реакта перенести на бэк, чтоб я перед выдачей формировал ему необходимые обьекты. Помоему бред какой-то. Рассудите кто прав?

на бэке правильней, ибо если этим фронт начнёт заниматься, то будут тратиться ресурсы клиентской машины (о которых мы ничего не знаем)

там может быть калькулятор (как пример компьютера), и этот цикл на фронте будет довольно заметным

чтоже там за массив такой, что перебор его займёт ощутимое время?

20 элементов

Пишу апи для реакта и возник спор c фронтендщиком насчет метода который выдает категории для списка в форме. Я отправляю ему как есть массив обьектов json [{"id":1, "name":"Здоровье"},...]. Он мне говорит перепиши метод, чтоб он возвращал [{"value":1, "label":"Здоровье"},...], чтоб он мог мою выдачу напрямую вставить, без цикла, который бы проходился по массиву брал бы name и вставлял в label, брал бы id и вставлял бы в value. По сути он хочет цикл из реакта перенести на бэк, чтоб я перед выдачей формировал ему необходимые обьекты. Помоему бред какой-то. Рассудите кто прав?

Бэкендер выдает api и остальные с ним работают

но-о

у вас же команда :)

тем более тебе это сделать проще в запросе возьми поля id as value, name as label

чтоже там за массив такой, что перебор его займёт ощутимое время?

в случае компа-калькулятора любые манипуляции js'а будут ощутимо заметными

тем более тебе это сделать проще в запросе возьми поля id as value, name as label

я думал там модели и fields()

Но вопрос скорее как ВООБЩЕ правильно. Подобных списков там еще штуки 3, но элементов там не больше 20.

в случае компа-калькулятора любые манипуляции js'а будут ощутимо заметными

ну если там реакт, то комп - явно не калькулятор)

вообще правильно сделать api в виде GraphQL и отдать фронту

пускай дальше сам себе выбирает чё как хочет

ERROR: S client not available

Такое мы не потянем)

у вас же команда :)

ну тогда сайз прав

договаривайтесь :)

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

Пишу апи для реакта и возник спор c фронтендщиком насчет метода который выдает категории для списка в форме. Я отправляю ему как есть массив обьектов json [{"id":1, "name":"Здоровье"},...]. Он мне говорит перепиши метод, чтоб он возвращал [{"value":1, "label":"Здоровье"},...], чтоб он мог мою выдачу напрямую вставить, без цикла, который бы проходился по массиву брал бы name и вставлял в label, брал бы id и вставлял бы в value. По сути он хочет цикл из реакта перенести на бэк, чтоб я перед выдачей формировал ему необходимые обьекты. Помоему бред какой-то. Рассудите кто прав?

Че он мэп не осилил?

Он тоже топит за производительность

Клиент сильно нагрузит

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

Клиент сильно нагрузит

пусть с цифрами приходит )

Клиент сильно нагрузит

20 элементов? сильно нагрузит? шта?

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

жестко

В локал сторэдж положить и все

или в web SQL

парсеры вам тока спасибо скажут

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

Идею фильтровать все на клиенте я сразу отмёл

ваще он должен был отмести)

Но вот про список задумался

Со списком у меня ощущение, что он предлагает мне решить задачу специфичную для реакта на бэке.

А если появиться потом андроид приложение, то мне потом для них тоже переписывать выдачу?

причём тут реакт? реакт ничего не маппит, это просто js

Пишу апи для реакта и возник спор c фронтендщиком насчет метода который выдает категории для списка в форме. Я отправляю ему как есть массив обьектов json [{"id":1, "name":"Здоровье"},...]. Он мне говорит перепиши метод, чтоб он возвращал [{"value":1, "label":"Здоровье"},...], чтоб он мог мою выдачу напрямую вставить, без цикла, который бы проходился по массиву брал бы name и вставлял в label, брал бы id и вставлял бы в value. По сути он хочет цикл из реакта перенести на бэк, чтоб я перед выдачей формировал ему необходимые обьекты. Помоему бред какой-то. Рассудите кто прав?

сыграйте на «чуваши», кто проиграет — тот и ремапит массив, тю! ну или так — что было раньше, апи или фронт? если ты вначале дал апи, а потом уже фронтендщик начал писать под него клиент — пусть он и подстраивается

если там собственный компонент а не взятый откуда то то какая раздница будет там id илил label

Я первый писал апи)

Ну вот он и мапит теперь

ну значит твои тапки :)

Просто чувствую себя мудаком после этого

тогда пусть он подстраивается :) а то ну реально, завтра придёт андроидописец и начнёт свои права качать надо их держать в строгости, фронтендеров энтих! а то иш чо!

ешь, что дают)

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

ну и статусы типа все ок или пшел отсюдава