Xpoint
   [напомнить пароль]

Как создать единый сайт из разрозненных скриптов php на основе css

Метки: [без меток]
2012-06-03 23:07:10 [обр] lassy[досье]

Я осваиваю PHP и CSS.
Я сделал несложную фотогалерею на основе фреймов. Получилась куча скриптов, каждый из которых загружается в

свой фрейм и так создается и изменяется единая страница - сайт.
Но фреймы - устаревшая технология. Как собрать сайт из скриптов на единой странице, которую бы можно было менять,

но на базе набора скриптов и CSS. Каждый скрипт создает свою страницу, как их связать воедино, подобно фреймовой

структуре. Кроме того, каждый скрипт по своему выполняет правила внешних таблиц CSS.
Посоветйте, пожалуйста, где об этом прочитать - как связать скрипты в единый сайт. Как вообще делаются сайты на PHP

и CSS?
Спасибо.

спустя 16 минут [обр] Евгений Седов aka KPbIC(7/176)[досье]
М Перенесено из форума "Прочее"
спустя 54 минуты [обр] Филипп Ткачев(20/112)[досье]

Ну все достаточно просто.
Вы разделяете свой сайт на куски - заголовок, шапка, меню, содержимое, подвал. Потом пишите код, который подключает нужную часть. Каждая из частей несет в себе нужный фрагмент HTML-кода или выполняющегося PHP-кода.
Например index.php:

// все наши кусочки лежат в отдельной папке fragments
// подключаем шапку - header.php
include_once('fragments/header.php'); 
// подключаем менюшку
include_once('fragments/menu.php'); 

// устанавливаем страницу по умолчанию
$page = 'index';
// переключаем на нужную страницу при наличии запроса
// т.е. получается наша запрос выглядит так http://domain.tld/index.php?page=hello
if (isset($_GET['page'])) {
 switch($_GET['page']) {
  case 'hello': $page = 'hello'; break;
  case 'gallery': $page = 'gallery'; break;
  // пример с файлом в другой папке
  case 'folder/file': $page = 'folder/file'; break;
 }
}
// подключаем нужную страницу
include_once('fragments/'.$page.'.php'); 
// подключаем подвал
include_once('fragments/footer.php');

