Вы меня запутали) Изначально обсуждалась тема, что плохого в том, что «роуты рендерят шаблоны». А если говорить лишь о URL, то разумеется не всегда возможно, или вернее сказать, не всегда целесообразно, хранить состояние приложения в путях.
Вовсе нет. Шаблон в данном случае как middleware между роутом и контроллером, смотрите пример выше про Users. А всё вами описанное можно реализовать или «по-старинке» или же через композицию. Последнее намного удобнее.
Ничего подобного, отличие лишь в том что входной точкой является шаблон. А шаблон может состоять лишь с одного компонента, например
<Users/>
. Далее вызывается контроллер «Users» и далее по старой, или вашими словами — привычной, схеме. Такое поведения на порядок лучше, чем прямой вызов контроллера «Users», так как шаблон разрешает создавать композицию из контроллеров и много прочих классных штук.
Я о PHP знаю очень мало, о Yii ещё меньше. Но выше приведённый пример мне даже очень понятен. А вот логика ваша, как бы, не совсем — метод «все()» возвращает действително «все()» из предыдущего запроса/потока/т.д… Неужели вы будете утверждать, что стримы, пайпы и трансформации это плохо?)
Популярный аргумент. Но вообще-то, принцип области ответственности для компонент никто не отменял. Чем конкретнее компонент — тем лучше. Это значит, что он не принимает внутрь посторонии компоненты, если конечно изначально не было это предусмотренно, тогда конечно и css будет другим и разметка. И более того, хорошо когда композиция компонент является плоской, а не вглубину.
) Да я так и не делаю. Просто ведь из примера — мы добавляем некий функционал к уже существующему классу, то-есть расширяем его. И это вас не смущает? А если мы хотим разбить этот функционал просто на два флага, это уже вас смущает? Или же мы делаем два расширения по очереди, это вас тоже не смущает, а вот уже параллельно, это уже не комильфо?
Вообщем о single resp. principle можно долго холиварить, но не в этом суть. Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.
У нас равносильно используются как Cookies, так и Tokens, для доступа к API. Cookies для браузеров, Tokens для приложений. Используем `access_token` вместе с `refresh_token`. У пользователя есть поле `SecurityStamp`, от него генерируем по `hmac` `refresh_token`. И собственно через него обновляем `access_token`. Также от `SecurityStamp` генерируем соль для `access_token`. При смене пароля или сброса сессий изменяем `SecurityStamp` и рефреш токены становятся не валидными. И в любой момент можем активировать проверку соли для `access_token`ов, что бы оградить пользователя от временного окно действительного `access_token`.
> Неужели никто никогда не меняет напрямую, или косвенно статус код ответа в самом приложении?
Ммм, это как?
Response.StatusCode = HttpStatusCode.BadRequest;
// или через exception
throw new HttpBadRequest(message);
// или ещё другими 100500 способами.
> Если endpoint по фазе луны определил что запрос не верный, неужели статус не измените на 400?
Нет.
Интересно, как же по вашему в этом случае приложение должно получить и отреагировать на ошибку (если мы говори о RESTful запросах и json формате)? lair упоминает о адекватном использовании существующих статусов. И действительно, все так делают, вы наверное первый от кого я слышу, что нельзя в приложении менять статус на 400, например.
lair, «адекватно-не-адекватно» это в любом случае «использование» в целях приложения, и я к тому и веду, что раз мы уже используем статусы, то чисто из мышления программиста у меня возник вопрос, ведь это абсолютно не DRY менять http-status, и ещё! дополнительно! передавать конкретный статус или в кастомном заголовке, или же где-то в теле ответа. И клиент тоже соответственно должен реагировать на http статус, a потом ещё на конкретный статус ответа.
Неужели никто никогда не меняет напрямую, или косвенно статус код ответа в самом приложении? Если «нет», то тут вы меня удивите, а если «да», то речи о разделении транспорта и приложения уже быть не может. Или мы как-то друг друга не верно понимаем? Или ещё пример: Если endpoint по фазе луны определил что запрос не верный, неужели статус не измените на 400?
Согласен, так оно и есть. Но на данный момент, мне кажется, это вовсе не два изолированных уровня, особенно в контексте API ресурсов, ведь за частую, как раз приложение решает или это Bad Request, или Conflict, или что-то там ещё. Выходит эти уровни уже давно смешаны. Поэтому пора бы уже сделать окончательное смешивание.
Да, это действительно отличный вариант! Не хочу писать это слово, «но» это уже из области пользовательских заголовков. А работа лишь с http статусом была бы предпочтительнее.
Не хотел приводить конкретный пример, что бы не обсуждать частный случай. Но представьте, у нас есть игра, и некий ресурс, который возвращает актуальный статус игры: Фаза1, 2… 10. Хотелось бы, например, возвращать коды 251, 252… 260 соответственно. Тогда даже простым HEAD запросом можно уже знать состояние. Или другая ситуация с ошибкой валидации запроса: 471 — неверный параметр «А», 472 — конфликт значения «Б», и т.д.
никто не мешает отвечать статусом 400 или 500 (в зависимости от того, клиентская ли ошибка) и отдавать в теле ответе, скажем, JSON
Мы так и делаем сейчас, другого варианта пока нет. Но повторюсь, что конкретный статус непосредственно в заголовках мне кажется лучше, ведь а) можно HEAD запросом уже получить состояние и б) не нужно повторяться (один код в заголовках, и другой код в теле).
Но к сожалению на данный момент нет общепринятого промежутка для пользовательских статусов, например 45X-49X;55X-59X;7XX-9XX;, или другой способ: конкретный номер через точку:400.ХХХ.
Вот меня уже давно мучает вопрос по custom http codes. При ошибках нам всегда нужно приложению отдавать конкретный номер ошибки, сейчас отдаем более подходящий стандартный http статус, а в теле ответа уже код конкретной ошибки. Боюсь за неадекватное поведение разных прокси у клиентов. Но такое дублирование разных кодов, сначала в заголовках, а потом в теле мне не совсем нравится. Есть у кого-то идеи по этому поводу или даже опыт работы с пользовательскими статусами?
`FooAsyncComponent` блокирует: а) рендеринг `footer`a, б) блокирует лишь отправку клиенту, в) не блокирует? Если последнее, то как происходит потом вставка компонента в DOM перед футером? Вместо компоненты посылается изначально placeholder?
Размер chunka отсылаемого клиенту контролируется нодовским стримом?
Спасибо.
Главное что бы документация была! и без ошибок) Во всех подходах есть и минусы и плюсы. В вашем варианте мне особенно понравилась генерация интеграционных тестов апи. А валидацию входных моделей делаете на освное того же json, или?
Не могли бы вы подробнее остановиться на этом моменте? Это ведь довольно распространенная практика что за путём регистрируется лишь шаблон.
А как быть если для изменения `doBaz` и для нового метода `doGood` нам нужно 2 Флага?
Вообщем о single resp. principle можно долго холиварить, но не в этом суть. Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.
+n) раздельные фичи для класса `Foo` и в конфигурации у нас свойства: `enableFooFeatureА` и `enableFooFeatureB`?Интересно, как же по вашему в этом случае приложение должно получить и отреагировать на ошибку (если мы говори о RESTful запросах и json формате)? lair упоминает о адекватном использовании существующих статусов. И действительно, все так делают, вы наверное первый от кого я слышу, что нельзя в приложении менять статус на 400, например.
lair, «адекватно-не-адекватно» это в любом случае «использование» в целях приложения, и я к тому и веду, что раз мы уже используем статусы, то чисто из мышления программиста у меня возник вопрос, ведь это абсолютно не DRY менять http-status, и ещё! дополнительно! передавать конкретный статус или в кастомном заголовке, или же где-то в теле ответа. И клиент тоже соответственно должен реагировать на http статус, a потом ещё на конкретный статус ответа.
Мы так и делаем сейчас, другого варианта пока нет. Но повторюсь, что конкретный статус непосредственно в заголовках мне кажется лучше, ведь а) можно HEAD запросом уже получить состояние и б) не нужно повторяться (один код в заголовках, и другой код в теле).
Но к сожалению на данный момент нет общепринятого промежутка для пользовательских статусов, например
45X-49X;55X-59X;7XX-9XX;, или другой способ: конкретный номер через точку:400.ХХХ.`FooAsyncComponent` блокирует: а) рендеринг `footer`a, б) блокирует лишь отправку клиенту, в) не блокирует? Если последнее, то как происходит потом вставка компонента в DOM перед футером? Вместо компоненты посылается изначально placeholder?
Размер chunka отсылаемого клиенту контролируется нодовским стримом?
Спасибо.