Я довольно новичок в php, и я пытаюсь решить, как лучше организовать страницы и, используя PHP, доставить их. Две (основные) идеи, которые у меня были:
Куча отдельных страниц с PHP включает в себя заголовок, нижний колонтитул и меню.
На одной главной странице есть меню, заголовок и нижний колонтитул, а также основной контент. Имя страницы происходит от переменной в URL-адресе.
Есть ли у кого-нибудь другие предложения или идеи? Это довольно простой материал, но подумал, что я увижу, есть ли у кого-нибудь лучшие идеи.
благодаря
Раньше я ездил в обоих направлениях, и хотя у них обоих есть плюсы и минусы, я склоняюсь к вашему второму варианту, единственной главной странице, которая содержит макет. Это похоже на то, как ведущие страницы работают в приложениях для настольных издательских систем, и у ASP.NET хорошая реализация этой идеи – не то, что я говорю, что вы должны переключать технологии.
Однако, если вы идете по этому маршруту, используйте mod_rewrite, чтобы получить свои пути на главной странице PHP, а не в ваших URL-адресах. Ваш файл .htaccess должен содержать что-то вроде:
RewriteEngine On RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^.*$ - [S=1] RewriteRule ^(.*)$ /index.php?path=$1 [QSA] В основном это говорит о том, что файл, который они запрашивают, не существовал, вместо того, чтобы передавать обработку ошибки 404 в index.php с URL-адресом в переменной запроса. Таким образом, « http://example.com/path/to/page » заканчивается нажатием index.php с $ _GET ['path'], установленным на «/ path / to / page». Оттуда вы можете вытащить контент из базы данных, плоского файла или того, что у вас есть. Вы также можете выбрать разные шаблоны на основе запрошенного пути.
Мне нравятся отдельные страницы с включенными для заголовков и еще много чего.
Я должен поддерживать сайт, на котором оригинальный разработчик использовал одну страницу с переменной в URL-адресе, и это боль. Это затрудняет любые изменения, кроме добавления новых похожих страниц. Хотя он также использовал фреймы, так что это может быть частью проблемы.
Учитывая эти два варианта, я бы пошел с номером 2. Если ваш сайт вырастет до уровня, необходимого для правильной структуры, перемещение отдельных страниц без всех include ('header.php'); вещи будут намного проще. Для бонусных очков используйте модель и просмотрите папки, в которые нужно поместить db-доступ и логику отображения соответственно, и вы на полпути к истинной среде MVC .
редактирование для добавления – один индекс с условными включениями также дает вашему приложению единственную точку входа, которая может быть очень ценной для безопасности.
Почему идти только на полпути в правильном направлении? Используйте одну из существующих инфраструктур MVC. Они являются мощными инструментами, которые структурируют код, вероятно, намного лучше, чем любое пользовательское решение. Пойдите для MVC, узнайте, как отделить бизнес-логику от логики представления и от структуры данных, повысить свою ценность на рынке труда в качестве потенциального сотрудника , сэкономить ваше время и быть счастливым.
Вероятно, вы должны начать (но не ограничивать себя) Kohana PHP, поскольку он имеет мягкую кривую обучения.
Главная с PHP заключается в том, что вам нужно «ХРАНИТЬ ПРЕДСТАВЛЕНИЕ И ПРОГРАММА ЛОГИКИ ОТДЕЛЬНО» . Или, другими словами, убедитесь, что вы не эхом html на экране в середине скриптов, которые вы делаете в своей бизнес-логике или в обработке.
Второе решение – довольно распространенное (и не плохое) решение проблемы. Он позволяет вам создать единую страницу со всей информацией о вашем макете, которая затем включает в себя конкретное содержимое страницы, которое будет отображаться. Очевидно, что это не будет работать так хорошо, если вам нужно поменять большие части шаблона макета с одной страницы на другую. В этом случае ваше первое решение будет работать лучше.
Наконец, я настоятельно рекомендую вам взглянуть на различные фреймворки PHP, такие как Zend Framework , Symfony или CakePHP, чтобы посмотреть, как они справляются с этой проблемой. Если вы найдете тот, который вам нравится, просто используйте его. В противном случае вы, вероятно, получите отличные идеи о том, как структурировать свой собственный сайт.
это действительно зависит от вашего сайта. если вы хотите повторно использовать свои компоненты, тогда будет использоваться подход с использованием включений. вы можете попробовать создать своего рода мастер-страницу и просто отобразить страницу, в которой вы хотите, внутри нее
Это делает вашу жизнь намного проще иметь меню и заголовки в header.php и footer, sopyright и т. Д. В footer.php. Затем просто включите эти файлы в каждую созданную вами страницу.
Зависит.
Содержимое страницы хранится в базе данных? Если это так, вам, вероятно, будет лучше всего иметь шаблон для каждой контент-страницы, которая просто получает содержимое, заголовки и метаинформацию из базы данных и вставляет их в шаблон. У вас даже могут быть разные типы страниц (новости, статические страницы контента, архивные страницы и т. Д.), Которые могут иметь другой шаблон.
Если контент находится в более или менее плоских файлах, два предложения, которые у вас есть, работают, и я думаю, что последний является самым простым в обслуживании.
В прошлом я использовал оба метода, я обнаружил, что первое является более гибким, но оно может поощрять плохие практики. Последний обеспечивает гораздо более последовательный пользовательский интерфейс, поскольку он держит всю вашу логику всего сайта в одном месте и не позволяет вам делать одноразовые исключения.
Я на самом деле в процессе преобразования сайта, который я написал пару лет назад, из включенной модели header / footer / menu в модель главной страницы. Оригинальная система включений была чистой и простой и работает очень хорошо. Однако чем больше контента я создал, тем больше я понял, что проект начинает нарушать принцип DRY . Каждая страница на сайте начиналась и заканчивалась тем же способом (повторение всегда должно посылать предупреждающие сигналы), и у меня возникало искушение делать исключения из стандартного макета, исключая отдельные включения и записывая одноразовые замены. (К счастью, я не уступил этому искушению часто!)
Рефакторинг сайта делает страницы более последовательными, макет легче обновлять (вы можете увидеть всю вещь «с первого взгляда»), а новые страницы легче создать.