А
Arman Poghosyan
На этапе настройки
до загрузки роутера?
Size: a a a
2020 August 17
AP
этапе самого конфига роутов (маршрутов)
А
так хранить то дефинишены надо а не объекты
AP
вот у нас Route::get(...)->addMiddleware() (точнее уже Route::get(...)->handler(...)). Куда девать их?
AP
так хранить то дефинишены надо а не объекты
Ну так в моей реализации это всего лишь массив, можно и сериализировать, если надо. Там ничего на этапе конфига не происходит.
AP
В итоге это как бы тот же дефинишн о котором ты говоришь
А
Arman Poghosyan
Ну так в моей реализации это всего лишь массив, можно и сериализировать, если надо. Там ничего на этапе конфига не происходит.
а что плохого в массиве? (хотя для памяти лучше объект)
А
я вроде не выступаю против DTOшек )
AP
а что плохого в массиве? (хотя для памяти лучше объект)
Ничего, он этот массив просто может в себе хранить любой тип/формат (хоть string, хоть объект, хоть callable), не он решает, какой формат правильный, что и как с этим делать, а решает диспетчер уже потом, когда надо что-то делать с матченым маршрутом.
AP
Я единственную проблему вижу только в твоем следующем issue
AP
А
я просто предлагаю больше контрактов: классы для дефинишенов роутов (дтошки предопределённой структуры); контракты для дефинишена пайплайна (собирается и отдаётся после матчинга роута эксекютору или диспетчеру, как не называй)
А
Arman Poghosyan
Я единственную проблему вижу только в твоем следующем issue
а тут задача в том, чтобы не засовывать стейт во внешний контейнер, а передавать всё в MatchingResult (например в атрибутах ответа)
И можно будет хоть два роутера на проекте держать и юзать поочерёдно
И можно будет хоть два роутера на проекте держать и юзать поочерёдно
AP
я просто предлагаю больше контрактов: классы для дефинишенов роутов (дтошки предопределённой структуры); контракты для дефинишена пайплайна (собирается и отдаётся после матчинга роута эксекютору или диспетчеру, как не называй)
Так если ты код смотрел, там почти то о чем ты говоришь, сам маршрут (Route) является реализацией интерфейса (контракта)
А
Arman Poghosyan
Так если ты код смотрел, там почти то о чем ты говоришь, сам маршрут (Route) является реализацией интерфейса (контракта)
ещё не смотрел. Там описание на английском, а английский заставляет мой мозг нагреваться :)
Что насчёт pipeline definition? тема оч. полезная
Что насчёт pipeline definition? тема оч. полезная
AP
а тут задача в том, чтобы не засовывать стейт во внешний контейнер, а передавать всё в MatchingResult (например в атрибутах ответа)
И можно будет хоть два роутера на проекте держать и юзать поочерёдно
И можно будет хоть два роутера на проекте держать и юзать поочерёдно
Я не об стейте пока думаю, с ним можно еще подумать. Я убрал у матчера зависимость на коллекцию и в итоге получается, что матчер не юзабельный как отдельный сервис, что по мне не очень хорошо.
А
Arman Poghosyan
Я не об стейте пока думаю, с ним можно еще подумать. Я убрал у матчера зависимость на коллекцию и в итоге получается, что матчер не юзабельный как отдельный сервис, что по мне не очень хорошо.
матчеру (я считаю) место в роутере. Это API роутера, которое должно, как результат, вернуть стейтовый объект MatchingResult с текущим роутом и всей фигнёй
Т.е. не должно быть матчера как отдельного сервиса
Т.е. не должно быть матчера как отдельного сервиса
AP
ещё не смотрел. Там описание на английском, а английский заставляет мой мозг нагреваться :)
Что насчёт pipeline definition? тема оч. полезная
Что насчёт pipeline definition? тема оч. полезная
На русском я это переписывать не собираюсь)) если что вопросы задавайте. Вместо того, что ты понимаешь под pipeline definition у меня просто котракт, который должен возвразать стэк (iterable) handler-ов (или как раньше это называлось - middlewares), по сути тот же pipeline definition, но не в текстовом формате
А
Arman Poghosyan
На русском я это переписывать не собираюсь)) если что вопросы задавайте. Вместо того, что ты понимаешь под pipeline definition у меня просто котракт, который должен возвразать стэк (iterable) handler-ов (или как раньше это называлось - middlewares), по сути тот же pipeline definition, но не в текстовом формате
а кому нужен текстовый формат такой структуры? :)
AP
матчеру (я считаю) место в роутере. Это API роутера, которое должно, как результат, вернуть стейтовый объект MatchingResult с текущим роутом и всей фигнёй
Т.е. не должно быть матчера как отдельного сервиса
Т.е. не должно быть матчера как отдельного сервиса
Я отчасти согласен. Но очень уж полезно иметь матчер, как отдельный легкий сервис только для матчинга - где нужно. Я как бы сейчас так и сделал, как ты представлял себе в этом issue и получается, что для матчинга нужно Router юзать всегда, и не как нельзя только матчер. А мне мы хотелось, чтоб оба варианта были юзабельны. Может кому наш роутер весь не нужен, а матчер нужен.