Можно даже сделать ЧПУ (http://domain.tld/folder/file/) . Создайте файл .htaccess в корне сайта.

DirectoryIndex index.php
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?page=$1 [L,QSA]

Теперь ваш "хвостик" всегда будет внутри переменной $_GET['page'].

спустя 10 часов [обр] Евгений Седов aka KPbIC(7/176)[досье]
Филипп, вы до сих пор считаете, что умеете мапить урлы на PHP эффективней, чем это делает Apache?
спустя 3 часа 49 минут [обр] lassy[досье]

Спасибо Евгений! Меня смущают в Вашем ответе некоторые моменты:

  1. Если к индексу приинклюдить header.php и menu.php и еще что-то, идентификаторы переменных должны в них быть все разные, ведь так? $link, который я использую в одном скрипте имеет совсем другой смысл и значение, чем в другом скрипте. Придется переделывать все скрипты, чтобы переменные в них не повторялись? Да?

2.$page это всего лишь переменная PHP и если я присвою ей значение 'index', каким образом это повлечет за собой то, что выдачи всех приинклюденных скриптов пойдут на одну страницу, а не каждый будет создавать свою?

  1. Что за расширение .tld такого нет, оно не открывается браузером?
спустя 16 минут [обр] Филипп Ткачев(20/112)[досье]

Евгений Седов aka KPbIC[досье], я не соревнуюсь в эффективности с Apache и другими серверами. Просто я по-другому подхожу к задаче. Я сайт рассматривая как веб-приложение с единой точкой входа, которое в свою очередь умеет подключать соответствующий функционал в зависимости от запрошенного материала. Имея подобный механизм я могу осуществить динамическую генерацию документов с эффективным кэшированием в файловой системе.

lassy[досье],

  1. Да, приложение стоит строить с учетом возможных пересечений имен переменных. Изоляция переменных внутрь локальных областей видимости - одно из необходимых условий создания проектов достаточно крупного уровня. Самый простой способ - оформление кода в виде одной общей функции на модуль с необходимым количеством аргументов передаваемых внутрь.
  1. Пока не будет соответствия списку внутри switch, у вас будет одна и та же страница index.
  2. tld
спустя 2 часа 46 минут [обр] Евгений Седов aka KPbIC(7/176)[досье]
сообщение промодерировано

Филипп Ткачев[досье]

Единая точка входа — это сокет сервера (или виртуальный сервер). Следующая фаза - мапинг урла. Вы почему-то не хотите юзать код веб-сервера для этих целей и пишите свой велосипед.

Про динамическую генерацию и эффективность кэширования я вообще не понял. С год назад уже был подобный разговор с Алексеем Севрюковым, и тогда я его просил показать преимущества подхода, который описываете вы, над "классическим", но Алексей ушел из спора по-английски. Если вас не затруднит, покажите на транке Точки, где я ошибаюсь в своих рассуждениях? — где у меня проблемы с "динамической генерацией" и с "кэшированием в файловой системе"?

Пока для меня это выглядит так, как если бы в многоэтажном доме люди не сразу бы поднимались на лифте на свой этаж, а сначала поднимались бы на лифте к вам в квартиру, а вы уже за руку по лестнице отводили каждого на нужный этаж. Потому что только вы один знаете, какая квартира на каком этаже находится и лифтам с рождения не доверяете.

lassy[досье] Пространства имен, про которые вы спрашивали, в PHP добавили всего пару лет назад. Вы, вообще, уверены, что вам нужен именно PHP? Он для простеньких задач задумывался.

спустя 3 часа 2 минуты [обр] Филипп Ткачев(20/112)[досье]

Евгений Седов aka KPbIC[досье]
Я не хочу с вами спорить о том, какой метод эффективнее и изящнее. Разные языки, разные задачи, разные подходы к их решению. Одни подходы оправданы в одних случах, другие - в других. Просто у меня такое представление: есть папка thumbnails, в которой лежат превью для фотогалереи, человек запрашивает http://domain.tld/images/gallery/thumbnails/1082.128x96.jpg, а там его нет по умолчанию, запрос заворачивается на скрипт, который вызывает генератор превьюшки, интерпретирующий запрос и получающий из него идентификатор изображения, его необходимый размер, генерирует превью и кладет его в указанную папку, делая редирект на тот же самый файл. После редиректа файл появляется в файловой системе и отдается для всех следующих пользователей автоматически. Другой пример - когда у вас CMS и произошло перестроение разделов на ресурсе, то необходимо переделать пути, установив 301 редирект (дабы не угробить SEO). Лучщий выход из ситуации понаписать редиректов в .htaccess или конфиг nginx, но уровень квалификации падает, да и лазить на FTP не всем удобно, плюс .htaccess может быть немаленький и добавлять в него редиректы сложно для менеджера. А пощелкать кнопочки внутри CMS и создать перенаправление несложно (а иногда и вовсе не требуется, т.к. внутри CMS возможно реализовать автоматическое создание редиректов).
И мое личное мнение еще и в том заключается, что не надо плодить десятки правил внутри .htaccess, описывающих всяческие перестроения параметров, а просто использовать полноценное структурированное ЧПУ.

Ну насчет трака
http://trac.xpoint.ru/browser/www/public_html/user/register/index.pl
http://trac.xpoint.ru/browser/www/public_html/user/activation/index.pl
Смотрим в начало файла. И сколько еще таких повторяющихся конструкций будет?
Не в обиду будет сказано, но shebang в веб-приложениях мне отдает каким-то атавизмом.

спустя 11 часов [обр] Jared(3/26)[досье]
сообщение промодерировано
Евгений Седов aka KPbIC[досье], с тем же успехом можно утверждать, что единая точка входа - дырка в сетевухе, куда патч-корд вставлен.
Пока вам нужно мапить УРЛ на файловую систему, код веб-сервера вполне подходит. Как только вам нужно что-то чуть более сложное, вы сразу вынуждены отдавать как минимум часть работы по маппингу своему коду, фактически размазывая этот функционал. Проще сразу реализовывать маппинг/роутинг, или как там его еще называют, самостоятельно, чтобы иметь возможность строить такие УРЛы, какие только могут в голову придти, не ограничивая себя файловой системой.
спустя 4 часа 30 минут [обр] Евгений Седов aka KPbIC(7/176)[досье]

Jared[досье] Речь идет об уровнях, начиная с уровня приложения (ISO OSI) и выше, и дырки в сетевухе в этот диапазон явно не попадают.

Код, который привел Филипп, не нуждается в центральном скрипте. Описание генерации превью тоже.

Про перестроение разделов я не очень понял, мало конкретики. Врядли вы каждый день драматическим образом меняете урлы, можно и правила апачу переписать. Я вообще не использую .htaccess, но думаю, при необходимости можно реализовать его анализ и генерацию, если у вас такая универсальная CMS.

Приведите, пожалуйста, пример "чуть более сложного", потому что пока я не вижу области, для которой необходим ручной разбор.

спустя 37 минут [обр] Евгений Седов aka KPbIC(7/176)[досье]
сообщение промодерировано

Филипп Ткачев[досье]

use ... можно вынести и в отдельный общий файл, в данном случае в модуль Server.pm, и в скриптах будет только одно включение. Сделано развесисто для более гибкого управления, чтобы не включать неиспользуемый код. И возможно это благодаря тому, что нет центрального скрипта, и каждая программа содержит только тот функционал, который ей действительно небходим. В PHP, ведь, тоже есть use ....

Шутку про shebang я не понял.

Мы не рассматриваем разные языки и разные задачи. ЯП в контексте "чем парсить урл", как мне кажется, не играет никакой роли. И задача у нас одна — разобрать урл, чтобы выполнить соответствующий код.

спустя 6 часов [обр] Phlinten(0/14)[досье]

Пипец нафлудили. Автору топика это совсем не нужно. Пускай урлы будут вида /albums.php, /frends.php и далее.

По поводу флуда: на ЧПУ ваще все пофигу, пофигу людям которые смотрят ваш сайт, пофигу роботам. Задротство на пустом месте.

Про точку входа: это в силу исторических и архитектурных причин, на питоне проще через общую точку, в силу подключения и настройки питона. В пхп можно и так и сяк и эдак.

спустя 50 минут [обр] Филипп Ткачев(20/112)[досье]
Евгений Седов aka KPbIC[досье], просто когда создается CMS, которая будет устанавливаться третьими лицами с минимальной подготовкой, нужно обеспечивать возможность создания ими произвольных адресов страниц. Я встречал в сети сайты со страницами вида http://домен.рф/каталог/раздел/товар/ и это на русском языке. Я понимаю, что извращения, но хочется людям. Да и порой хотят, чтобы тут у них была форма одна, а на этой странице должна быть другая форма и все это должно управляться через панель администрирования системы.
спустя 1 час 47 минут [обр] Phlinten(0/14)[досье]
Я встречал в сети сайты со страницами вида http://домен.рф/каталог/раздел/товар/ и это на русском языке. Я понимаю, что извращения, но хочется людям.
уверен что это хотелось программисту, или какому нить адовому сеошнику
спустя 9 часов [обр] Jared(3/26)[досье]

Евгений Седов aka KPbIC[досье]

Речь идет об уровнях, начиная с уровня приложения (ISO OSI) и выше, и дырки в сетевухе в этот диапазон явно не попадают.

Уровень приложения в модели OSI - верхний, так что "выше" HTTP в этой модели некуда.
То, что код на какой-то момент не нуждается в центральном скрипте, не означает, что это не изменится завтра. И завтра может будет проще все переписать с нуля, чем подставлять костыли к сложившейся неудачной архитектуре.

Я вообще не использую .htaccess, но думаю, при необходимости можно реализовать его анализ и генерацию, если у вас такая универсальная CMS.

Разбор, анализ и генерация .htaccess - это, вообще говоря, задача не из тривиальных. Это.. хмм.. скажем - ад и извращение. К тому же, если завтра потоп, и вы будете вынуждены перейти на другой веб-сервер, то привет вашему .htaccess. Например, закупщик заказчика купил серверную винду с ИИС'ом, но не нашел кто бы ему откатил за заказ на переписывание системы. То есть ваше приложение должно работать без .htaccess. И, чтобы сразу отмести вопросы, это было в ТЗ - независимость от веб-сервера, или возможность работать на любом из списка в приложении А.
Куда проще разбор УРЛа осуществлять самостоятельно.

Приведите, пожалуйста, пример "чуть более сложного", потому что пока я не вижу области, для которой необходим ручной разбор.

http://example.com/news/01-02-2012/news1-name/
Это аггрегатор новостей. Каждые сутки на нем собирается over9k новостных статей. Я надеюсь, вы на каждую новость не будете создавать директорию на диске с index.php внутри?
Оттуда же:
http://example.com/news/tag/tag-name/
http://example.com/news/news-category/author/author-name/
http://example.com/news/news-c......more-field/second-field-value/

Либо отказаться от ЧПУ:
http://example.com/news/?date=01-02-2012&name=news1-name
Либо прописывать в .htaccess все варианты параметров, какие можно подсунуть скрипту. Да, по ТЗ вложенность категорий до 10ти.

А через неделю заказчик просит за 100 рублей прикрутить блог, древовидный форум, многоуровневый каталог товаров и многопользовательскую галарею. С ЧПУ. С такими же возможностями выборки и фильтрации.

Phlinten[досье]

на ЧПУ ваще все пофигу, пофигу людям которые смотрят ваш сайт, пофигу роботам. Задротство на пустом месте.

Вы неправы. Мне не пофигу, я частенько пользуюсь возможностью перейти на уровень выше по сайту, удалив последний сегмент урла. И маму свою научил ;).

