Нужен ли контроллер? сейчас пишу фронтенд для некой системы
роутер матчит урл и направляет все в несколько контроллеровfunction indexAction( $data )
{
switch()
{
case 1: return $this->render( [ "article" => [..], "events" => [ ..] ] );
case 2: return $this->render( [ "article" => [..], "related_articles" => [ ..] ] );
case 3: return $this->render( [ "folder" => [..], "child_articles" => [ ..] ] );
}
}
ессно в проекте не switch а куча проверок, определение типа контента, определение конфигурации и т д
Т.е это анализ реквеста и извлечении данных ( это не просто Post как во всех гайдах по фрейворкам, в зависимости от запроса, конфига и еще нескольких факторов которые могут появится позже, извлекается article и events или articles и related_articles, кроме извлечения данные могут агрегироватся и т д )
как это сделать по уму?
у меня крутится в голове мысль направить все запросы в некий сервис который будет делать этот анализ и возвращать обьекты;
- simplePage
- twoColumnArticlePage
- twoColumnActiclePageWithEvents
- gridArticlePage
т.е return $twoColumnActiclePageWithEvents->render();
все эти классы наследуются от базового в который запихнуть twig
PS. это часть приложения будет только отображать контент. никаких других routes дергаюших контроллеры не будет
Нужен ли контроллер? сейчас пишу фронтенд для некой системы
роутер матчит урл и направляет все в несколько контроллеровfunction indexAction( $data )
{
switch()
{
case 1: return $this->render( [ "article" => [..], "events" => [ ..] ] );
case 2: return $this->render( [ "article" => [..], "related_articles" => [ ..] ] );
case 3: return $this->render( [ "folder" => [..], "child_articles" => [ ..] ] );
}
}
ессно в проекте не switch а куча проверок, определение типа контента, определение конфигурации и т д
Т.е это анализ реквеста и извлечении данных ( это не просто Post как во всех гайдах по фрейворкам, в зависимости от запроса, конфига и еще нескольких факторов которые могут появится позже, извлекается article и events или articles и related_articles, кроме извлечения данные могут агрегироватся и т д )
как это сделать по уму?
у меня крутится в голове мысль направить все запросы в некий сервис который будет делать этот анализ и возвращать обьекты;
- simplePage
- twoColumnArticlePage
- twoColumnActiclePageWithEvents
- gridArticlePage
т.е return $twoColumnActiclePageWithEvents->render();
все эти классы наследуются от базового в который запихнуть twig
PS. это часть приложения будет только отображать контент. никаких других routes дергаюших контроллеры не будет
роутер матчит урл и направляет все в несколько контроллеровfunction indexAction( $data )
{
switch()
{
case 1: return $this->render( [ "article" => [..], "events" => [ ..] ] );
case 2: return $this->render( [ "article" => [..], "related_articles" => [ ..] ] );
case 3: return $this->render( [ "folder" => [..], "child_articles" => [ ..] ] );
}
}
ессно в проекте не switch а куча проверок, определение типа контента, определение конфигурации и т д
Т.е это анализ реквеста и извлечении данных ( это не просто Post как во всех гайдах по фрейворкам, в зависимости от запроса, конфига и еще нескольких факторов которые могут появится позже, извлекается article и events или articles и related_articles, кроме извлечения данные могут агрегироватся и т д )
как это сделать по уму?
у меня крутится в голове мысль направить все запросы в некий сервис который будет делать этот анализ и возвращать обьекты;
- simplePage
- twoColumnArticlePage
- twoColumnActiclePageWithEvents
- gridArticlePage
т.е return $twoColumnActiclePageWithEvents->render();
все эти классы наследуются от базового в который запихнуть twig
PS. это часть приложения будет только отображать контент. никаких других routes дергаюших контроллеры не будет
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Как вы правильно заметили, направление всех запросов в некий сервис, который будет осуществлять анализ запросов и возвращать объекты соответствующих страниц, может быть хорошим подходом для организации вашего фронтенда.
Создание различных классов для разных типов страниц (например, SimplePage, TwoColumnArticlePage, GridArticlePage и т.д.), которые будут отображать контент в зависимости от запроса, конфигурации и других факторов, может упростить управление вашим кодом и сделать его более поддерживаемым.
Каждый из этих классов может иметь метод render(), который будет отображать соответствующую страницу с помощью Twig или другого шаблонизатора. Вы также можете использовать наследование для повторяющейся логики между различными типами страниц.
Такой подход позволит вам изолировать логику отображения контента от остальных частей вашего приложения и упростит добавление новых типов страниц в будущем.