В классическом MVC приложении, каждая страница, описана в отдельном файле, например: IndexController.php, AboutController.php, ContactsController.php.
После разбора URL, например: example.com/about или example.com/about/index. Получаем контроллер AboutController.php и метод index().
В моем случает, получается некое подобие, простой CMS. Все страницы хранятся в БД, создаются, удаляются. Создавать запись в БД, а потом создавать файл контроллера, это тупость. Как правильно продумать и реализовать, отображение страниц из БД? Может для этих целей есть отдельный паттерн?
ПС: В приложении ContactsController.php наследуется от базового контроллера, и расширяется методом sendMessage($postData). (HTTP Method POST) example.com/contacts/send-message, после разбора URL, контроллер ContactsController.php метод sendMessage($postData).
UPD: Приложение существует и прекрасно работает. В базу пишет ContactsModel.php. Но раз уж используется БД, не лишним будет добавить динамические страницы.
А в чем сокровенный смысл создавать контроллер под каждую однотипную страницу, которые отличаются только контентом? Вы как-то неправильно понимаете принципы MVC. ))) Создаете ОДИН контроллер PageController и рулите в нем всеми вашими страницами.
Дмитрий, тогда непонятен вообще смысл вопроса. В MVC для работы с базой используется Model, какие еще вам нужны паттерны? Создаете модельку базовую и модельку под каждый тип данных и все.
zorca, Как тогда быть с роутингом на основе сегментов URL-a? Ведь получается что ContactsController.php есть (это файл физически существе, в этом файле описана логика GET и POST запроса) и URL example.com/contacts - отобразит страницу, example.com/contacts/send-message - обработает POST запрос. Но! Если я создаю один контроллер для все страниц PageController.php (что конечно логично, тут я не спорю), как теперь организовать роутинг? Ведь по запросу example.com/about файла AboutController.php не существует, этот запрос должен обработать PageController.php.
UPD: POST запрос example.com/contacts/send-message обрабатывает модель, а то ЩАС заклюют "- Он из контроллера в базу пишет и читает.!".
Дмитрий, просто вы создали отдельный контроллер для страницы Контакты, зачем? Все запросы на любые страницы отправляйте в PageController.php, на дефолтный метод типа index или deafult, где уже разруливайте полученное. Index вообще как-бы предполагает, что вы хотите вывести спсиок страниц или еще что-то, когда у вас кокнретная страница не задана. Вам скорее нужен контроллер не для страницы Контакты, а для обработки всех форм на ЛЮБЫХ страницах. Посмотрите как это раньше было реализовано в Ларе, сейчас изъято правда из ядра: https://laravelcollective.com/docs/5.4/html
zorca, Я понимаю, отображение страниц происходит через PageController.php. Но мне помимо вывода простых страниц из БД, требуется еще обрабатывать POST запрос, например со страницы контактов. В том и заключается вопрос, как прикрутить это все...
Дмитрий, создаете контроллер FormsController.php и внутри методы для каждой формы и перенаправляйте пост-запросы из ВСЕХ форм на него. В данном случае у нас именно форма является неким новым объектом, который требует подхода, отличного от страниц. Форме назначаются поля данных и контроллер, который будет обрабатывать субмит. Сабмит формы можно обрабатывать в контроллере формы, а можно и в другом контроллере, Ведь форма может создавать страницы к примеру, а не почту отсылать.
zorca, да неет ) чем этот метод лучше наследования от класса PageController? Уже лучше тогда для обработки запросов формы, делать так:
class Contacts extends Page {
// метод index наследуется из класса Page
public function sendMessage($data) {
// валидация
// вызов модели ContactsModel.php (запись в базу)
}
}
Дмитрий, ну вы же стремитесь следовать правильной стратегии? Можно вообще все описанное наговнокодить в одном PHP-файле и все будет работать. Но предполагается, что ваше приложение будет расти и поэтому каждый контроллер должен решать свою задачу: Page - отображать страницу, Form - отображать форму на странице и решать что делать при сабмите и третий Mail - который вы будете подключать при сабмите к контроллеру Form. Вы просто пытаетесь писать в ООП, а все еще смотрите на свое приложение как на одностраничный PHP гавнокод, а все ваши "контроллеры" и "модели" в итоге только мишура, прикрывающая очень простую суть.
zorca, я не собираюсь спорить с вами на счет mvc. Но! Заводить контроллер, для описания методов обработки РАЗНЫХ форм, это и есть чистыой воды говнокод! Форма это страница, форма может не пройти валидацию, в этом случае, нужно отобразить форму с указанием на ошибки. (ВНИМАНИЕ: Я только что высказал свое мнение, это может показаться странным, но оно может идти в разрез с вашим, такое иногда случается.) Попробуйте реализовать оба подхода и посмотреть на "красоту" и "правильность" предложенного вами варианта. "- говнокод" Зачем делать такие громкие заявления? Предложенный мною вариант, прицепов паттерна не нарушает и значит имеет право на жизнь,
Дмитрий, а зачем спорить? Вы спросили, я ответил. Это вы задаете здесь вопросы, а не я. Я ответил на более чем 200 вопросов из них 36% решило ту или иную проблему. Я так же вам привел методику работы контроллеров форм из двух популярных фреймворков. Форма - это не страница, это всего лишь HTML-элемент, который вставлен в страницу. Как вы будете решать задачу, если вам понадобится сделать 2 формы на странице?
zorca, Я ценю то, что вы пытаетесь мне помочь.
Свое мнение по поводу FormController я уже высказал. Пусть хоть 10-ть форм на одной странице, этот подход запутывает код.
Я не отрицаю того факта, что написанный мною код, далек от "идеала", именно поэтому я задал этот вопрос.
Дмитрий, а что тут может запутать код? Если вы отдельную логику выносите в отдельный же контроллер. Поймите - контроллер занимается СВОЕЙ ЛОГИКОЙ, а не своей страницей, формой или каким-то еще конкретным элементом сайта. Формы валидируются в наше время: 1) на стороне клиента и сразу клиент получает отклик в форму, без перехода на другую страницу, 2) на стороне сервера через API, в этом случае можно перезагрузить страницу, вернувшись на ту же но с выводом ошибок, которые хранятся в сессии пользователя, либо через API опять же на той же странице, через AJAX. Вы хотите написать велосипед, дык никто не мешает. Но посмотрите как это уже решено в ведущих фреймворках и используется тысячами разработчиков по всему миру.
Ну если вы храните в базе типовые страницы, то заведите для всех страниц контроллер `PageController`, который и будет отрабатывать все типовые урлы и тянуть модель, чтобы та таскала из бд данные для страниц. Если страницы отличаются, то нужно будет сделать по контроллеру для каждого типа страниц (вряд ли страницы полностью разнородны).
Средний