Вот тут была доработка по одному проекту - спецы по юзабилити сказали заказчику, мол даешь ЧПУ вместо урлов вида /object/object-id. Там, кстати рельсы, на своем собственном веб-сервере и со своим собственным раутингом, на руби же и написанным. Это к вопросу об эффективности.

спустя 12 часов [обр] Phlinten(0/14)[досье]

Уффф.... как же люди любят обманыватся, сами себя обманывают и другим внушить пытаются.

К тому же, если завтра потоп, и вы будете вынуждены перейти на другой веб-сервер, то привет вашему .htaccess. Например, закупщик заказчика купил серверную винду с ИИС'ом, но не нашел кто бы ему откатил за заказ на переписывание системы. То есть ваше приложение должно работать без .htaccess.

Да чего уж потоп, сразу кирпичом накрыло сервер, и переносить ничего не нужно. У того же IIS можно нажатием одной кнопки перегнать .htaccees в ISS правила.

Это аггрегатор новостей. Каждые сутки на нем собирается over9k новостных статей.

Да, в агрегаторе новостей это очень важно. Вот люди туда заходят и сразу ссмотрят на ссылки, и давай стирать последние сегменты урлов.

спустя 2 часа 7 минут [обр] Филипп Ткачев(20/112)[досье]
Все вы конечно хорошо обрисовываете, пока не наступает момент массового деплоя веб-приложения. Итак, у вас на дестинейшене может быть nginx, lighthttpd with php as fastcgi, nginx/php-fpm, apache1x, apache2x, IIS. Эм... не буду приводить всякую остальную экзотику. Под каждый случай можно написать по 3-4 строчки правил в FAQ, которые достаточно будет просто скопировать и вставить в конфигурационный файл, чтобы заработало. Но если у вас веб-приложение с динамическим контентом, да еще и высокой степенью персональной настройки заточенной под не очень квалифицированного юзера (например это Joomla CMS), то тут решение с виртуальными путями весьма обосновано.
Был у меня несколько лет назад печальный опыт - была написана пара скриптов и правила к ним внутри .htaccess, строк 15 правил, стоял Apache 1.2 кажется. Потом хостеры сменили версию Apache и все посыпалось. Ладно бы ерунда какая, но эти хостеры не уведомили о работах и утром позвонили клиенты с матами и расторжением договора о поддержке сайта. Сайт был недоступен около полусуток из-за "смены интерпретации правил" mod_rewrite. На том же хостинге стояла система с высокоуровневым разбором URL, из-за простых правил она продолжила работать, никто ничего и не заметил, что там что-то поменялось. Конечно, и апдейт PHP тоже может пагубно сказаться на системе, но тут мы получим какой-нить deprecated warning, нежели страшную пустую 503.
спустя 2 часа 22 минуты [обр] Phlinten(0/14)[досье]
Ладно бы ерунда какая, но эти хостеры не уведомили о работах и утром позвонили клиенты с матами и расторжением договора о поддержке сайта.

Ок, в дата центре отрубили свет, канал перерубили, или просто ребята накатывают обновление системы, и не уложились в положенные 2 часа к примеру. Как тут ЧПУ поможет?

какие то странные доводы приводите.

спустя 4 часа 58 минут [обр] Jared(3/26)[досье]
Phlinten[досье], вы просто, как мне кажется, троллите толсто, пардон за оффтоп.
Вы можете какие-нибудь тезисы по теме флуда высказать, или вам лишь бы ляпн... ой, то есть запостить что-нибудь?
Powered by POEM™ Engine Copyright © 2002-2005