У меня есть объектно-ориентированная структура, которая использует дизайн страницы, где каждая страница расширяет представление о структуре. Так, например, моя индексная страница для сайта на самом деле является классом, который реализует абстрактный класс View представленный каркасом. Я подключаю фреймворк, включив стартовый скрипт в верхней части страницы, и после некоторой обработки фреймворк создает экземпляр страницы и обрабатывает данные своего представления. Чтобы добавить гибкость в систему, я не требую, чтобы имя класса было именем самого файла. Это позволяет мне создать что-то вроде класса поддержки и вести себя как индекс для /support/ subdomain.
Сначала я передавал имя класса страницы в фреймворк с помощью конструктора фреймворка, но это добавило еще несколько шагов к верхней или нижней части страницы. В настоящее время я получаю имя класса через таблицу страниц в базе данных, идентифицированную фильтрованным запрошенным URI . Я использую эту таблицу для создания навигации, и добавление дополнительной таблицы столбцов было практически бесплатным. Это работает нормально, пока у меня есть соединение с базой данных, но я пытаюсь реализовать статическую поддержку страниц для сообщений о состоянии и отчетов об ошибках, и мне нужен другой метод для создания экземпляра класса страницы. Если я использую стандартное соглашение о присвоении имени имени файла, то я знаю, что у меня есть надежный способ экстраполяции имени класса. Я не хочу называть все индексы моих классов только для объяснения причин. Какой совет или какие-то стандарты для инициализации объектно-ориентированных фреймворков?
<?php abstract class View { abstract function getView(); } ?>
<?php require_once("View.inc"); require_once("CoreController.inc"); $Framework = new CoreController(); $Framework->Initialize(); exit; ?>
<?php require_once("Startup.inc"); class Index extends View { public function getView() { echo "<pre>View Data</pre>"; } } ?>
В моей структуре у меня есть TemplateController, который обрабатывает страницу. Класс страницы известен, потому что он отображается другим классом. Однако без базы данных я хотел бы открыть класс внутри, скажем, index.php без изменения способа его настройки. Вот фактический код в TemplateController.
//Get the View Class from Page $view = $page->getPageClass(); //We need to catch View creation failure $this->Page = new $view($this->Framework); //Initialize the Page View $this->Page->Initialize(); //Cache the Page View $this->cacheView($this->Page, $page->getPageName(), $this->SiteID.TCS_PAGE_SORTID);
В фрагменте над представлением $view это фактическое имя класса, сопоставленного с другим контроллером. Я передаю ссылку на структуру конструктору представления, а остальное действительно не имеет значения. Я пытаюсь придумать подобный метод сопоставления для определения класса страницы в случае, если база данных не работает. Мне нравится, что одна включает строку для запуска фреймворка и хотела бы, чтобы это было просто.
В верхней части TemplateController я также должен повторно включить фактическую страницу, так как мой сценарий запуска находится наверху, фактический класс не включен, даже если это запрошенная страница.
include($_SERVER['SCRIPT_FILENAME']);
Просмотрите вопрос о переполнении стека. Идентифицируйте имена классов из $ _SERVER ['SCRIPT_FILENAME'] для получения дополнительной информации о том, что я пытаюсь сделать.
Вот мой контрольный список маршрутизации страницы:
И самое главное – прекратите копирование, подумайте о лучшем подходе.
Все те предложения, которые я использовал в PHP UI framework – Agile Toolkit, где я являюсь автором.
Релевантные источники: Agile Toolkit – PHP Framework с jQuery , Agile Toolkit – PageManager.php , Agile Toolkit – URL.php и Agile Toolkit – PathFinder.php .
Мы хотели сделать это очень простым для разработчиков. И тоже. И гибкий. Поэтому класс «страница» выбирается на основе URL-адреса. Как? Вполне легко:
/hello.html -> page_hello /hello/world.html -> page_hello_world
Затем класс отображается в имя файла. page/hello/world.php
Тогда бывают случаи, когда мы также хотим использовать динамические URL-адреса, например: /article/234
Многие структуры реализуют здесь сложные методы (массивы, регулярные выражения, фронт-контроллеры). Мы этого не делаем. Для этого есть mod_rewrite . Просто перепишите это в page=article&id=234 и он работает. И весы.
Помимо страниц существуют и другие классы, но к этим классам нельзя обращаться напрямую. Поэтому страницы живут в папке / page /, различают их и сохраняют безопасность.
Затем появляется дизайнер, говорящий: « Я не буду писать PHP ». Поэтому мы вводим статические страницы. Если класс page_hello_world не определен, мы рассмотрим template/skin/page/hello/world.html . Это простой ярлык для дизайнеров и не-разработчиков, чтобы добавить новую страницу.
Что делать, если страница не найдена? Api->pageNotFound() . Не стесняйтесь переопределять и загружать страницы с SQL или отображать 404 страницу с изображением розового слона.
И тогда есть несколько страниц, которые поступают из надстроек . Мы не хотим включать их по умолчанию, но вместо этого пользователи могут добавлять их в свое приложение. Как?
class page_hello_world extends Page_MegaPage
Следующий вопрос заключается в том, как мы обрабатываем подстраницы этой страницы, так как иногда вся функциональность не может быть помещена на одну страницу. Итак, добавим поддержку page_edit() (или любого page_XX) в качестве псевдонима для подстраницы внутри этих классов. Теперь разработчик дополнений может включать в себя многофункциональную страницу, которая может быть расширена, настроена и размещена в любом месте приложения.
Наконец, есть хакеры, которые хотят сделать что-то очень быстро. Для них мы применяем ту же технику к API. Вы можете определить функцию page_hello_world в API, и вам не нужен класс.
Некоторые могут сказать, что существует слишком много способов сделать простую вещь. Ну что ж.
Надеюсь, что это было полезно.
Используйте __autoload() . Большинство основных фреймворков PHP используют автозагрузку для оптимизации загрузки классов.
Вам нужно каким-то образом сопоставить URL-адрес с объектом, который обычно обрабатывается компонентом маршрутизации в большинстве фреймворков. Можете взглянуть на библиотеки, такие как https://github.com/chriso/klein.php , или компоненты маршрутизации основных платформ (Zend, Symfony и т. Д.).
Почему бы не использовать информацию из URL для определения правильного класса? Поскольку вы не будете использовать базу данных для статических страниц, вам необходимо каким-то образом сохранить сопоставление между URL и классом в файле. Т.е. у вас будет файл mapping.php :
return array( 'about' => 'AboutView', 'copyright' => 'CopyrightView', );
Здесь и copyright используются URL-адреса, а значения представляют собой соответствующие дочерние классы View . У вас могут быть URL-адреса, например http://example.com/index.php?page=about, и использовать возможности перезаписи веб-сервера, чтобы они выглядели хорошо.
Вы измените реализацию Page::getPageClass() , чтобы вернуть правильный класс представления. В зависимости от URL-адреса он будет использовать статические сопоставления из вышеуказанного файла или использовать базу данных.
В чем проблема с этим подходом?