Плюсы и минусы использования одного файла для всей веб-страницы?[закрыто]
https://stackoverflow.com/questions/121849
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Не знаю, как мне это выразить, но я попробую.
Недавно я начал программировать свое портфолио на объектно-ориентированном PHP, и мне интересно, соответствует ли передовой практике использование одной страницы, содержимое которой меняется в зависимости от данных SQL и переменной $_GET?
Если да/нет, то почему?
Редактировать:Более подробную информацию вы найдете в моем следующем посте.
Решение
Вы спрашиваете об использовании шаблона фронт-контроллера, где один файл обслуживает все ваши запросы?Часто это делается с помощью index.php и mod_rewrite, получающих все запросы, а остальная часть URL-адреса передается ему в качестве параметра в строке запроса.
http://www.onlamp.com/pub/a/php/2004/07/08/front_controller.html
Я бы рекомендовал использовать этот шаблон для приложений, потому что он дает вам единое место для обработки таких вещей, как аутентификация, и часто вам придется интегрировать вещи на более тесном уровне, где новые функции будут классами, зарегистрированными в контроллере. через какой-то механизм имеет большой смысл.
Опасения по поводу URL-адресов, упомянутые другими, не совсем точны, поскольку между структурой URL-адресов и структурой файлов нет реальной связи, если только вы не используете древние методы создания веб-сайтов.Значительная часть функциональности Apache основана на концепции, согласно которой структура файлов/каталогов и структура URL-адресов являются разными понятиями (модуль псевдонима, модуль перезаписи, согласование содержимого и т. д. и т. п.).
Другие советы
- Не масштабируемый
- Трудно управлять кодом
- Парсер должен анализировать все
- Идеальный пример Code Smell
- Одна ошибка приводит к сбою всего вашего сайта
Если вы имеете в виду одну целевую страницу (например,index.php), который затем использует переменные сеанса и т. д.чтобы выяснить, какой код нужно включить, то да, это часто используемый прием.
Редактировать:и под вышеизложенным я имею в виду то, что Даниэль Папасян подробно объясняет в своем прекрасном посте
Если вы имеете в виду размещение всего вашего HTML, SQL и PHP в одном файле, то нет, по причинам, указанным GateKiller.
Файл страницы actaul должен содержать только то, что отличается на этой странице от стандартной «страницы» вашего сайта (например, заголовок страницы, индексная страница может содержать код для получения последних новостей и т. д.).Все, что используется (или может) использоваться более чем в одном месте, должно быть перенесено во внешние файлы php и включено.Примеры:
- Информация о базе данных (пароль, имя пользователя и т. д.)
- Верхний/нижний колонтитул
- Код входа
Это значительно упрощает управление кодом.Например, если вы измените пароль базы данных, это будет только один файл, который необходимо обновить, или если вы решили добавить баннер в заголовок, это снова будет только одна страница, а не все страницы, которые необходимо изменить.
Это также значительно упрощает добавление новых функций, например, новая страница может быть просто:
<?php
require ('config.php')
require ('start.php')
require ('header.php')
//custom page stuff
require ('footer.php')
?>
или добавление автоматического входа через файлы cookie — это простое изменение функции Login() (создание файла cookie) и start.php (проверка наличия файла cookie + вызов Login()).
Также вы можете легко перенести эти файлы в другие проекты в будущем.
Все, что упомянул Gatekiller + вы также не можете использовать позднее связывание.
- Трудно управлять кодом
Если вы используете контроль версий, будет НАМНОГО сложнее отменить любые изменения, которые могли произойти с одной «страницей» вашего сайта.Поскольку вам придется снова объединиться для всего, что могло произойти после
Это не так удобно для поисковых систем, если вы не используете переписывание модов.
Я склонен не согласиться с большинством вопросов: если ваш сайт управляется специальной CMS или чем-то подобным, нет причин не использовать одну страницу.
Я сделал то же самое с CMS, которую написал некоторое время назад.У всех клиентов была одна страница default.asp, которая запрашивала базу данных на предмет темы, содержимого, вложений и разрешений участников.Чтобы внести изменение, я просто внес изменение один раз и скопировал его другим клиентам, если этого требовало изменение.
Это, конечно, не сработает в большинстве сценариев.Если у вас есть веб-сайт, который делает много РАЗНЫХ вещей (моя cms просто повторяет определенные функции при загрузке страницы), то несколько страниц — действительно единственный вариант.
Для тех из вас, кому интересно, существует фреймворк, использующий именно эту модель.Первоначально для ColdFusion.Сообщество этой методологии все еще существует, версия 5.5 была выпущена около года назад (декабрь 2007 г.).
Этот снимок экрана и следующее объяснение могут дать лучшее представление о том, как выглядит мой код в данный момент.
Я использую ту же модель, которую упоминают «Интернет-друг», Дэниел Папасян и некоторые другие;Передний контроллер.
Моя индексная страница выглядит так.
require_once 'config.php';
require_once 'class_lib/template.php';
$template = new template($config);
$template->dataQuery();
$template->pageCheck();
$template->titleAssembly();
$template->cssAssembly();
$template->metaAssembly();
$template->menuAssembly();
$template->content();
echo $template->publish();
Конструкция класса открывает основной файл шаблона и загружает его в переменную, которой может манипулировать каждый метод, заменяя теги сгенерированным кодом.Некрасивые URL-адреса на самом деле не являются проблемой, поскольку я буду использовать mod_rewrite, чтобы их исправить.
Однако Папасян прав: этот метод больше подходит для веб-приложений и тому подобного.
Я прошу прощения за то, что не был очень конкретен в своем вопросе.
Кроме того, большое «спасибо» всем, кто написал несколько строк, чтобы помочь.
Я часто использую файл php без расширения .php (т.е. сайт) и добавляю
<Files site>
ForceType application/x-httpd-php
</Files>
в .htaccess, который заставляет Apache интерпретировать файл как файл php.
Вы можете проанализировать переменные в файле внутри URL-адреса: http://www.вашдомен.com/site/var1/var2/var3
Использовать
$var_array = explode("/",$_SERVER['REQUEST_URI']);
$var1 = $var_array[1];
$var2 = $var_array[2];
$var3 = $var_array[3];
чтобы получить vars.Таким образом, вы можете использовать один файл с поисковыми URL-адресами без перезаписи.
ре:URL-адрес и файловая структура
Я преобразовал сайт, где весь контент находился в базе данных и доступ к нему осуществлялся по модели index?p=434.Использование базы данных не приносило никакой пользы, а сайт сбивал с толку людей, которым приходилось добавлять контент, поскольку им приходилось редактировать контент с помощью браузера, а страницы представляли собой просто числа.
Я вытащил весь контент и поместил его в отдельные файлы.Каждый имел разумное имя и был организован в папки.Каждый файл выглядел примерно так:
require('sitelib');
do_header('about', 'About Us');
// content here
do_footer();
Клиенту понравилось.Они могли использовать любой HTML-редактор, чтобы войти, найти нужный файл и внести изменения.И они смогли создать новые страницы.Все, чтобы сказать:Иногда полезно совместить URL-адрес и файловую структуру.
